Back in 2016, I was exiting a startup in Berlin after a disastrous year at a health-tech company. After this, looking for a job at the C-level as a non-native in a country was an interesting experience — in short it’s very very very difficult so think very carefully about putting yourself in that position.
If you’re looking for technology roles in Berlin (as an engineer or other) expect the process to be long (sometimes it can take months). I spoke to several of my startup colleagues (who are also great friends) about their experiences as well in Berlin.
The following aims to encapsulate that experience and provide it as advice back to tech companies in Berlin. Don’t tread the same, sorry, horrible path as a company — you’ll hire better, happier, nicer people. Be better than the companies I met along the way!
Short Advice on Moving to Berlin
- It’s incredibly hard to find an apartment in Berlin — I cannot emphasize that enough — it took me five months and then only through luck. Start with a room, or look for something well outside the city. The demand is utterly nuts.
- You have to have health insurance (and it’s not cheap). I was paying 500 EUR a month fo private health insurance.
- Be prepared to go through all kinds of bureaucratic nonsense with documents at the Burgaramt. You can ring them and book an appointment. You don’t need to wait in that ridiculous queue for them to tell you Nein — come back with translator.
- Try and learn some German — you’ll be surprised how attitude (and there’s lots of it) change when you can say hello, ask questions, order a coffee etc… Google Translate is your friend!
More info here in a great Medium article:
What I Learned Moving to Berlin- 10 Lessons from an American Expat
When was the last time you had to begin all over again?
CTO Hiring Duties
As a CTO building a team I ended up:
- Writing the job specs and adverts
- Managing the posting (although I had lots of help with this) to job boards
- Dealing with technical recruiters
- Telephone and face to face interviewing candidates
- Negotiating and making offers to them, based on compensation advice provided by the company and the incubator we were at.
All the hires we made were direct hires — not through an agency. It was a super multi-cultural team also. Don’t expect to find an all German engineering team — it won’t happen.
I should mention that I had some great support and help of our head of HR who made this process much easier for me (thanks Fran). I learned some new things along the way for sure.
This is suitable for developers, technical leads and CTO’s primarily looking to hire. In summary, the recommendations are as follows:
- Complete the interview process in 1–2 weeks
- Ask candidates for a cover letter and project summary
- Two interview stages maximum
- Telephone Interviews — Suggested Structure
- Face to Face Interview — Suggested Structure
Complete The Interview Process in 1–2 weeks
Above all, you should be aiming to complete the interview process within a week to two weeks maximum — all stages including candidate CV review. If you take longer than this, especially in Berlin where the market is incredibly competitive then you’re going to lose out on the good candidates.
Job Specification and CV Review
I think a CV is a poor way to judge candidates, but it’s what we’re used to historically. Normally as part of an application, it’s good to ask for some additional information on a candidate, besides the CV:
- Cover Letter — describing existing experience, aspirations, and motivation. I’ve originally didn’t see the benefit of this, but in hindsight, I think it’s a good way to demonstrate what you’re looking for and where your core experience is in a summarised form. It’s more difficult after 10 years of experience for sure!
- Online Portfolio/Profile — generally to look for what else a candidate does outside their work time. It could be a portfolio of the candidates work — their Github/Bitbucket profile or it could be their SlideShare or personal blog. You’re looking for people that care about what they do.
Two Interview Stages Max
At most, there should be two interview stages and you should aim to get as much done as possible in the second stage. Front-load the telephone interview with the culture fit questions as well — for your benefit as well as the candidates in terms of being time-efficient.
Telephone Interviews — Suggested Structure
I’d suggest the following structure for the telephone interviews you carry out with a candidate. Above all, try and ensure you’re in a quiet place, with no background noise (as an interviewer and a candidate).
- Fundamentals — Establish candidate expectations of the role, their salary expectations — there’s absolutely no point in continuing past this stage and wasting everyone’s time if these are not in-line upfront.
- Core Competencies — Ask technical questions to establish the basic knowledge for the fundamental languages, frameworks, libraries you are using. It should be absolutely clear from your job advert what the essential and desirable skills are. This is about establishing whether the candidate has the basic fundamental knowledge required to do the job.
- Technical Test — The infamous technical test — it’s got be done — people need to see your code and the solution to a problem. It’s normally advised that you don’t produce a problem that takes more than four hours to complete. Remember the poor candidate might have done four of these already. We’ve generally given the test after the initial phone interview for them to complete prior to the face to face interview. That way you can use the interview to review the solution. In some cases, in the interests of speed when a candidate has an offer on the table you need to move fast. Push the technical test into the second stage and do it on the day in some form.
Face to Face Interview — Suggested Structure
I’d suggest the face to face interview is primarily about reviewing the technical test, getting an in-depth view of the candidate's technical skills in terms of libraries/frameworks and the way they think. You should also be looking to do your cultural fit here.
- Technical Test Review — walk through the technical test with the candidate — do a review, ask what could be done better and find out if the developer is able to take criticism. We’re funny old things, but if you can’t take constructive (and I mean that) criticism of your work, then working with a team is going to be a problem. There’s another side though. Please don’t be overly critical of someone’s work — it sucks — there are several ways to deal with problems. Being aggressive, condescending or making the candidate feel uncomfortable is not cool. It’s also not senior developer qualities — consider a Udemy course in being humble if you think it is. Be polite, ask inquisitive questions and try to make the candidate feel as relaxed as possible.
- Design Test — yeah I know, we all hate coding on the whiteboard — but you can instead give a developer a laptop, leave them alone for 15 mins and ask them to complete the problem instead while you make them a cup of tea/coffee/club mate instead. It could be pseudo-code also. It absolutely should not be about “parlour tricks” either — a simple understandable problem with multiple stages of achievement. Forget the sum of square roots, finding the longest sub-string and all that. If algorithms are important to you, fair enough, but for most of us, it should be about problem-solving skills instead.
- Career and Motivation — most companies want people who are motivated to learn more. I firmly believe if you’re not learning a new language, reading Reddit Programming, Hacker News etc… in order to learn how to do your job better, then a developer role is not the job for you. Check for intrinsic motivation in the candidate (rather than extrinsic money-focused). Check their desire to learn new technology (but not apply it carte blanche in a CV driven development manner). Check their ability to pick up older technology and legacy code if needed — we all have to deal with it after all.
- Meet The Team — I think this is crucial. People need to understand who they’re going to be potentially working with. Get the candidate to ask questions about what the team members do — include developers, ops, QA etc… it doesn’t have to be lengthy — 5 minutes with each person. It gives you a much better view of the candidate from their perspectives.
I’m a consulting CTO (fractional/interview) working/living in London (not Berlin anymore — I gave up and got out). You can find more information here (and hire me as a consultant):
Interim/Fractional CTO Services and Technology Consulting We've helped facilitate the success and growth of…
If you want to talk about my experience in Berlin then holler and buy me a coffee. Happy to chat.