Hiring for startups can be really challenging. While that’s probably pretty obvious, the diligence and careful attention for detail is especially pronounced when looking for a software engineer—even more so when you, the prospective employer, lacks certain fundamental coding competencies.
Unfortunately, when it comes to helpful web content, there’s so much more job search-related content focused on the perspective of the interviewee — life hacks for passing interviews, quick resume clean up tips, or any number of other preparation topics — than there is devoted to helping the people actually conducting these interviews. One might argue that imbalance is incredibly problematic — how can you prepare people for interviews when the interviews they’re walking into don’t understand what they’re looking for?
Despite that this process cannot be completely formalized, and human factors will by and large remain key decision drivers in most cases, we’re going to try to balance out the noise of how to nail an interview with 5 general suggestions that can guide you — the employer — throughout the hiring process, and give you a general understanding of how to go about hiring your next software engineer.
Two heads are better than one
At Ezetech we believe in team spirit and creative collaboration, and with that in mind, we try to not interview anybody alone — ever. This is actually incredibly important for the following reasons:
- Different perspectives might uncover subtle differences in how you collectively viewed the candidates’ experience and competencies — both on the page and how they’re able to discuss them in person — and behaviors and composure that otherwise might be overlooked when conducting the interview alone.
- Sharing opinions after the interview could more effectively reinforce decisions to hire or not.
- Interview team grows synergy and become more compatible working together on side activity — conducting technical interview.
- Nobody is accountable for hire alone, so members of interview team feel more safe and relaxed, thus, they can make a more sound, weighted decision.
The typical team lineup for an interview has two engineers and an HR manager. The presence of the HR manager at job interview is necessary because it’s absolutely important wonderful to have a view from the outside on how a candidate performs different activities. This is not to say that the preliminary “pre-screen” interview conducted by HR or a recruiter is not important. That helps the candidate understand the scope of the role, and whoever is bringing this candidate forward — or not — can understand their fit for the role from a character standpoint when it comes to the candidate’s personal and professional references. Apart from that, having the HR manager participating in the tech interview can be used to collect additional observations to support the hiring decision.
Two heads are better than one, but even adding an additional perspective unrelated to the function of the role is important. This allows you to cover all bases, checking not only for technical aptitudes, but also soft skills that are important when working on projects.
If the candidate is going to be part of a team, they need to not only know how to write code, but they need to be able to communicate with the team effectively, manage their time well, and work cooperatively and collaboratively towards a finished product. These are all things you can determine when you have multiple people present looking for these different aspects.
You can’t judge a book by its cover
Conducting technical interviews can be stressful! But that’s not the reason to stop interviewing — that’s the reason to not trust first impressions. Your candidates might be experts in talking. They’re good at it; they’re affable, charismatic, they’re not ruffled by the tension, and they’re naturals at both recognizing what you want to hear and saying those things they know you want them to say. You might find yourself in the entirely unenviable position where your candidates come across as more confident than your interviewers. For that reason, behavioral shouldn’t serve as a determining factor in your hiring decision — especially so early on.
After making a few of these hiring mistakes on our own, we’ve arrived at a different convention of sorts, something we call “late impression.” Obviously, it’s the opposite of that first impression, but the disclosure is very simple: As a team we agree not to make any decision until a post-interview discussion with the candidate. All questions and conversations during this part of the interview are used to compile entirely different observations about the candidate.
For example, you might meet a candidate who didn’t exactly interview well the first time. They have promising qualifications, and they handled themselves well technically speaking, but from a behavioral standpoint they came across as flustered, confused, and maybe they even forgot something critical. In this case, you want to give them a second chance. You should never pressure yourself into making a rushed decision either way, and this second time, who knows? They might have done a bit of self-editing, so they come into this meeting much more relaxed.
Practice Makes Perfect
Practice makes perfect, and, of course, this is true for anything you do. It’s especially true for the interviewing process — from both sides of the table. Remember: finding yourself in a room with someone who has rehearsed numerous lines of questioning and can answer any question about as perfectly as you could hope is neither impossible nor where you want to find yourself. A diverse range of soft skills is always an added benefit to any team, but you’re looking for core competencies that truly blow you away.
They need to be as close to perfectly, technically sound when it comes to coding as possible. And you should never — never, ever, ever — just take their word for it. Portfolios are great, but they’re rarely accurate encapsulations of one moment. You need to pressurize the situation a little — even if it stresses you out — and give at least a simple coding task for every candidate you want to seriously consider hiring.
And task selection is very important, so important in fact, that the scope of it might lend itself to a different blog post entirely. But, for our purposes here, you might make use of some other resources like Codility. We would advise on timing here. If you have a really simple coding task, like implementing bubble sort or factorial calculation, you can incorporate the expected completion of it into the structure of your interview.
Word of caution of course is that task selection is somewhat limiting in terms of the range of skills your candidate can demonstrate. It will only help you distinguish between people who are able to complete the simplest task “in field” and those who can’t even.
So, if you’re looking for harder coding tasks, it might require separate time slots independent of this interview. Remember: First impressions are deceiving, and behavioral never gives you the full picture. You’ve got to blend all of this together — with the coding task and technical interview — to get a good sense of the candidate’s talents.
People who live in glass houses should not throw stones
Interviews should always be a dialogue between people, and both sides should be prepared to answer each and every question. If you did an audit of all of the job search related tips and questions on the Web, one of the more common themes you’d likely find are how these writers insist on asking questions, often providing boilerplate samples of what to ask.
It’s an essential piece of the puzzle. You want your candidate to have a natural curiosity not only about the position itself, but maybe even the culture of the company, thoughts on industry trends, and other aspects that balance out a team. So, recognizing this, you should hope to have an understanding of anything they might ask — especially when it comes to how your company operates. When you conduct a technical interview with a software engineer, you should always remember that this is likely the place they’re going to ask the most questions about the team, projects, workload etc.
Additionally, you should always know your own strengths and weaknesses. Be honest to yourself and with your candidates. If you have 10 year-old legacy code written in PHP 4 — don’t hesitate to tell this to your candidates. After all, what reason could you possibly have to be disingenuous. That’s not something you want them discovering after the fact because the quick quit is far worse than the slow hire.
Many of our candidates have suffered through these kinds of bait and switches during the hiring process throughout their careers. It’s always a huge disappointment, and it’s always one of the first and biggest reasons they leave the job so quick. Even when we’ve asked our own candidates why they are looking to leave or have already left their last job, they give a number of different reasons, but more often than not we hear the common thread: “My expectations were never met.”
Easy, yet entirely generic suggestion to every hiring manager or team out there? Always set expectations at the very beginning. Do it clearly, definitively, and as truthfully and accurately as possible.
Measure thrice and cut once
Measurements are an important part of hiring process inside a company — no matter how personal or informally your interviews are organized. Regardless, there should always be a funnel; one showing drop-offs at each stage of the hiring process. Additionally, each member of the interviewing team should also compose their own internal rank of each candidate.
And that can vary from relatively simple, “Answered 8/10 questions well”, “Solved 1 out of 2 coding problems”, or something more complicated. At the end of the day, you should be able to balance out subjective opinions and personal impressions with objective, quantifiable performance.
At Ezetech we generally end up making a skills grade matrix, covering different aspects of the software engineer’s competence. One of the main benefits is that we’ve almost templated the process so we can use the same matrix to evaluate candidates and other employees’ skills as they grow and develop over time.
These software engineer hiring tips just a little part of any HR rules out there, but some of these are tried and true pieces that separate a relatively functional team from the dream team.
Don’t limit yourself when searching, be creative when evaluating, and always prepare software testing interview questions.
And then remember to have common measure for them — after all, hiring mistakes are expensive to cover.
Lastly, if you’re non-technical entrepreneur, and you’re thinking about conducting a tech interview by yourself, don’t. It’s better that you ask an agency or find a Startup tech partner that will help you test and certify the tech skills of the candidate. Or, you could always start to learn some coding if you have the time.