Bewerbungsgespräch Softwareentwickler

[Alex_Wa]

Hallo liebe Community,

ich habe das große Glück erhalten nach dem Bachelor (Wirtschaftsinformatik) in einem Unternehmen als Junior Softwareentwickler zu starten. Nach einem Gespräch mit dem Entwickler aus dem Unternehmen habe ich erfahren, dass paar Fragen zu "Grundlagen der Programmierung" (Java) anstehen werden um meine Kenntnisse zu prüfen.

Ich wollte mal nachfragen ob jemand für mich paar Tipps hätte welche Themen ich mir nochmal genau anschauen sollte. Evtl. war jemand von euch in der gleichen Situation und kann mir meine Nervosität nehmen. Ich habe leider gar kein Gefühl dafür welche Fragen dort drankommen könnten.

Ich weiß lediglich, dass mit Java das Backend und mit Angular das Frontend gestaltet wird. Mit Java beschäftige ich mir derweil etwas länger und hab die "Grundlagen" eigentlich drauf. Bei Angular bin ich ganz frisch und habe nur das Tutorial (the way of hero) auf der Homepage von Angular selbst absolviert.

Ferner werden Spring Boot und Maven für die Webapplikation angewandt um eine Microservice Architektur zu realisieren bzw. die monolithische Anwendung in einzelne Services zu koppeln. Dazu sollen auch paar grundlegende Fragen dran kommen.


Ich bin über jede Hilfe und über jede mögliche Frage die dort gestellt werden kann sehr dankbar!


Vielen Dank an alle.

Grüße

Alex

 

[Ebi]

Hi,
Ich bin etwas irritiert, in der Überschrift schreibst du von einem "Bewerbungsgespräch" aber im ersten Satz klingt es so, als ob du den Job schon hast und dort startest. Ich kann dir gerne mal schreiben wie ich Bewerbungsgespräche führe, bin aber nicht ganz sicher, ob das jetzt auf deine Situation passt.

Bei Juniors fang ich eigentlich immer mit ziemlichen Basics an, sowas wie zum Beispiel "Was bedeutet denn Immutabilität und kannst du mir das anhand einer Klasse aus dem JDK erklären?" oder "Was versteht man unter Polymorphie?" Dabei geht es darum einfach mal abzuchecken ob der Kandidat mehr als ein "Hello world" zu Stande bringen kann. Je nachdem wie die Antworten ausfallen, kann man dann weiter gehen in Richtung Designpatterns oder was denn Dependency Injection ist.

Es kann auch mal sein, dass man einen Kandidaten eine kleine Aufgabe auf Papier/Whiteboard lösen lässt. Der Klassiker ist FizzBuzz, aber das ist mittlerweile so bekannt, dass man das eigentlich nicht mehr nimmt, sondern Problemstellungen auf ähnlichen Niveau. Da geht es dann gar nicht mal so darum, ob am Ende das richtige Ergebnis rauskommt, sondern man beobachtet wie du an so eine Aufgabe ran gehst. Denkst du erstmal nach oder codest du gleich darauf los? Stellst du Rückfragen, wenn du etwas nicht verstanden hast? Lässt du den Interviewer an deinen Gedanken teilhaben? Wie zerlegst du das Problem? Da gibt es nicht unbedingt ein richtig oder falsch, wobei natürlich 5 Minuten nichts sagen oder machen und danach aufgeben, nicht so toll ankommt. Hier geht es um die Frage, ob man sich vorstellen kann überhaupt mit dir zusammen zu arbeiten und ob du in das bestehende Team passt.

Danach kann dann auch noch die Kür kommen. Da geht es dann für mich darum, welche Tools du kennst oder ob du zumindest einordnen kannst, wozu sowas wie Maven, Spring Boot, git oder was auch immer für Sachen im Unternehmen genutzt werden, gut ist.

Ein Interview ist für mich in erster Linie ein Kennenlernen. Klar wirst du nicht der einzige Bewerber sein und die Firma wird die Kandidaten vergleichen. Aber mir ist zum Beispiel jemand lieber, der vielleicht noch ein paar Lücken hat, aber wissbegierig ist, als jemand der alles runterbeten kann und denkt er könne gleich als Architekt einsteigen.

Auch ist mir wichtig rauszufinden, was der Kandidat eigentlich machen will. Nicht mit so klassischen HR Fragen wie "Wo siehst du dich in 5 Jahren", sondern ich frag das bei erfahrenen Leuten direkt und bei Juniors dann in so Fragen verpackt, wie sie sich denn eigentlich so einen typischen Tag im Leben eines Entwicklers vorstellen?

Nervosität ist normal und ein guter Interviewer weiß das auch. Man wird zwar versuchen deine Grenzen zu finden, aber in der Regel weiß man auch wann es sich nicht mehr lohnt nachzubohren und wird dich nicht auflaufen lassen. Und falls doch das Interview richtig unangenehm sein sollte, das Interview ist dazu da sich kennenzulernen. Das gilt natürlich auch für die Seite des Kandidaten und wenn das Interview schon unangenehm ist, darfst du dir natürlich auch die Frage stellen, ob du da arbeiten willst.

 

