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

  • 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:

CTO Hiring Duties

  • 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
If you wait, it won’t come to you. Go get it.

Complete The Interview Process in 1–2 weeks

Job Specification and CV Review

  1. 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!
  2. 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

Telephone Interviews — Suggested Structure

  1. 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.
  2. 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.
  3. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

About Me

If you want to talk about my experience in Berlin then holler and buy me a coffee. Happy to chat.

Consulting CTO (Interim/Fractional) — https://www.hwintegral.com