4 shortcuts to your job in Germany
What we learned from reading the 'inside notes' from tech recruiters.
Hi everyone,
hope you are staying positive and testing negative.
This month we share some lessons learned from those who came before you. Fellows who now have jobs in Germany but did not make it through the process in other companies.
The cool thing: We got to read what the tech recruiters said internally, and thus got to learn how they decide whom to admit and whom to reject for a job.
So: read the below & shortcut your way to a job in Germany.
Best, Your Friends at Team Imagine
Congrats — you got invited to a first-round interview with a company like GetYourGuide or DeliveryHero in Berlin?
Awesome.
Now it’s your chance to shine. We have seen many of our Fellows pass through HR interviews, technical tests, and final round interviews & succeed. We’re super happy for all of them. To read their stories, see how Mahmoud or Ahmed did it.
These two and many more have made it. But not all have. We have seen wonderful, qualified people lose. Sometimes we wonder: Why do some make it and others … not yet?
In our work with firms we can sometimes look behind the curtain and see what firms write about applicants. We reviewed some of these notes by the recruiters.Here are 4 lessons and a little hiring secret we learned from them.
Lesson #1: Show recruiters you *care* about working at their firm.
Companies choose you if you choose them. It’s not about being prepared, but showing you WANT to join the company. You need to have answers to basic questions like:
Why do you want to work at [my company]?
What do you like about our product?
Do you like [tourism] and can you understand our customers?
Lesson #2: Make it *easy* for people to understand you
If you are reading this, chances are high that your English is good enough. But talking in English over the phone or video chat is difficult, for all of us. So, to make sure recruiters “get” you, and you understand what they’re saying, do these 3 things:
Do the video call from a place where you are 100% uninterrupted with a great wifi connection. Test it with a friend before the call. Do not do it from your employer’s coffee kitchen (true story, it did not go well)
Prepare a few phrases on yourself, effectively answering the question “Tell me about yourself”. Make it short, and precise — do not talk too long without giving the recruiter the opportunity to ask a question. E.g. “I am Ahmed, I’ve a degree in computer science, have coded for X years and full time since college for Y years. I’ve spent most of my time on Java with Spring and recently got into AWS/Docker etc… I am working at company X which is in the field of Y. We build products helping customers do Z.”
In case you don’t understand exactly what the recruiter says, ask back but not by asking. Instead, say: “let me paraphrase, you want to know about my skills in Python, right?” That way you confirm without asking, and the recruiter will feel understood.
This feedback illustrates lessons #1–#4.
Lesson #3: Speak *plain* English, no geek speak
Believe us, you get rejected if you’re speaking only in too technical language. It does not make you sound smart. It makes you sound aloof.
Sure, tech people love great engineers, and great engineers may not always be wonderful communicators… yet: in interviews with HR people *and* also with engineers like you, you need to show that:
You can communicate your thoughts in non-technical ways
You know the customer of the product & what problem you solve
So, here’s a little trick:
Say “here is the non-technical answer”, followed by something in plain english.
This signals to your interviewer that you understand that there are at least two different modes of communication and that you are aware that you can switch between both.
Lesson #4: Take the coding challenge seriously. Seriously.
We have seen great engineers fail coding challenges not because they did not submit a good solution, but because their execution was sloppy.
Firms in Berlin have high standards. Not unreasonable, but high. “Good enough” does not cut it in the coding challenge. Instead, invest 15min more of tidying up and testing 1–2 more edge cases to get you across the line.
Let’s look at the most typical errors:
Details: Unnecessary code, commented out code, not defining variable types
Sloppy reading: Probably 20% of test-takers will — if they get asked to create a table by variable “city” create one using a different variable. Like region, or product. Read the question prompt carefully!
In addition, read this read feedback from a recruiter below: This Imagine Fellow did submit a good solution, but deviated too much from established convention and added some impurities in the details - he was out.