Home > Allgemein, PHP, Studium > getDigital – Bewerbung als Web-Entwickler

getDigital – Bewerbung als Web-Entwickler

Nein, ich habe mich nicht woanders beworben. Ich bin aber vorgestern durch Zufall auf einen Facebook Kommentar von getDigital gestoßen. Diese suchen momentan einen Informatiker mit Schwerpunkt Web-Entwicklung (wer sucht die momentan eigentlich nicht?).

Eigentlich nichts erwähnenswertes wäre da nicht ein kleiner Einstellungstest bevor man sich bewerben darf. Hab ich in dieser Form noch nirgends gesehen und finde ich persönlich auch gar nicht gut. Würde ich mich in einer Firma bewerben, die diese Art von Test macht, dann würde meine Meinung auf jeden Fall negativ beeinflusst werden. Natürlich verstehe ich die Firma, welche Flachpfeifen im vornherein aussieben möchte und oft erkennt man es einem Menschen nicht an. Ich spreche auch aus eigener Erfahrung.

Ich habe Informatik studiert und das gar nicht mal schlecht (Diplom mit Auszeichnung bestanden) und ich komme lieber einen oder zwei Tage zum probe arbeiten (Wichtig: Nach dem Vorstellungsgespräch) als so einen Test zu machen. Ein Vorstellungsgespräch sollte meiner Meinung nach für beide Partien ein Kennenlernen sein. Nur weil mich der Arbeitgeber möchte, heißt das ja noch lange nicht, dass ich auch ihn möchte? Aber ich schweife glaube ich ab.

Nun zu den Fragen die getDigital vorgibt. Die Quelle der Zitate ist unter http://www.getdigital.de/index/jobapplication/idB/8 zu finden:

Frage 1 Sie bekommen die Problemstellung, dass Kontonummern und Bankleitzahlen auf Korrektheit geprüft werden sollen, da zu viele Betrugsversuche per Lastschrift auffallen. Wie gehen Sie an die Lösung des Problems heran?

Meine Antwort:

Also die beste Lösung ist ja eigentlich da gar nichts selbst zu machen, sondern das der Bank (welche sicherlich über eine API am Shop angebunden ist, bspw. Saferpay) zu überlassen. Vorteil: Wenn die Bank das O.K. gibt, dann passt es höchstwahrscheinlich auch. Wenn nicht dann nicht.

Dumm nur: Oft kostet jede Transaktion/Anfrage bares Geld (unser Geld!), und bei entsprechend hohen (falschen) Eingaben bleiben wir auf der Kohle sitzen. Nicht gut. Wir könnten doch die Kreditkartennummer/Kontonummer selber prüfen? Hurra, die Lösung! Selbstverständlich gibt es rudimentäre Prüfungen (Bspw. Anzahl der Zahlen in der Kreditkartennummer/Kontonummer) oder auch aufwendigere, da Kreditkartennummern/Kontonummern einen CRC (bzw. Prüfziffer) beinhalten. Wir sollten uns aber niemals nur auf unseren eigenen Check verlassen, sondern diesen nur als Vorauswahlkriterium prüfen.

Ohne Anfrage an die Bank kann anhand der Nummer nicht festgestellt werden, ob die Karte bspw. gestohlen wurde.

Frage 2 Schreiben Sie PHP Code, der auf ein beliebiges Datum der Form dd.mm.yyyy 1337 Minuten addiert.

Meine Antwort:

Diese Antwort gestaltet sich schon etwas schwieriger. Das Problem ist in der Fragestellung begründet “…beliebiges Datum der Form…”. Da steht ja nirgends, dass es ein gültiges Datum sein muss. Der 42.13.2012 ist ein Datum, aber sicher nicht gültig. Ok, wenn wir davon ausgehen, dass ein gültiges Datum gemeint ist, dann ergeben sich ein paar interessante Punkte.

  1. Das Datum hat keine Uhrzeit, also gehen wir von Mitternacht aus (0:00 Uhr).
  2. Es sollen 1337 (Leetspeak) Minuten dazu addiert werden. Kurz nachrechnen: Ein Tag hat 24 Stunden und eine Stunde hat 60 Minuten: 24 * 60 = 1440 Minuten
  3. Da wir von 0:00 Uhr ausgehen und weniger als 1 Tag drauf rechnen, kommt immer das gleiche Datum raus.
  4. Ok, was aber, wenn die Jungs die Anzahl der Minuten variieren und noch eine 0 dranhängen? Also müssen wir doch was programmieren :D
  5. Eine wichtige Überlegung noch. Was passiert, wenn wir als Datum den 20. Januar 2038 nehmen (Max Unix Time)?
  6. Verdammt, jetzt bekommen wir den 02.01.1970 raus. Einem Pufferüberlauf sei Dank. Naja, bis 2038 ist es ja noch ne Weile, vielleicht fällt es keinem auf.
$date = "22.03.2012";
$minutes = 1337;
$seconds = $minutes * 60;
echo addSecondsToDate($date, $seconds);

