Hiring programmers is a challenging process for companies. A lot of thought is being given to designing good interview questions and coding challenges to assess the skills of candidates in a hands-on way, either as a take-home exercise or a whiteboard interview. I know this from having designed and evaluated coding challenges myself, with respect to code quality, structure, and optimality of the solution.<\/p>\n\n\n\n
This evaluation is useful to a certain extent. What the process really boil downs to is asking the candidate to create an algorithm from scratch, finishing it within a short amount of time (typically anywhere between 30 minutes to a few hours), and then\u00a0hoping<\/em>\u00a0that doing well on this task will translate into being a good fit for the team.<\/p>\n\n\n\n The truth is there are many skills this practice is unable to cover. This is because working as a programmer mostly involves working with existing code, not from scratch, and within a team, not alone.<\/p>\n\n\n\n Due to this, a programmer should have\u00a0solid communication skills<\/em>\u00a0and an\u00a0effective approach to problem solving<\/em>\u00a0in the real, imperfect world. Assessing these skills, which are sometimes termed as \u2018soft skills\u2019, when done at all, is typically by asking the candidate questions about past or hypothetical scenarios, for example asking them to \u201cwalk us through an occasion where you had to ask for help\u201d. <\/p>\n\n\n\n While this is useful in the sense that past behavior can predict future behavior, it also gives the candidate an opportunity to guess what the answer\u00a0should<\/em>\u00a0be. Additionally, candidates tend to dislike these questions, as well.<\/p>\n\n\n\n Companies do not test for, say, Python skills, by asking the candidate to tell a story about a time they wrote a Python program. They ask them to write a Python program. What if there was a way to assess skills that are beyond algorithms in a similar, hands-on way? Not through a separate HR interview, not through behavioral questions, but baked in the same process that assesses coding skills.<\/p>\n\n\n\n This is what we\u2019re going to cover in this article. We\u2019re going to look at how to modify the different interview stages, specifically the phone screening stage, the take-home exercise, and the on-site interview, to get deeper knowledge about the candidate\u2019s ability to communicate, how they work with an existing codebase and others, and the resourcefulness they bring to problem-solving.<\/p>\n\n\n\n Looking for top talent fast? See how <\/em>Arc<\/a> can help you:<\/em><\/p>\n\n\n\n \u26a1\ufe0f Find developers, designers, marketers, and more Hire top talent with Arc risk-free \u2192<\/strong><\/a><\/p>\n\n\n\n Phone screenings are typically used to get more information about the candidate\u2019s past experience. However, it\u2019s possible to assess the candidate\u2019s awareness of what they do and do not know, and how precisely they can communicate.<\/p>\n\n\n\n Being aware of what one does and does not know, and being forthcoming with this information is a real gift when working in a team. If an employee is aware and honest about not possessing the knowledge needed to finish a task, it frees the team to look for alternatives, such as allocating time to acquire the knowledge, getting training, and hiring externals. The team is able to weigh the alternatives against the benefits of completing the task.<\/p>\n\n\n\n One way to assess this during the phone screening is to have an extensive list of questions across a large variety of topics to ask the candidate, for example asking a full-stack engineer technical interview questions<\/a> on everything from CSS to database internals. It is good to tell the candidate upfront: \u201cWe\u2019re not looking for guesses or for answers to all the questions, we\u2019re just looking to discover the areas you are strong in.\u201d<\/p>\n\n\n\n We can proceed to ask them questions for a fixed amount of time, usually 5 to 10 minutes. During the process, we can observe and record not only what the candidate knows, but also how they act when they don\u2019t know something. <\/p>\n\n\n\n In addition to correct answers, some positive signs to look for include: quick admissions that the candidate has not worked with a certain technology, and statements that deal effectively and honestly with uncertainty, such as \u201cI am not certain whether this particular database system implements bitmap indexes. If it does, we could use them, otherwise we\u2019d have to go for B-trees.\u201d<\/p>\n\n\n\n Read More<\/strong>: How to Find Developers: 18+ Expert Tips & Essential Strategies<\/a><\/p>\n\n\n\n You can also try <\/em>Arc<\/a>, your<\/em> shortcut to the world\u2019s best remote talent:<\/em><\/p>\n\n\n\n \u26a1\ufe0f Access 450,000 top developers, designers, and marketers <\/a>Try Arc and hire top talent now \u2192<\/strong><\/a><\/p>\n\n\n\n Precise communicators make things easier on many fronts. They are able to give pertinent information when describing something (such as a bug that needs to be fixed, the pros and cons of an architectural decision, how a system works, etc), and elaborate in the correct direction when prompted.<\/p>\n\n\n\n During the phone screening, we want to see if the candidate can give a precise account of their past experience. One way to facilitate this exchange is to ask\u00a0clean language questions<\/a>. The basic philosophy behind this is to minimize our assumptions as interviewers and explore the candidate\u2019s model of their own work. Clean language questions in the context of a tech interview are questions like these:<\/p>\n\n\n\n We can start this part of the interview by asking the candidate to \u201cdescribe a complex project they worked on,\u201d and continue with questions similar to the previous examples. We should use a gentle manner as we want to make the candidate feel heard, not as if they were being interrogated.<\/p>\n\n\n\n Clean language questions serve a dual purpose. First, they give deeper information about the candidate\u2019s past work, which is valuable in itself, and also allows interviewers to see how well the candidate can elaborate when asked questions about very specific aspects of their work. <\/p>\n\n\n\n Another positive sign to look for is when the candidate asks questions to clarify what is being requested of them, such as \u201cWhat do you mean by \u2018complex\u2019 project?\u201d<\/p>\n\n\n\n Read More<\/strong>: How to Implement a Welcoming Software Developer Onboarding Process<\/a><\/p>\n\n\n\n The take-home exercise is generally used to evaluate a candidate\u2019s algorithmic skills, by looking at how they solve a problem. We can learn even more about the candidate with some alterations to the process.<\/p>\n\n\n\n Most of the work programmers do day-to-day is not a greenfield project. A large portion is reading and building on top of existing code, which requires additional problem-solving skills. Hence, instead of giving the candidate an open prompt to create a small program from scratch, we can give them an existing code base that they can fork. <\/p>\n\n\n\n This codebase would, ideally, be Dockerized so that setting up the dependencies is easy, and produced by the company. It should still be shareable, for example, a small open-sourced project. We can also set up a private Slack channel where the candidate can ask engineers questions during the development process.<\/p>\n\n\n\n We can ask the candidate to add extra functionality to the code base to solve a new problem by creating commits in their own fork and then doing a pull request to the master repository. Their ability to perform these tasks shows not only their algorithmic skills, but also their ability to read, understand, and figure out where to make changes on code not written by them. <\/p>\n\n\n\n We can make sure to include a test suite, paying attention to whether the candidate extends the test suite in addition to the code. The take-home exercise can be reused if the candidate comes onsite, which we will look at in the next section.<\/p>\n\n\n\n Through the take-home task, the candidate will get a glimpse of what the company\u2019s typical codebase looks like, and an idea of what working with the team feels like.<\/p>\n\n\n\n Read More<\/strong>: 10+ Software Engineer Interview Questions to Find Top Dev Candidates<\/a><\/p>\n\n\n\n The on-site interview provides the opportunity to test-drive how the company and the candidate can work together. It makes sense to take advantage of both sides\u2019 time to delve deeper into that. If we are to go beyond whiteboard interviews, here are a few ideas for tasks to assess specific skills:<\/p>\n\n\n\n A task that can give both the candidate and the company a deeper understanding of each other is asking the candidate to pair-program with a member (or members) of the hiring team. We can tell the candidate that the requirements of their take-home exercise have changed and they need to work with another programmer, and optionally, a business analyst, to reflect this change in the code. <\/p>\n\n\n\n We can then ask the candidate to sit down with the teammates and their laptops in a meeting room to collaborate on making the changes. All people involved can use the task management system the company uses, for example, JIRA, Trello, or a physical Kanban board.<\/p>\n\n\n\n We observe whether the candidate uses the resources provided (i.e. the other people and the information captured in the task management system) to figure out what exactly needs to be done, what would be the most consistent way to do it, and how they address possible ways of splitting of the work. We can see where they lie on the spectrum of approaching changing requirements: from resisting them to the other extreme of starting over completely.<\/p>\n\n\n\n This task will provide symmetrical information to the candidate: how tasks get distributed and assigned in the company, how well project managers can communicate requirements, and how potential future coworkers can share knowledge and collaborate.<\/p>\n\n\n\n Read More<\/strong>: Andela vs Toptal vs Turing vs Arc: Which is the Best Andela Alternative?<\/a><\/p>\n\n\n\n Another skill to test for is how the candidate provides feedback. This can be assessed directly by isolating a relatively self-contained bit of the real code base, printing it out, and having the candidate read and take notes with the intention of doing a code review by posing the question \u201cwhat do you think of the code and how would you improve it?\u201d<\/p>\n\n\n\n It\u2019s important to pay attention to whether the candidate sprinkles positive comments together with negative ones, whether they are able to outline concise steps for iteratively improving whatever stands out, and whether they ask questions to find out if those improvements would be worth the effort or would affect other parts of the system. <\/p>\n\n\n\n People that only see mistakes in the work of others without offering solutions can be hugely demoralizing for the entire team, no matter how sharp their observations are. People who are well-meaning but want to roll out too many changes at once probably do not have a lot of production experience.<\/p>\n\n\n\n Speaking from personal experience, people who include honest and positive feedback in their reviews actually get thanked when reviewing pull requests. Those who understand while there\u2019s room for improvement, it\u2019s sometimes best to opt out of improving what\u2019s already good enough, are the ones that can drive impactful change.<\/p>\n\n\n\n This task has the added effect of giving the candidate a look into real company code. Moreover, if the candidate communicates to the interviewer an alternative way of doing things that they weren\u2019t aware of, how positively this suggestion is received can be very telling of the company\u2019s ability to support iterative improvement. This quality may be something that the candidate is looking for in a workplace.<\/p>\n\n\n\n Read More<\/strong>: 13 Things Freelance Software Developers HATE Hearing From Clients<\/a><\/p>\n\n\n\n By going beyond the whiteboard interview, we\u2019re able to assess the candidate\u2019s ability beyond coding skills. This can be as simple as going through the existing interview process and tweaking it with the intention of learning more about the candidate. <\/p>\n\n\n\n Naturally, time will need to be invested to find and package specific parts of the codebase that can be shared with the candidate, and to train interviewers to ask discerning questions. This adjustment will have the symmetrical effect of also giving the candidate a clearer picture of what it\u2019s like to work with the team. If you want support overhauling your interview process, don\u2019t hesitate to get in touch.<\/p>\n\n\n\n As a parting thought: remember to always keep a positive disposition. As interviewers, we\u2019re here to discover people\u2019s true strengths, and it\u2019s up to us to design a process that will bring them out.<\/p>\n\n\n\n You can also try <\/em>Arc<\/a>, your<\/em> shortcut to the world\u2019s best remote talent:<\/em><\/p>\n\n\n\n \u26a1\ufe0f Access 450,000 top developers, designers, and marketers <\/a>Try Arc and hire top talent now \u2192<\/strong><\/a><\/p>\n\n\n\n This post was originally written by Ariadni Alexiou<\/strong>, an experienced software engineer with expertise in Python, data science, Java, and code reviews.<\/p>\n","protected":false},"excerpt":{"rendered":" Learn how to adjust technical interviews to also size up a developer candidate’s ability to work with the team and an existing codebase. <\/p>\n","protected":false},"author":4,"featured_media":1205,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-1204","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hiring"],"yoast_head":"\n
\u26a1\ufe0f Freelance or full-time remote + fully vetted<\/em>
\u26a1\ufe0f Save up to 80% with global hires<\/em><\/p>\n\n\n\nPhone Screening<\/h2>\n\n\n\n
Self-awareness<\/h3>\n\n\n\n
\u26a1\ufe0f Vetted and ready to interview<\/em>
\u26a1\ufe0f Freelance or full-time<\/em><\/p>\n\n\n\nPrecision<\/h3>\n\n\n\n
Take-home exercise: Extending an existing code base<\/h2>\n\n\n\n
On-site interview<\/h2>\n\n\n\n
Dealing with change and asking for support<\/h3>\n\n\n\n
Constructive feedback<\/h3>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
\u26a1\ufe0f Vetted and ready to interview<\/em>
\u26a1\ufe0f Freelance or full-time<\/em><\/p>\n\n\n\n