There are many things which keep us developers shrieking and hiding behind oak doors. Be it Bugs, Incidents, KPIs, Javascript, YAFF (Yet another Frontend Framework), Game of Thrones spoilers — the mention of these is enough to send cold chills down our spines. But nothing compares to the agony of going through tedious and lengthy procedures to crack a job interview.

I will try to generalise the process, give some tips on how to handle different areas (more focussed on the tech aspect of course). 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 ecosystem in the last 9 years, and I have not really conducted a thorough research on this.

The Structure#

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 how to get up to speed in any environment in 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:

  1. “Virtual” selection round: The 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.
  2. “Fitting” 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.
  3. 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. You might also have a quick one hour interview after your code challenge has been submitted to discuss your solution.
  4. 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.
  5. 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 (salary, etc.) in this round.

I will focus more on the Virtual round, Code Challenge, and Onsite interview, and provide some simple tips for each.

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, though I have seen a decline in its users over the years. Stack Overflow Jobs is also worth a look.

Recruiters: This is a grey area for me. Finding jobs as a developer, and finding good talent for a company, is quite stressful. This gap is filled by many recruiters. There are advantages to having a recruiter — you do not have to worry about those awkward salary negotiation conversations or following up on your process. Unfortunately, be a little wary of recruiters, as many 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 role requests” just because you mentioned Java in your university thesis. Look for recruiters who are knowledgeable in your technical domain, transparent with the processes, and respect your decisions.

Recruitment platforms: There are many recruitment platforms where many parameters like salary are transparent. Some worth checking: talent.io, 4scotty, honeypot.io, functionalworks, angel.co.

Online listings: Popular websites for openings: indeed.de, berlinstartupjobs.

The “Virtual” Selection#

This is a very important round. Companies generally look at your profile, LinkedIn account, Stack Overflow, GitHub, etc. — basically to find any tech-like traces of you.

My advice:

  • Always have your LinkedIn profile updated with brief comments on each job position without being too verbose.
  • If you have good open source projects on GitHub, that would be quite helpful. If you have worked predominantly with private enterprise solutions, now is the time to build some small helpful libraries and put them on GitHub.
  • Read up on better git commit message standards — 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 integrations to your projects like codecov, travis, etc.
  • Write tech blog entries if you can. This can be daunting, but a colleague once advised me: “Just write. Have weekly to bi-weekly posts. The more you write, the more easily you can express yourself on certain technical challenges.”

Code Challenge#

Not many companies would hire you as a developer without seeing your code first. In general, I have noticed there are usually two different kinds of code challenges.

First kind — online timed challenge: You would need to write code to solve medium to difficult algorithms in a short span of time, ranging from 1 to 4 hours. My advice: prepare with sample ones on HackerRank and codewars. Also, use your own editor to solve these challenges — it is hard to see compilation errors on a web interface that you could spot quickly in your editor.

Second kind — longer take-home project: Something like “Build an API server using your favourite web framework, which supports the following API actions…” This is generally not timed but the company expects you to solve it in roughly 6–12 hours. If you objectify the aspects to solve, you get:

  1. Basic project/framework setup
  2. Code organisation/design patterns
  3. Solve the actual problem
  4. Unit/functional tests
  5. Containerise (Docker)

You can easily practice #1 and #4 in advance. Say if you are a Go developer applying for backend positions, practice writing API servers with it. Have a set template ready so you can quickly refer to it when you have doubts. For tests — we are living in an era where not writing tests is not just considered bad, it is simply unacceptable. I remember when we were recruiting, we would not even look at solutions which did not have unit tests. So practice writing unit tests, and lots of them.

For #5, adding Docker files to your project means the reviewer can set up your project hassle free. This does not take much time if you have practised with it before, and you will score a lot of bonus points.

Onsite Interview#

If you have cleared the above rounds, you are generally invited to visit the office for further interviews. This will be a deeper technical interview and could even include some pair programming challenges. Be prepared to set aside at least 4 hours on a work day.

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 particular languages, their garbage collection strategies, algorithms, etc. usually helps.

One last thing: the dress code is fairly casual in Germany. It is quite alright to interview in your favourite jeans and t-shirt.

While many of these processes seem daunting and exhausting, companies are adapting and preferring shorter processes more and more these days. But at the end, this is something you have to go through. 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!

Originally published on Medium.