$date = "22.03.2012";
$minutes = 13370;
$seconds = $minutes * 60;
echo addSecondsToDate($date, $seconds);

$date = "20.01.2038";
$minutes = 1440;
$seconds = $minutes * 60;
echo addSecondsToDate($date, $seconds);

function addSecondsToDate($date, $seconds)
{
 if($seconds < (60 * 60 * 24))
 {
  return $date;
 }
 return date("d.m.Y", strtotime($date) + $seconds);
}

Frage 3 Schreiben Sie PHP Code mit einer SQL Abfrage, die aus den Tabellen Kunde und Bestellung die Summe aller Umsätze aus einem Land berechnet. Die Variable $HTTP_POST_VARS['Land'] ist die Benutzereingabe für das entsprechende Land. Tabellen:

Kunde: Kundennummer INT, Land VARCHAR, z.B. “Usbekistan”
Bestellung: Kundennummer INT Bestellungswert FLOAT

Meine Antwort:

Erst mal muss man demjenigen der die Tabellen angelegt hat ein High-Five geben. Ins Gesicht! Hallo, Primärschlüssel? Naja, die ersten Probleme treten auf, sobald ein Kunde seine zweite Bestellung aufgegeben hat, da dann die Datensätze nicht mehr auseinandergehalten werden können. Für die Besserwisser: Die zweite Bestellung mit demselben Betrag :D

Aber was solls, nehmen wir es so hin, wie es ist und Werten das nun aus. Ich nehme an, dass man hier seine SQL-Fähigkeiten unter Beweis stellen soll.


$country = "Deutschland" //von mir aus auch aus $HTTP_POST_VARS['Land']

$conn = mysql_connect('localhost', 'root', 'password') OR die(mysql_error());
if (!$conn)
{
 echo "Fehler: " . mysql_error();
 exit;
}

if (!mysql_select_db("MyDatabase"))
{
 echo "Fehler: " . mysql_error();
 exit;
}

