Jess Lee

Posted on May 22, 2017

How does your company conduct interviews?

#discuss

Top comments (5)

If possible, it begins with a short (5-10) minute phone conversation to explain the process and answer any questions. If the person has a disability, we'll opt for IRC/XMPP/Email/Slack/whatever.

Our process is then:

We ask the candidate to email us their SSH public key.
We give them access to a git repository that contains a sample application.
The candidate is then expected to add a small feature, specific to the type of work they'll be doing. We might ask a frontend designer to add mobile-friendly navigation. We might ask a backend developer to add a search feature. Third party libraries are OK. This should be time-boxed to less than 4 hours of work.
Candidates are expected to email a patch file with their changes, any unit tests they wish to include, etc.

We then evaluate the candidates objectively:

Did they solve the problem they were tasked with?
Did they write unit tests for the new features?
Is the code easy-to-read and/or well-commented?
- Does it pass static analysis; e.g. psalm?
Did they find and fix any of the intentional security vulnerabilities in the sample project? (If we're hiring for a security position, this is a must.)
How extensible and maintainable is their solution?

We make our hiring decision based off these metrics. Over time, we plan to add better metrics and cull the ones that aren't a better predictor of excellent hires.

We do not look at resumes, CVs, etc.

We do not whiteboard candidates. We do not fly anyone anywhere for a stressful in-person interview.

Ben Halpern • May 26 '17 • Edited

We have two steps in our process:

Take home questionnaire

This really helps us determine how a candidate thinks through problems, how much they fit the position, and helps them put their best foot forward. It is enough work that we can tell who mailed it in, but not so much that candidates need to upend their whole schedule to accommodate us.

Interviews with the team

Each member of our team taking part in the interview process (typically everyone in our small team) conducts individual 15-20 minute interviews with the candidate, usually back-to-back. Each member of our team will evaluate the candidate on areas they are most capable of evaluating (some more technical than others)

My interviews will typically consist of walking through their code and asking questions, then we may walk through our code if it is relevant and they ask us questions. I am looking to tease out a candidate's current understanding of topics, potential and willingness to learn, and interest in our mission. What I don't do is code trivia or riddles and the such.

And if we need another interview, we will do it.

In general

We try to optimize for capable candidates, not for ones with enough spare time to jump through circus hoops for us. The best candidates are not necessarily the ones most capable of taking on an arduous interview, and we think there are diminishing returns and enough uncertainty that we try to streamline the process whenever possible.

The most important part of our process is that we all fill out individual surveys after each contact point without consulting one another. We do this to insure we don't bias each other and get true wisdom of the crowds benefits. After everybody has filled out their surveys in private, we come together to have discussions about our candidates, fight for ones we liked, etc.

I'm pretty happy with our process so far.

Victor Schröder • Feb 4 '17

Here we go like this, after we get the candidate application:

CV analysis, not very strict, but some things are no-gos, like lack of care with the application
Short email asking availability, salary expectation and relocation possibilities (most applicants are foreign)
Short phone call with the product manager, to check cultural fit and basic communication skills
Deep technical interview (using hangouts or skype), with a bunch of Q&A and lots of talk, but no hands on. It servers to access the candidate level of understanding of the technology and how curious they are. Some matches or divergences in terms of values become clear at this point
Technical assignment. Git repo, 3-5 days to develop something according to the instructions. Unit tests, clear architecture and clean code are the most important points here
Remote pair programming session, following coder/breaker pattern or refactoring exercise. It's done on the terminal with tmux and vim through an AWS instance

Each step is proceed only if the candidate passed the previous one. Sometimes, people can get approved somewhere in the middle of the process, when the match becomes obvious.

Gábor Nádai • May 26 '17

This is a really great question and I've found a lot of inspiration in the answers below.

Our company has about 130 employees, so we have a lot of effort to make our process smooth and effective.

Screening

Looking for candidates

We are doing both direct contacts to potential candidates through LinkedIn and also listing our open positions on our website, social media and other platforms.

Our HR doing a great job finding new developers, but we also have recommendations from our fellow colleagues.

Short phone talk

If it is possible, HR makes a short phone call to the candidate, asking a few general question (starting date, salary, current job etc.) and explaining our recruitment process.

Online questionnaire

At this point, candidate should receive a link to our online test for developers.

This questionnaire consist of general questions about software development, a few "what is this code doing" puzzle and some questions about the technologies we use.

Interviewing

First personal interview

If most of the answers were correct, we ask the candidate to join us for a personal interview which takes usually one hour.

This turn has two parts: one is HR-related and one is about topics related to software development. Beside the candidate, there are three participants: one colleague from HR, one developer and me, the team lead of devs.

In the first part, HR ask some questions about their previous projects and experiences and some of the "classical HR questions" and just in case we are ask the candidate about salary one more time in person.

In the second part, we ask some questions about software development and other skills (we are interested if the candidate would be a great mentor or lead developer as times passes).

At the end, we talk about company culture, teams, products etc.

Second personal interview (optional)

Sometimes we use a second round of personal interview if we are not sure about the candidate's personality or if someone from the designated team would like to meet with the candidate. The second interview is way more casual than the first one, we usually just talk about general questions, our company and the possibilities within it.

Decision

After this we talk about the candidate and make a decision.

Proposal

If the candidate turns out to be applicable, HR makes a phone call about the exact salary and other options. If the candidate accept our offer, we agree on starting date and deal is done: we have a new developer in team!

Rejection

If we wouldn't like to work with the candidate, HR makes a phone call explaining why we decided so. We call or e-mail every rejected candidate.

Onboarding

I think this is an important step of recruiting new employees. We have a complete programme for new developers and it works perfectly because in their first week, they slowly walk through the many project and departments at our company.

Mentor programme

We have some fellow developers who are mentoring others. This mentoring is mostly about general stuff around the office, like: "How can I print?", "How can I ask my days out?", "I have a problem, to whom can I go with it?" and so on.

Workflow support

We are using JIRA for recruiting which is connected to the online questionnaire system. We comment every question and decision. I just wanted to share this with you guys, because trust me, a ticket with every useful information about a candidate could be life saver when you are making a decision.

Some personal thoughts

I really like to make interviews a casual, personal experience rather than asking questions about unsolvable problems. I'm going to interviews as well mostly by curiosity and to enhance our process, and I don't really like interviews when I feel myself embarrassed as a candidate. You should never bully the developer in front of you in any way, because he became stressed and will forget everything about his profession.

I know, this should be fundamental, but I've seen a lot interviewer holding this wrong.

That would be it. I really like our process because in the last two years, we only hired really talented and great developers who are fit the team and the company.

Thanks for the chance to share our process and my thoughts about the topic! I'm open to questions and further discussion as I browse your fantastic posts. :)

Co-op Source • Feb 3 '17

Unfortunately we use the standard whiteboard interview technique. I've expressed my great displeasure with it but the culture is still very much focused on trial by fire.

DEV Community