Technical interviews at Futurice

I have been conducting a good amount of technical interviews with programmer candidates to Futurice. I used to think that our ways of interviewing programmers were similar to what the rest of the world was doing. However, Futurice is the only company where I have worked for so far in my career, besides my own startup. When I heard from friends that have applied to top companies in Silicon Valley that their interview processes involve computer science specifics on the whiteboard and feel like an exam evaluated in real time, I was shocked.

Even though I enjoyed my time at the university, I always hated exams. They put a lot of pressure on you: you have N questions in front of you and the clock is ticking. But I still had some peace to think alone and perform the tasks, because the professor would evaluate my answers only after I delivered my papers. Now imagine that situation, except the professor is sitting in front of you, evaluating you while you are trying to answer the questions. It suddenly becomes daunting. It paralyzes you.

That is how some interviews, in my opinion, are conducted wrongly. The interviewers have a list of specific questions and the candidate will be evaluated in real time. If any one of those questions fail, the candidate scores less, and may not get the job.

We try to keep the candidate comfortable.

Technical interviews at Futurice are samples of the candidate's skills, not exams. Sampling and examining may sound like synonyms, but there is a difference. In an exam-like interview, each question needs an answer, and each failure counts. In a sample-like interview, the more we sample, the more accurate our understanding of the candidate's skills will be. So if at any point the candidate gets stuck with a question, we switch to another topic that we want to sample, to try to keep the candidate comfortable. On a whiteboard or not, the goal is just to sample your skills.

People are comfortable talking about things they are highly skilled in.

Of course, if the candidate fails in all the samples we take, that probably means they are not a fit for us. We want to look for those topics that the candidate is comfortable talking about, because people are comfortable talking about things they are highly skilled in. That's why sometimes we may need to switch topics a lot until we discover their core skills.

Keeping them comfortable is not just about discovering competencies: we also want to respect the candidate. All of us had to pass through a job interview at least once in our lives, and we know being interviewed is to be in a vulnerable position. You want a job, or maybe you need a job, and it all depends on that one or two hours being evaluated by the interviewers.

Even if we don't find a match, we want that process to be fair also to the candidate. And often fairness boils down to simply transparency and respect. If we respected them during the interview and made it very transparent what skills we need for the business, then the candidate may be able to conclude themselves that the outcome was fair.

We are looking for proficient programmers with good communication skills.

Because our work is so diverse, our job descriptions are usually generic and do not sound like we are looking for specific skills. In reality we are simply looking for proficient programmers with good communication skills.

We have usually phrased this as: smart, gets things done, and is nice to work with. But to avoid misunderstandings about what smart means, we have some more specific criteria. "Smarter than me" has been a good rule of thumb, but we look for other qualities too. For instance we value craftsmanship, the independent drive in making better and more organized code.

To guide myself I have come up with a simple framework to sample proficiency in programming. A proficient programmer is able to think on three levels of abstraction: low, mid, high.

Levels of abstraction when programming: low, mid, high.

Programmers who think on the lower level are analytical and can read code like a compiler does. They are detail oriented and know how primitive operations work in their programming language of choice. When they find a bug, they are able to pause their feature-building enthusiasm and dig deep into lower-level code until they uncover the root cause of that bug. An example question that samples your low level knowledge is: in which cases does JavaScript create a scope for variables? Got stuck with that question? No problem, we can skip it and talk about another one.

Programmers who think on the middle level are doers and know they have a mission. They can imagine the software ready and plan their course of action. They know how to reuse existing libraries and integrate them in order to build features. They know how to use frameworks and libraries. They understand that business has goals and limited time, and they get things done. An example question on mid-level knowledge would be: how would you go about creating a currency converter with frontend technologies? Can you code it now?

Programmers who think on the high level are architects and can organize code without necessarily seeing code. They know how different design patterns help achieve goals while keeping code maintainable. They have empathy and carefully consider how other programmers will appreciate the code structure when joining the project. When faced with a mid or low level problem, they stop to reconsider their overall approach. An example question for this level is: what kind of technical debt do you allow and what kind do you forbid?

We look for programmers who can think in all of these levels. If they only think in the mid level, they may actually get things done, but are constantly dependent on StackOverflow or the web when they hit bugs or technical problems, and rarely consider the architecture. A person with only low and high level programming proficiency is a computer scientist, but not necessarily a builder of software in production. Futurice needs all three.

The job of a software developer actually requires all three levels. Low-level programming is needed for overcoming technical obstacles and fixing bugs. Mid-level programming is vital for actually building software. High-level programming is important for troubleshooting and ensuring the future maintainability of software.

It turns out that transparency in the interview process makes it easier for the candidate, and fair for everyone. Futurice embraces openness in other aspects as well, like open source. So why not share our interview process too? It is rather straight-forward, and already published on our blog.

So don't be afraid. We don't have any surprises; it's all laid out and open. If you're looking for a forward-thinking consulting and software development house, and you believe you're that proficient programmer we described, we're looking for you. Send us an application, and let's talk. :)

Written by:

Andre Medeiros User Interface Engineer