Tech Job Interview Red Flags: 7 Things Great Candidates Never Do
Unlike a "standard" job interview, tech
interviews can often be very different. Many include having the
candidate complete a well-defined task. (Either before, as a qualifying
assessment of skill, but also often as a formal part of the interview
process itself.)
For example, the interviewer could give the candidate a list of numbers and ask for an algorithm that will find the smallest number in the most efficient way possible, and then ask the candidate to write code that generates the solution.
While the assessment approach can certainly help evaluate skill levels, testing also can reveal other things about the candidate -- some of which are definite red flags.
The following is from Tigran Sloyan, CEO of CodeFights, the skills-based recruitment platform that provides coding challenges to help users improve coding skills and even land new jobs. (For companies, CodeFights helps identify skilled programmers and, with the individual involved's permission, contact that person about a potential job.)
Here are seven red flags to watch for during a tech interview:
1. Lack of attention to the task description.
If hired, the candidate who can't follow instructions or has a problem understanding instructions correctly due to sloppiness will cost your organization in the future.
Candidates who are confused or unsure after reading the task description should ask questions and clarify issues as they appear.
2. Shutting down after getting stuck, instead of trying to talk through the problem or attempting alternate approaches.
The real-life engineering problems tend to be complex and not straight-forward. Great engineers also pioneer new way of solving technical problems. So, if a candidate demonstrate a tendency to give up easily when facing uncertainty or obstacles, this might not be the person you are looking for.
3. Sloppy and inconsistent coding style.
For example, using inconsistent formatting, lacking spacing and indentation, using unnecessarily terse variable names, or having code duplication.
This could be a potential disaster in a team environment, where other engineers on the team will need to understand this person's codes to debug or to integrate to other codes. It also signals that this person does not have an adequate level of 'attention to detail' to do the job well.
4. Ignoring the interviewer's suggestions and hints.
Some candidates will do what they think is correct, even if interviewer says the opposite. While you do want employees to push back at times, in a skill-based interview the goal is to assess specific skills, not necessarily to allow candidates to express their individuality.
Not paying attention to cues, much less direction, could be a sign that the candidate will not be not a great team player. If that's what you need, working with that person might not turn out to be efficient or even enjoyable.
5. Not considering edge cases or inputs that might break their code.
This is an essential sanity-check step in writing professional codes. Candidates who stop short of completing this step are definitely waving red flags.
6. The candidate doesn't know what your company does.
The fit between candidate and company is as important as the candidate's skills in making a good hiring decision. If a particular candidate doesn't really know what your company does, that means he or she is looking for a job, maybe any job... not a specific job at your company.
Successful members of teams are often people who are passionate about what the company does. A candidate who is not -- and can't even be bothered to find out if they might be -- is not a candidate you want to hire.
7. The candidate can't share a specific learning experience from a past mistake.
Everybody makes mistakes: Solid, experienced engineers, consummate professionals, novices... everyone. That's a given.
What you want are employees who 1) are humble and mature enough to recognize when they make mistakes, and 2) are able to learn from their mistakes.
Smart people -- and smart hiring managers -- see mistakes as just another form of training.
Via Inc
For example, the interviewer could give the candidate a list of numbers and ask for an algorithm that will find the smallest number in the most efficient way possible, and then ask the candidate to write code that generates the solution.
While the assessment approach can certainly help evaluate skill levels, testing also can reveal other things about the candidate -- some of which are definite red flags.
The following is from Tigran Sloyan, CEO of CodeFights, the skills-based recruitment platform that provides coding challenges to help users improve coding skills and even land new jobs. (For companies, CodeFights helps identify skilled programmers and, with the individual involved's permission, contact that person about a potential job.)
Here are seven red flags to watch for during a tech interview:
1. Lack of attention to the task description.
If hired, the candidate who can't follow instructions or has a problem understanding instructions correctly due to sloppiness will cost your organization in the future.
Candidates who are confused or unsure after reading the task description should ask questions and clarify issues as they appear.
2. Shutting down after getting stuck, instead of trying to talk through the problem or attempting alternate approaches.
The real-life engineering problems tend to be complex and not straight-forward. Great engineers also pioneer new way of solving technical problems. So, if a candidate demonstrate a tendency to give up easily when facing uncertainty or obstacles, this might not be the person you are looking for.
3. Sloppy and inconsistent coding style.
For example, using inconsistent formatting, lacking spacing and indentation, using unnecessarily terse variable names, or having code duplication.
This could be a potential disaster in a team environment, where other engineers on the team will need to understand this person's codes to debug or to integrate to other codes. It also signals that this person does not have an adequate level of 'attention to detail' to do the job well.
4. Ignoring the interviewer's suggestions and hints.
Some candidates will do what they think is correct, even if interviewer says the opposite. While you do want employees to push back at times, in a skill-based interview the goal is to assess specific skills, not necessarily to allow candidates to express their individuality.
Not paying attention to cues, much less direction, could be a sign that the candidate will not be not a great team player. If that's what you need, working with that person might not turn out to be efficient or even enjoyable.
5. Not considering edge cases or inputs that might break their code.
This is an essential sanity-check step in writing professional codes. Candidates who stop short of completing this step are definitely waving red flags.
6. The candidate doesn't know what your company does.
The fit between candidate and company is as important as the candidate's skills in making a good hiring decision. If a particular candidate doesn't really know what your company does, that means he or she is looking for a job, maybe any job... not a specific job at your company.
Successful members of teams are often people who are passionate about what the company does. A candidate who is not -- and can't even be bothered to find out if they might be -- is not a candidate you want to hire.
7. The candidate can't share a specific learning experience from a past mistake.
Everybody makes mistakes: Solid, experienced engineers, consummate professionals, novices... everyone. That's a given.
What you want are employees who 1) are humble and mature enough to recognize when they make mistakes, and 2) are able to learn from their mistakes.
Smart people -- and smart hiring managers -- see mistakes as just another form of training.
Via Inc
Post a Comment