Have you got an upcoming Developer Interview? Gaurav Singha Roy has written a handy guide on how to prepare so you can go in feeling confident! You might also see that Signify have sneaked into this article, thank you to Gaurav for the recommendation!
Before we begin, please note that in no way what I speak about in this article can be considered a good way to crack an interview or is applicable to all jobs in Germany. These are simply ramblings of a mere software developer, observing his eco-system in the last 9 years, and I have not really conducted a thorough research on this.
Many people like myself, who have given lots of job interviews during campus placements in India are used to getting questions like “There are 4 rabbits, holding 3 balls each of different colors. When a lion passes by, what is the color of the first ball that was dropped?”. This was termed as the “aptitude” section of the interviews. While, many would argue that this sounds like a good way to determine the thinking of the interviewee, this does not establish if they know how to write good clean code. With more and more startups cropping up, they tend to go for “battle-ready” developers, who already know to be get up to speed in any environment with the minimum time. This, means, it is hard to even find interviews where they won’t ask you to write code.
Usually, a company’s selection process consists of the following sections
- “Virtual” selection round: In this section, a candidate is considered by the HR or in some cases recruiters, to be a probable candidate. This is usually done through various means which I would talk about later.
- “Fitting” round: In this round, you would generally have a quick call with the HR of the company, where they would establish if you are fit for the role. In my experience, this is simply a skype/telephone call for 15–20 minutes.
- Code challenge: This round is generally remote, where you are asked to solve a particular code challenge. This could range from anywhere between 1 hour to even a couple of days in some cases. So be prepared to invest some time into this. Also, you might have a quick one hour interview after your code challenge has been submitted to discuss your solution.
- Onsite interview: Here, you will be invited to be interviewed in the office. This can be up to 3–4 hours depending on the company. Most of your interview would consist of technical rounds.
- Manager round: This is the last round of your interview, where you will be interviewed with the head of engineering, the CTO, etc. depending on the size of the company. They would get the final say to your selection and you can usually discuss your employment terms in this round, like salary, etc.
I will not talk much about the Fitting round and the Manager round. I would focus more on the other rounds and try to come up with some simple tips to be better prepared for them. But before we jump into them, lets have a quick look into where to find job openings.
Where to look for jobs
- Social media: The quickest way to connect with prospective employers is of course through apps like LinkedIn. In Germany, xing is also quite popular but I have seen a decline in its users over the years. Look into stackoverflow as well.
Recruiters: Well, this is a grey area for me. Finding jobs as a developer, and getting good talent for a company is quite stressful. This gap is filled by many recruiters who help in handling this in a quick and easy way. There are a lot of advantages to having a recruiter, since you do not have to worry about those awkward conversations where you negotiate your salary, or following up on your process. Unfortunately, it will serve you good to be a little wary of recruiters, as most of the ones I have come across treat it like a sales position, and you are simply a number to them. Many, won’t do their homework, and you would end up getting “Java roles requests” just because you say your university degree thesis was in Java. Try to look for recruiters, who are knowledgable in your technical domain, transparent with the processes, and of course respect your decisions. Many developers would be probably rolling their eyes now, but I have come across some good chaps as well. Off the top of my head, I could think of Signify. Recruitment companies with narrower focus are generally good.
Recruitment platforms: With the ever growing need to have apps for everything, there are many recruitment apps. In this, you can connect potential roles in a safe way and secure way where many parameters like salary, etc. are transparent. Best way to find them is to simply google for specific job openings, but do check out these websites : talent.io, 4scotty, honeypot.io, functionalworks, angel.co, etc.
The “virtual” selection
So, here is a very important round. In this the companies generally look at your profile, your linkedin account, stackoverflow, github, etc., basically to find any tech-like traces of you. My advice would be to always have your linkedin profile updated with very brief comments on each job position without it being too verbose. Also, if you have some good open source projects on github then that would be quite helpful. But if you are like me, and have worked predominantly with private enterprise solutions, then maybe now is the time to build some small and helpful libraries which you always thought would be useful and put them up on github. Read up a little on better git commit message standards, and these habits will not only impress your future employer but you would also make a lot of friends in the tech universe. You get extra points for adding more integrations to your projects like, codecov, travis etc. Another useful tip is to write tech blog entries if you can (No, thats not why am writing this blog post ). This can be a bit daunting, but I remember a colleague advising me about this, “just write. Have weekly to bi-weekly posts. The more you write, the more easily you can express yourself on certain technical challenges”.
Not many companies would hire your as a developer without seeing your code first. Checking code which you have published in public repositories is well and good, but there are certain things an organization cannot predict from it, eg, how long did it take you to build that, is it your own or was it plagiarised ? In general I have noticed there are usually a couple of different kind of code challenges.
First, is an online challenge where you would need to write code to solve medium to difficult algorithms in a short span of time. These challenges could range from anywhere between 1 hr to 4 hrs. These are timed tests, and you would have to solve them in your own time. My advice for you on this would be to prepare for some sample ones on Hackerrank, codewars. It will give you a lot of confidence and you would be able to solve a lot of challenges quickly. Another tip would be, to have an editor ready when you are writing these challenges since its hard to see compilation errors on a web interface, which you could spot quickly on your editor. So simply use your own editor to solve these, but then again, its a personal preference.
“Build an API server using your favourite ruby web framework, which supports the following API actions. blah blah blah. You need to retrieve the result by fetching them from the public API blah blah blah. ” Sounds familiar ? This is the Second kind, a longer code challenge which you would have to solve in your own time. This generally is not timed but the company expects you to solve this in roughly 6–12 hours. Now if you look at the problem, you would notice that it is a full fledged mini project, which you are expected to solve in a short period of time. So you would have
- Basic project/framework setup
- Code organization/Design patterns
- Solve the problem
- Unit/functional Tests
If you objectify the aspects you have to solve, you can easily practice #1. Say if you are a go developer and you are applying for backend developer positions, then practice writing api servers with it. Have a set template ready with you so that you can quickly refer to when you have doubts. Same applies to #4. You can quickly refer how you wrote tests to simply write tests for your project. This is crucial, and we are actually living in an era where not writing tests is not just considered bad, but its simply unacceptable. I remember when we were recruiting for developers, we would not even look at the solutions which did not have Unit tests. So my advice on this would be to really practice writing unit tests, and lots of them. Now #2, ie the design patterns are something which one picks up from their experience. There is ideally no right way, but having a particular path is always good. eg, if you are not a bit fan of OOPS and want more FP, then you can simply organize your code in such a way that you do not have a lot of mutations in your classes and simply have helper singleton functions. Finally on #5, since you probably would be building a full fledged project which your future employer is gonna evaluate on their machines. You can add docker files to your projects so that the reviewer can setup your project hassle free. This does not take much time if you have already practised with it in the past and you will score a lot of bonus points. Thus remains #4, which is basically your code challenge and probably will take 15–20% of the total time. Only this part should come out as a surprise in your code challenge
If you have cleared the above rounds, then you are generally invited to visit the office to have further interviews. This will be a deeper technical interview and could even be some pair programming challenges. Be prepared to set aside at least 4 hours on a work day for this. Since this is quite generic, I cannot give specific tips on how to prepare for this. Go with your gut feeling, and study whatever you feel would be useful. Studying on particular languages, its Garbage collection strategies, algorithms, etc usually helps. Almost forgot, the dressing is fairly casual in Germany. Its quite alright to interview in your favourite jeans and t-shirt.
While many of these processes seem daunting and exhausting, it does raise a question, why this long ? Am I getting paid to write code for such long interviews ? Companies are adapting and preferring more shorter processes more and more these days. But at the end, this is something you have to go through and don’t be disheartened if you did not clear certain rounds. Simply learn from it, and do better next time. Good luck and do share your experiences !'