Coming up with interview questions might be one of the hardest parts about being a technical recruiter. You have to come up with ones that people can’t possibly research or prepare for beforehand, all the while making sure they’re still in line with the company’s voice. When it comes to finding a software developer for you or your client, knowledge and aptitude in software engineering isn’t enough. You need to parse whether they’ll be a good fit for your company in terms of company culture, work ethic, and dependability.
Hence, questions about their experience in software engineering won’t give you a very comprehensive insight regarding their overall character. Which is why we’ve come up with a list of the 7 best questions you should ask software engineers applying for your company.
1. Why should we hire you?
This question gets asked at almost every interview – and not just for software engineers. And before you roll your eyes at how cliché it is, there’s a reason it’s always used. This question is a good way to match how the applicant sees themselves against the way you see them; your initial impression curated from how they carry themselves, how they speak, and the information presented in their resume.
By getting the applicant to answer this question, you’ll find out what they consider to be their strengths, their talents, and what they genuinely believe they can contribute to your company. You can then match these against their resume and their previous answers for discrepancies or clarification.
For instance, they might say that they deserve the job because they’re a great leader. However, according to their resume, they never even held a leadership position before, they were never put in charge of any team, or they never attended a leadership training/seminar prior to their application. You can call them out on this and ask them to explain further.
2. What’s the most memorable project you worked on? Did you complete it successfully? Walk me through what you did.
This is a pretty loaded question, but it’s also very straightforward. The goal is to get a more in-depth look into the applicant’s work history and experience.
By recounting their favorite project, you’ll be able to discern several things; do they enjoy working with a team, or do they prefer flying solo? What kind of development process or methods do they use? What’s their coding philosophy? What steps do they take to solve a problem (i.e. coding errors, quality assurance fails, debugging issues)? Do they like brainstorming or do they prefer following specific instructions? How long does it take them to work on a project (taking into account scale, available resources, manpower, etc.)?
By retelling their memorable project and walking you through the steps, the applicant is verbally describing what it will be like to work with him or her. Of course, there’s always the chance that they’ll embellish certain instances or leave out some minor details, but this question ultimately gives you a better feel of how the candidate is as nothing but a software developer.
3. What would you say are the principles of good software engineering? What are some of the fundamental principles you think every software engineer should subscribe to?
Although there is sort of a general agreement regarding the principles of good software engineering, that doesn’t mean that people can’t have their own opinions. Most software developers, designers, and engineers probably prioritize some principles over others, or find several to be non-negotiable.
By asking this question, you discern two things; (1) do the candidates even know the established principles of good engineering, and (2) what is their personal opinion regarding these principles? Of course, bear in mind that they might have a different name for the principles. For instance, they might refer to Incremental Development as “Staged Development” or even “develop in stages.” The principle of Consistency might become “Consistent Quality,” or “practice consistency in development.”
Some other principles that can easily be given a different name are Critical Thinking Skills, Anticipation of Change, and Simplicity. The trick here is to listen to how they explain each principle to understand what they’re referring to, and then use that knowledge to match their philosophy on engineering against your own.
4. How comfortable are you in a startup environment? Do you prefer working in a more established company?
This question should help you puzzle out the candidate as a potential team player. Skills and talents in development notwithstanding, how well is this person going to fit into your company’s social environment and status? Working in a startup company is drastically different compared to working for a long-established corporation.
Wherever your current organization stands – new business or recognized brand – you want to make sure the candidate can handle whatever you throw at them. If they’re used to working for established companies, the unpredictability and flexibility of a startup might be jarring for them. However, if their work experience is exclusively comprised of online businesses, retailers, or internet entrepreneurs, the rigidity of a more traditional 9-to-5 might be suffocating or boring for them.
Use this question to parse their company fit, their flexibility and readiness for a startup/established work environment, and their understanding of the expected workload.
5. Do you follow the Agile software development process?
Earlier, we mentioned finding out about a candidate’s preferred method or approach to software development. Although there are a few dozen different approaches, one of the most common and proven methods to managing software development is the Agile approach. Even if your candidate doesn’t particularly like or subscribe to the Agile development process, he or she should at least be familiar with it, preferably having implemented it at one point or another. If your team does employ the Agile approach, then someone who follows it or already knows it will be easier to integrate compared to someone who’s never heard of it.
6. If you were to review another team member’s code, what’s the most important thing you’d check for?
There isn’t necessarily a right or wrong answer for this. This is just to gauge the candidate’s knowledge and how well they can articulate their debugging process. It’s also a way to figure out how dependable this person could be in terms of quality checking and assurance, should the need ever arise. When it comes down to it, you want someone who can focus on the larger picture while utilizing their knowledge and without losing their professionalism. Their answer will also give you a pretty good idea about their attention to detail, their debugging skills, and their problem-solving abilities.
7. What’s the difference between a good software engineer and a great one? Based on what you just described, would you say you’re a great software engineer?
This question is a great one to spring right at the end, like a closing remark for the entire interview. It helps you understand how the candidate views someone who they would consider to be the ‘best’ in their industry, and how they view themselves in comparison to that concept. It also shows you their personal opinion regarding their own talents and abilities, and how they actually view themselves in the narrative of something as competitive as the software engineering industry.
Asking this question also gives you a chance to discover a couple other things about the candidate, depending on how they answer the question; their thoughts on software development, their idea of someone ‘accomplished,’ and their level of honesty and introspection regarding their career.