Hi JonasVP, a little late but regarding your original question...
We were building a tech team at a start-up in Germany.
Our hiring process evolved and stabilized into the following process, which worked exceptionally well for us:
1. Review of written documents, accepting any kind, any style and any medium.
2. Telephone interview with recruiter from HR about motivation, personality and the formal aspects of education and experience.
3. Personal interview with VP of engineering. Future employee is asked to bring some of his or her source code to the interview, any language any style any form is good. We don't copy the code, we don't keep it, we don't use it in any way. This is the only technical interview.
4. Interview with the CTO, immediately following. This is the most important social interview, and it also contains the main salary negotiation.
5. Decision.
Between any of the steps, we would briefly exchange our impression of the candidate, and it turned out that it is wise to sleep a night before taking the decision.
My function was VP of engineering and lead architect, and I would conduct the interviews of step 3. My principles are as follows:
- Keep the candidate at ease as much as possible. We want developers to crack hard problems with "feet on the table" as the Dutch say, most of the time. Stress distorts things, and I want to see the undistorted version.
- Get to know the candidate, and what makes him or her tick. This requires respect, tact and genuine interest in the person and his or her achievements.
- Estimate the fit with team and company. I can talk a lot about this---but in the end it either feels right or it does not.
- Gauge the technical capabilities of the candidate. For this I let the candidate choose a piece of the source code at will and have her explain what it does, and why it is the way it is. For all our hires, some form of dialog on software architecture in general emerged. This usually takes between 10-30 minutes.
- Do your best to get the candidate interested in the company. For this I do not advertise the benefits of the company but simply explain what the company does, what the software we create does, which languages and systems we use and maybe even demo some of it live. Also I explain the risks of working for a start-up company to the less experienced candidates.
I don't do programming exams of any kind. Interactive exams exhibit dangerous positive feedback: you start with something in the middle. If the answer is good you make it more difficult. If the answer is bad you make it easier. Repeating this quickly converges to either extreme, which means you missed the chance to learn something more profound about the candidate, and even risk loosing suitable candidates at split-second blackouts. I don't like take-home exams either, although they are all the buzz these days. A take-home exam is a large investment for the candidate, and most of the people I hired never even touched the programming systems we were using (Erlang, Python, Ocaml, GLPK to name few). All hires did exceptionally well after a few weeks, and with a little bit of guidance. So what could a take-home exam tell me? Even worse, take-home exams are supposed to reduce the risk for the company, at the expense of the candidate. But do they actually do that? At what price? In addition, the large German probationary periods provide an easy way to correct mistakes later, which I had to do only twice so far.