[Alex_Wa]

Erst Mal vielen Dank für diese ausführliche und qualitative Antwort!

Sorry, habe vergessen etwas zu erwähnen! Ich habe in dem Unternehmen bereits ein Praktikum absolviert und habe mich anschließend auf die freie Stelle beworben.

Falls es dich nicht zu stört, würde ich gerne noch paar Fragen loswerden. Bist ja vom Fach .


Falls ich, wieso auch immer, nicht weiß was bspw. Dependency Injection ist oder Immutabilität zwar kenne aber keine passende JDK Klasse nennen kann. Wäre das für dich "schlimm"?

Könnte man auch nach einem Beispiel für etwas fragen, falls man gerade einfach nur auf dem Schlauch steht und die Antwort einem nicht direkt einfällt?

Ich habe hier und da meine Wissenslücken die ich, soweit es geht, nacharbeiten werde. Wäre keine Antwort in Ihren Augen schon ein Durchfallkriterium? Wenn nein, ab wann würden Sie denken: "ne das wird nichts mit ihm"? oder "er wusste zwar nicht alles, aber sein Engagement und Wille war präsent"?


Danke noch Mal für deine echt erstklassige Antwort!! Das hat mir sehr geholfen!


Liebe Grüße

Alex

 

[Ebi]

Falls ich, wieso auch immer, nicht weiß was bspw. Dependency Injection ist oder Immutabilität zwar kenne aber keine passende JDK Klasse nennen kann. Wäre das für dich "schlimm"?

Was heißt schlimm? Also wenn du jetzt ein Praktikum bei mir gemacht hättest, und dort mit Spring gearbeitet hast, dann würde ich mich schon fragen, ob du verstanden hast, was du gemacht hast? Es wäre jetzt nicht so, "Was ist denn Dependency Injection?" und wenn keine Antwort käme, dann ist Schluß. Ich würde dich versuchen dich in eine Richtung zu stupsen, mit so Sachen wie, "Du hast ja im Code bei uns @Autowired gesehen, weißt du denn was das macht?" Aber wenn dann immer noch keine Antwort kommt, dann wird es schon schwierig.

Stell dir ein Interview nicht wie einen Test in der Uni vor, bei dem es 10 Punkte gibt und mit 4 Punkten bist du durchgefallen. Wissen baut auf einander auf, wie Stockwerke in einem Haus. Als Interviewer möchte ich wissen, wie weit ich hoch kommen kann. Wenn jemand nicht weiß, was ein Interface ist, brauch ich gar nicht erwarten, dass eine gute Erklärung für Dependency Injection kommt. Für einen Junior würde es mir schon reichen, wenn er DI kennt. Bei einem erfahrenen Entwickler, gibt es dann tiefer rein in das Wissen und bei Seniors erwartet man dann natürlich schon sehr tiefe Kenntnisse.

Könnte man auch nach einem Beispiel für etwas fragen, falls man gerade einfach nur auf dem Schlauch steht und die Antwort einem nicht direkt einfällt?

Bei mir sehr gerne! Wenn du später mitarbeitetest, dann ist es schlimm, wenn du etwas nicht verstanden hast, aber statt Rückfragen zu stellen, einfach drauf los codest. Das kostet Zeit und bringt Bugs. Kommunikationfähigkeit ist eine Sache die ein Entwickler braucht, das gilt übrigens nicht nur bei Juniors. Es ist besser etwas nochmal nachzufragen, und es dann mit Hilfe hinzubekommen, als gar nicht versuchen eine Antwort zu geben.

 

[Alex_Wa]

"Du hast ja im Code bei uns @Autowired gesehen, weißt du denn was das macht?" Aber wenn dann immer noch keine Antwort kommt, dann wird es schon schwierig.

Danke dafür! Damit hast du mir echt die eine oder andere Sorge genommen.

Kommunikativ bin ich alle Mal. Das haben die Entwickler auch als eine positive Eigenschaft bei mir genannt und ich soll auch weiterhin Fragen stellen, falls etwas unklar ist. Viele Konflikte oder Stopper entstehen einfach durch mangelhafte Kommunikation innerhalb und außerhalb des Teams deshalb habe ich mir rasch angewohnt Fragen zu stellen.

Für einen Junior würde es mir schon reichen, wenn er DI kennt. Bei einem erfahrenen Entwickler, gibt es dann tiefer rein in das Wissen und bei Seniors erwartet man dann natürlich schon sehr tiefe Kenntnisse.

Okay prima. Also geht es in erster Linie gar nicht darum, dass zu 100% die richtige Antwort kommt, sondern, dass einfach in eigenen Worten DI erklärt werden kann. Wäre bspw: DI ist die gewollte Verhinderung von bestimmten Abhängigkeiten die man in einer Klasse z.B. nicht haben möchte. Mir würde vor lauter Aufregung eine solche Erklärung aus dem Mund strömen.


