How I Interview Developers via Video
Why video interview?
I work for a fast growing start up located in Berlin. We would like to hire mid-senior Ruby developers, and the competition is high - there are many tech companies in Berlin that are growing and hiring, and talent is scarce.
Most developers already have a job that they won’t easily leave, so no wonder companies are looking for candidate also oversees and support their relocation process.
Each hiring process starts with phone screening, which I will not cover here, followed by a programming task to be completed and submitted for our review. The purpose is to assess the candidate’s level and competence regarding things like problem solving, design, code, written communication, error handling and testing.
Assuming the task was good, local candidates are invited for an onsite technical interview, but flying over remote ones is expensive and time consuming, so we conduct it via video.
How is video different from onsite interview?
Both onsite and video interviews have the same structure:
- Introduction — myself, the company, team and technology
- Questions from me to the candidate
- Questions from the candidate to me
Some of the questions are identical for both types of interview, but for the onsite one, I present some very high level problem, and the candidate is requested to give her solution(s) on a whiteboard, from major database entities to API response. Once they have a basic working solution, I can further inquire why she made certain choices, and how change of circumstances would affect, for example, high load, new features, etc. This is a great way to assess problem solving skills.
While we can learn a lot from this, this has proven to be inconvenient for video calls. Communicating diagrams or abstract ideas is not straight forward, and existing sketching tools take too much time and distract from the major learning we’re after.
Assuming that the home task was good and was done honestly, there is also not much to learn from a live-coding interview, where you have to be 100% precise in a very stressful situation.
What I ask
The interview is dynamic, but I am trying to cover the following things:
Tell about a medium to big project you’ve been recently working on. Briefly describe the main components and your contribution.
There are several things to learn from the response.
First, to see whether she understands the system she was working on, its design, its parts and how they play together. Second, to understand whether the candidate came up with solutions, or was implementing given solutions and worked on rather small pieces.
Weak responses would include the word “we” a lot. “We decided to use…”, “We wanted to…”, etc. In this case I probe “what was your opinion? who decided? what arguments? what tradeoffs? what did you want?”
Another negative signal is if the candidate cannot describe the entire system, e.g. “I only worked on component X, so I have no idea about the rest”.
Good indicators are, the candidate can describe the system, and give examples of initiatives or parts she knows really well and can explain tradeoffs, which shows she has interest and brings more value than mere implementing what someone else proposed. If she speaks with enthusiasm, that’s even a greater indicator for engagement.
For the problem solving skills, I challenge with new requirements for their system. For example, how would they change it in case the traffic is significantly higher, adding a mobile client and supporting near realtime dashboards.
This question takes up most of the time, and leaves the candidate a lot of room to choose what she wants to talk about and in particular gives the chance to shine.
Tell me about your experience with Kafka
Often candidates mention an interesting technology in their CV. This is an opportunity to dig deeper and check whether it is just a buzzword that the candidate has heard about or actually worked with. If they really did, they can explain it (I sometimes ask them to describe it to me as if I am a new developer joining their team) and why it was chosen (for example, why Kafka and not RabbitMQ?), what was the purpose and so on. More examples can be: AWS, graph database, working with huge volume of traffic, realtime, performance tuning and microservices.
A bad example is if the candidate mentions AWS, but the only experience is manually uploading files to S3.
How does the code you write gets to production?
The purpose is to assert that the candidate has some knowledge outside the actual “coding”. I hope to hear a modern process, for example, pushing via git, opening a pull request, tests are automatically run on continuous integration server, code is reviewed and fixed, then merged. Then it could be something like automatically creating a docker image and pushing it, etc. Hopefully candidates do not respond with “no idea” or sending modified source code files to someone who uploads via FTP. Of course, most of the time, it’s not their call how the pipeline looks like, so they might describe it with criticism or how they would implement their ideal one, which is a good sign.
Can you describe your work process?
Here I want to see how they worked — was it as part of a team? Completely alone, executing requests of managers? How they communicate, receive feedback (e.g. code review, retrospective meeting). How they worked with the product manager, QA and team lead. The candidate might get emotional at some parts, for example “It was so annoying, I had to update a ticket in our ticketing system instead of just coding”, or “mandatory code reviews really helped me improve my skills”.
I also ask to describe a case of disagreement with colleagues and how they resolved it. Preferably, they presented arguments and facts first, suggested to collect data, research or build a PoC, and didn’t go to the team lead to decide immediately.
What’s your testing methodology?
We have our testing philosophy, and we require team members to follow — we believe in automated testing — having a lot of unit tests, less functional tests and even less end to end tests.
So answers like “I am a senior developer, so I don’t need to test”, or “QA will test it” are not acceptable. I want to assert that the candidate is accountable and covers their work with automated tests, and preferably, they can explain why it is good to have it.
Can you explain any of the SOLID principles and a design pattern that you used?
As we work with an object oriented language, it’s important to have object oriented theoretical and practical knowledge. Communication between developers is easier when the concepts are familiar, and the code is more readable. The development is cheaper this way, as code is easier to change. Of course, this is something that can be taught, but as mentioned, candidates should be mid-senior level. This also proves that they read and are engaged in this profession, which is a good signal.
Not hearing about SOLID principles or not being able to explain even a single design pattern is a signal for lack of interest or previous mentoring.
Can you give an example of an initiative?
Organizations benefit from proactive engineers with initiative, ideas and suggestions. It is less beneficial to have engineers merely as “executing commands”.
Examples could be: convincing to start unit testing, introducing a build server, introducing continuous integration pipeline, migrating to AWS, change of processes, extracting a service, building dashboards, introducing Kafka and many more.
Again, this is something that is expected from mid-senior level engineers.
What’s the thing you’re most proud of professionally?
This is another signal for enthusiasm, and again, gives a chance to shine. If the candidate gets stuck, I ask about a big challenge that they solved.
What things you didn’t like in your current and previous work places?
This really helps getting the full picture about the candidate.
If they say they hated working in a team, it’s a problem, because we work in teams.
If they say they needed to come up with solutions instead of implementing given solutions, this would also be an issue.
If they mention things that prevented them from growing, that’s a good signal. More examples: not allowing other ways of thinking, forbidding to write tests, micromanagement and many more. It’s a sign they’re wishing for a change that we can deliver. They will be happier because they can grow. I do take into account the fact that they should be happy, as this is a bidirectional relationship.
What’s important for you in your next role? Where do you see yourself in the future? 1 year, 3 years…
I am not very interested in the plan they have, and everything is way too dynamic to predict. I want to see if there’s real misalignment, for example, developer who is interested in embedded programming is likely to not enjoy his work so much. A developer that wants to manage the entire R&D while we cannot even offer tech lead position would be frustrated.
What would you like to ask me?
It’s the candidate’s turn to ask whatever they want, in order to get more information to evaluate the opportunity. I answer honestly — selling the job, but never lying or bending reality, as it would be counter-productive to hire someone and they leave a short while afterwards when they discover something was not true.
But on top of that, the questions show what’s important for them. If they have no questions at all, or only ask about vacation days, they’re probably not very engaged. On the other hand, if they ask about technology, team, process, organization, options to grow and develop, then it’s a good sign.
What I don’t ask
Why are you interested in our company specifically?
First, as mentioned, it’s an employee’s market, meaning, they could choose many workplaces, so there’s no point being picky on something relatively minor.
Second, I don’t see it as a good signal — if the candidate saw our job posting, or was approached by us, he probably read a bit, and seems like there could be a match. I don’t believe that engineers are interested in the mission, the product or office location or specific leader within the company when they choose a workplace. If this is the case, they’d probably mention this.
Are you programming outside of work? Weekends, nights…
As much as it’s good to have enthusiast employees who love the profession, it’s not a good indicator.
Like the joke goes, you don’t expect a plumber to play with pipes when he gets home after work.
People need to relax, recharge, be with their loved ones and develop in other directions.
It is also exclusive — you might miss good engineers who have children, take care of someone, volunteer, train for marathon or have interesting hobbies.
It is also not a good indicator for their impact. Even if they do program all the time, maybe they are too tied to implementation details and fail to see the bigger picture.
How do you find a palindrome in a given text?
Computer Science questions, algorithms or brainteasers are a waste of time and are irrelevant for the actual work. They do not give any sign.
Review
The technical interview is just one of the interviews. Often one more engineer joins the interview. Other interviews test for communication, culture fit, values, expectation setting and coding skills.
However, the technical interview also gives signals as mentioned, and in the end, all interviewers give feedback without seeing each other’s feedback, to prevent bias.
A bad signal does not necessarily reject a candidate, but rather the overall impression of all interviewers.
Would love to hear how you assess whether the candidate is a fit via video!