$sql = sprintf("
SELECT
 k.Land as Country,
 SUM(b.Bestellungswert) as Value
FROM
 kunde as k
 join bestellung as b
WHERE
 k.Kundennummer = b.Kundennummer
 AND k.Land = '%s'
GROUP by Land", mysql_real_escape_string($country));

$result = mysql_query($sql);
if (!$result)
{
 echo "Fehler: " . mysql_error();
 exit;
}
if (mysql_num_rows($result) == 0)
{
 echo "Fehler";
 exit;
}
while ($row = mysql_fetch_assoc($result))
{
 print_r($row);
}

mysql_free_result($result);

Natürlich kann das Skript nicht ohne Modifikationen verwendet werden, wer will schon die Fehlermeldungen dem Kunden präsentieren? Die “echo“-Befehle müssten also zwingend raus, abgesehen davon würde man sowieso eher Zend DB oder Ähnliches verwenden.

Also, wie hättet Ihr die Fragen beantwortet? Anders? Genauso?

Nur zur Klarstellung: Die Produkte von getDigital sind einsame Spitze, ich konnte selbst schon mal eines testen: USB LED-Anzeigetafel.

KategorienAllgemein, PHP, Studium
  1. 26. März 2012, 10:50 | #1

    Danke für Deine Kritik und wirklich gute Antworten! Ich hoffe, dass die nicht irgendwann geguttenbergt bei uns im Bewerbungseingang landen ;) Im Ernst: Wenn die Fragen per Google auffindbar sein sollten, müssen wir den Test wohl ändern :(

    Zu Deiner Kritik: Wir benutzen diese Tests bei allen Stellen, um uns nicht zu sehr von Noten und Abschlüssen leiten zu lassen. Wir wollen jemanden, der was kann und nicht unbedingt jemanden, der es geschafft hat, einen Abschluss zu bekommen. Eigentlich halten wir das für deutlich fairer als die normalerweise angewandten Verfahren, bei denen im Endeffekt rein nach Abschlussnoten und Rechtschreibfehlern im Anschreiben entschieden wird, wen man einlädt. Danke aber für Deinen Hinweis, dass man das auch anders sehen kann. Ich glaube, wir nehmen eine entsprechende Begründung mal mit in die Beschreibung des Tests auf.

    Ach ja: Du hast nicht zufällig Lust, bei uns zu arbeiten? So eine Bewerbung per Blogpost wäre auf jeden Fall ziemlich cool :)

  2. Christoph
    26. März 2012, 23:16 | #2

    Hallo Philipp,

    erst mal finde ich es gut, dass Ihr die Kritik positiv aufgenommen habt. War ja auch nicht böse gemeint. Finde es auch sehr gut, dass ihr nun eine kurze Begründung darüber geschrieben habt.

    Es ist nur sehr schade, dass in der heutigen Zeit so was überhaupt nötig ist. Ich kenne selbst (aus Studiumszeiten) einige, die einen einigermaßen guten Abschluss haben, aber nichts können. Und einige (von den Noten her schlechte Leute) konnten programmieren, wie junge Götter ;) Vielleicht ist da ein System wie bei euch ja die richtige Richtung.

    Trotzdem bleibt bei mir immer so ein Nachgeschmack: Kommt mir vor, wie wenn BMW einen Konstrukteur sucht, welcher zeigen soll, dass er Reifen wechseln kann :D

    Kiel ist mir leider etwas zu weit weg, wobei eine Bewerbung per Blogpost tatsächlich mal was Neues wäre. Nein im ernst: Ich wünsche euch erst mal viel Erfolg bei der Suche…

  3. Bert
    28. März 2012, 11:30 | #3

    Hm! Ja so Tests sind immer so eine Sache. Um ehrlich zu sein, hätte ich jetzt mehr dahinter vermutet. Deine Antworten zeigen deutlich, dass Du das nur zum Spaß beantwortet hast, und die Antwort von Phillip sagt mir, dass es eigentlich wirklich mehr ein Idiotentest ist, als die Suche nach den wirklich fähigen Leuten. ;)

    Zu Frage 1: Ok, da kann man nicht viel reißen. Wenn’s was kosten darf, muss man es definitiv von der Bank verifizieren lassen, ansonsten muss eine entsprechend strenge Prüfung nach den jeweiligen Regeln des Wertes her (wobei man da bei Konto und BLZ kaum falsche Eingaben filtern kann). Da eine Prüfung per API aber dann aber auch entsprechend langsam werden kann, würde ich vorher über andere Wege nachdenken. Das fängt bei der Analyse der falschen Eingaben an. Handelt es sich um Bots oder menschliche Betrugsversuche? Vermutlich keine Bots in diesem Fall. Kann man das Problem evtl. schon lösen, indem man auf eine eigene Tabelle mit BLZ + Bankname zurückgreift? Letztendlich muss da auch der spätere Weg der Bestellabwicklung berücksichtigt werden. Wie auch immer, ich denke, das Beispiel hätte für einen Test besser gewählt sein können – ein anderes Gebiet, bei dem es nicht so viele Unbekannte gibt.

    Zu Frage 2: Woher weißt Du denn, dass sie hier nicht testen wollen, wie fit Du in Sachen Performance bist? In diesem Fall hättest Du von strtotime Abstand nehmen müssen, weil’s einfach arschlangsam ist. Steht natürlich nichts darüber drin wie z.B. “die Berechnung wird x mal aufgerufen”, aber man muss ja mit Fangfragen rechnen. Natürlich muss dann auch ein entsprechender Hinweis dabei sein, damit sie einen nicht für blöd halten, weil man strtotime nicht kennt. Aber wie du schon schreibst ist das Beispiel auch wieder nicht so toll gewählt, weil mehr Wert darauf gelegt wurde, dass die Zahl cool ist, als dass sie Frage oder Lösung sinnvoll unterstützt.

    Zu Frage 3: Hier würde ich sofort vermuten, dass Dein Sicherheitsbewusstsein getestet werden soll. In diesem Fall dürfte mysql_real_escape_string genügen, ich würde derart beliebige Benutzereingaben aber vorab noch stärker prüfen – in diesem Fall auf eine maximale Länge und verwendetet Zeichen. Abgesehen von der miesen Tabellenvorgabe stört mich da aber die Vorgabe $HTTP_POST_VARS statt dem empfohlenen $_POST. Das lässt mich dann wirklich misstrauisch werden und daran zweifeln, ob die zu besetzende Stelle richtig für mich ist.

    Aber genug klug geschissen – ich finde so Tests generell gut, aus den schon erwähnten Gründen. Ich würde dann aber auch erwarten, dass sie in sich entsprechend korrekt sind, weil man mit einem schlecht gewählten Test die wirklich guten Bewerber eher abschreckt.

  4. Christoph
    29. März 2012, 00:39 | #4

    Hi Bert,

    noch ein paar kleine Anmerkungen von mir zu deinen Antworten:

    1) Ein Bestellvorgang kommt ja nicht so häufig vor, also das Surfen auf der Seite überwiegt doch sehr stark. Wenn dann der Checkout (also das tatsächliche Bestellen) 1-2 Sekunde mehr dauert (wegen langsamer API) denke ich ist das noch kein Performance-Problem.

    2) Also hätte dort gestanden “die Berechnung wird x mal aufgerufen” dann würde ich zuerst in einer Integer-Variablen alle x * die vorgegebene Zeit zusammen rechnen und danach einmal strtotime + die Integer-Variable machen. Problem gelöst :D

    3) Vielleich soll auch geprüft werden, ob das Problem mit einem SQL-JOIN oder mit zwei separaten Datenbankabfragen gelöst wird. Hier ist ein JOIN mit Sicherheit die bessere Wahl, aber bei entsprechend großen Tabellen könnten zwei kleine Abfragen durchaus einen Performancegewinn bringen. $HTTP_POST_VARS ist tatsächlich was für die Steinzeit, das wurde doch schon in PHP 4.1 von $_POST abgelöst. Würde das nie und nimmer benutzen.

  1. Bisher keine Trackbacks