Könnten Sie mir evtl. ein Buch empfehlen, welches genau solche Themen behandelt? Ich habe zwar das eine oder andere Java Buch (Java ist auch eine Insel) mich würde aber interessieren ob es eine Literatur gibt, die genau solche Begriffe thematisiert.


Und noch Mal, vielen Dank für Ihre Mühe, das schätze ich sehr.



Liebe Grüße


Alex

 

[yfons123]

es wäre hilfreich zu wissen was die denn für eine java version benutzen

 

[Alex_Wa]

Die verwenden Java 12

 

[yfons123]

also was ich von meiner arbeit weis ist dass
1. konstrukte aufgebaut worden sind wo man ein paar wochen braucht um sich rein zu denken
2. man sowieso die basics beigebracht bekommt

wenn du direkt "erfahrung" sammeln willst könnte ich mir folgende sachen als hilfreich vorstellen

1. maven projekt mit dependencies: vllt mal javafx maven projekt selber anlegen zum üben oder sonst was
2. git commandos: mal mit konsole git repo anlegen, pushen, commit, einfachen merge conflict lösen
3. Uncle bob: die videos über clean code und Solid

 

[Alex_Wa]

1. maven projekt mit dependencies: vllt mal javafx maven projekt selber anlegen zum üben oder sonst was
2. git commandos: mal mit konsole git repo anlegen, pushen, commit, einfachen merge conflict lösen
3. Uncle bob: die videos über clean code und Solid

Zu 1: Ein Maven Projekt habe ich schon öfters angelegt und verstehe auch die Bedeutung der einzelnen tags (Elemente) sprich: PlugIn, Build, dependencies etc. auch die goals (clean, install etc.) und Maven Profile habe ich bereits selbstständig angelegt.

Zu 2: Push/Pull/Commit und Share eines Projektes habe ich auch während der Zeit dort behandelt und angewandt.

Zu 3: Muss ich mir anschauen kenne ich noch gar nicht! Danke für den Tipp!

 

[yfons123]

 

[KonradN]

Könnten Sie mir evtl. ein Buch empfehlen, welches genau solche Themen behandelt? Ich habe zwar das eine oder andere Java Buch (Java ist auch eine Insel) mich würde aber interessieren ob es eine Literatur gibt, die genau solche Begriffe thematisiert

Das ist meist mit in den Büchern, die darauf aufbauen. Spring nutzt z.B. DI und einige Bücher zu Spring oder Spring Boot behandeln dann auch Dependeny Injection / Inversion of Control.


Ansonsten rate ich dazu, aufmerksam zu sein und bei Begriffen, die unklar sind, dann im Netz zu suchen. Wikipedia bringt dazu z.B. auch schon einiges und die Anzahl der Blogs, die das Thema behandeln, ist wohl sehr hoch

 

[Alex_Wa]

Vielen Dank für die tollen Tipps Leute! Schätze ich sehr .

 

[OnDemand]

Ich musste eine for schleife "erklären" also die Ausgabe nennen was raus kommt und einen alternativen Weg finden, sprich die Schleife etwas umbauen statt for(i=0;...) zu for(Object o : objects) und dann war da noch was mit "wie kann man ojektorientierte Entwicklung" erklären.

Weiterhin kam es bei mir gut an, dass ich Fragen gestellt habe. Die habe ich aber nicht gestellt weil ich dachte es kommt gut an, sondern weil ich es wissen wollte und das Interesse haben sie mir wohl angesehen. Zb welche Versionierungstools sie nutzen, wie die Issues verfolgt und gelöst werden (Jira bla) und wie allgemein die Kommunikation stattfindet, wer Bugs meldet, zuteilt und die Lösung freigibt oder ob jeder fröhlich einchecken kann. Am Ende hab ich dann noch gefragt ob es denn möglich wäre mal einen kleinen Rundgang durch die Büros zu bekommen

Drück Dir die Daumen. Sei einfach du, wenn du aufgeregt bist kann man das auch ruhig sagen das ist sympatischer als einen auf dicke Hose zu machen. Stichwort Schwächen erkennen und auch zeigen.

 

[Alex_Wa]

Danke für das Teilen deiner Erfahrung . Das Einzige was mich etwas Nervös macht, ist, dass wir in der Hochschule bei Grundlagen der Programmierung echt nur das Nötigste angeschnitten haben. Dependency Injection und Co. habe ich mir selbst angeeignet. Auch das "Coden" haben wir mit Python und nicht mit Java gelernt. Deshalb wird die eine oder andere Lücke vorhanden sein. Deswegen bin ich etwas vorsichtig und lerne zurzeit nochmal die Grundlagen soweit es geht. Etwas stressig, da ich zurzeit noch meine Bachelorarbeit über Microservices schreibe und eine Seminararbeit zur gleichen Zeit abgeben muss.

Nochmals vielen Dank für deine Nachricht .