How we hire at Scrivito

I hire people since 20 years. I’ve co-founded a software company in the 90ies which is still doing pretty great. Beeing responsible for our software products, I’ve conducted hundereds of job interviews in the last years.

Frankly, I don’t understand why interviews are nowadays appearently done the way they are done. This reminds me a bit of high school, when you had to learn a lot of useless stuff just for the sake of it. Especially in the fast-changing tech world that’s superfluous. If I need a certain algorithm, I just look it up. That’s what the Internet is there for, right? Knowing it out of the blue is great and maybe important for 1% of super algorithm-heavy jobs, but definitely not for the majority of programming jobs. And particularly not for a front-end developer.

I definitely prefer interviews the informal way, like you described your first interviews at Vimeo. I’m interested in the experiences people had and how they learned new things. A good programmer can (and has to) definitely always learn any new stuff, so I’m rather interested in how curious people think, their ability to learn stuff in the future and not what they already know. I definitely don’t believe in some strange whiteboard exercises (which maybe the interviewers wouldn’t pass themselves). If you’ve got your fine projects on GitHub and I can take a look at them, I know that you know how to code.

I’m also a bit astonished of the complete lack of any social compatibility questions in the interviews you’ve experienced. In my opinion, the “how-does-a-person-fit-into-the-team”-Question is at least equally important as the technical skills.

At Scrivito, we’re only doing one round of interviews (if the person can’t visit us in our office, we do a Google Hangout beforehand), usually with me and a senior developer plus a person from HR. After doing the interview in an informal setting where we talk about your experience, your past projects and how you solved problems so far, you know whether the person is generally capable or not. Generally it’s a good idea to trust your gut in that regard.

After the interview everybody who took part has a veto right against the candidate. You don’t have to bring detailed reasons, a “I don’t have a good feeling with this one” is usually enough because it’s almost certainly right.

If everybody has a good impression after the interview, we invite the candidate simply to work a day together with our development team on their everyday’s work. After this day, you usually know not only whether the person is technically capable but more importantly whether he fits into the team.

And also the other way round. Does she want to work with us? I think, a job interview is definitely also a two-sided question. She’s applying at us, but we’re also applying at her. Or at least that’s the way it should be.

At the end of the day, the question is always to the team: Would you like to work with this person or not? And besides all the technical qualification, this is the most important question to form a great team of people who actually like to work together. So if anyone in the team has objections, we don’t hire.

So the finally hiring decision is usually not made by me or HR; it’s the team.

This technique served us very well — and we were generally right with our decisions in 99,9% of all cases. The result is that we’re having really a world class team of developers working on our products, which I am really proud of.

As a rule of thumb, we try to keep our interview process in a way, that a) we’d still like to apply at our own company and b) would still hire ourselves.

Or to quote Elon Musk:

My biggest mistake when hiring is probably weighing too much on someone’s talent and not someone’s personality. I think it matters whether someone has a good heart.I couldn’t have said it better.

Let’s hope Eric, Sergej and Larry can write maze solving algorithms on a whiteboard.