7 Red Flags to Watch for When Assessing Tech Talent
So, you’re looking to make a new tech hire ? Just as important as finding someone with the rights skills, experience, and personality is finding someone who doesn’t exhibit certain warning signs.
It’s a lot easier to recognize good signs than bad ones, but it’s not impossible to catch red flags as soon as they pop up – as long as you know what to look for.
CodeFights, a platform that helps programmers sharpen their skills and connect with employers that want to hire them, recently put together a list of seven major red flags that companies should watch out for when assessing tech talent. Most of these red flags revolve around candidate behaviors during a test coding assignment, but there are a couple tips relevant to in-person conversational interviews, if that’s more your company’s thing.
(Although, if your company is hiring programmers without testing them first, you should really reconsider that decision.)
Check out the full list of red flags below:
1. Lack of Attention to the Task Description / Misunderstanding the Task and/or Missing Details
CodeFights says: “If one can’t follow instructions or has a problem understanding instructions correctly due to sloppiness, having that person will cost your organization a lot in the future. If there is any confusion when reading the task description, the candidate 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 Alternative Approaches
CodeFights says: “Real-life engineering problems tend to be complex and not straightforward. Great engineers also pioneer new ways of solving technical problems. If a candidate demonstrates a tendency to give up easily when facing uncertainty or obstacles, this might not be the person you are looking for.”
3. Sloppy, Inconsistent Coding Styles
CodeFights says: “For example: using inconsistent formatting, lack of 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 into other codes. It also signals that this person does not have an adequate level of attention to detail to do the job well.”
4. Not Listening to the Interviewer’s Hints and Suggestions
CodeFights says: “If the candidate does what they think is correct even if the interviewer says the opposite, it’s a sign that this person is not a great team player. It will make working with this person unenjoyable and inefficient.”
5. Not Considering Edge Cases of Inputs That Might Break Their Code
CodeFights says: “This is an essential sanity-check step in writing code professionally. If the candidate stops at writing out codes and doesn’t have the habit of trying to poke holes in their own code, think twice. Not only is it possible the candidate will require a lot of other engineers’ time to review their code, but this candidate may also fail to raise the bar by challenging other team members’ approaches, logic, or code.”
6. The Candidate Does Not Know What the Company Does
CodeFights says: “The fit between candidate and company is as important as the candidate’s skills. If the candidate doesn’t even know what the company does, it is a sign that the candidate is looking for a job, not this particular job at your particular company. Successful members of a team are those who are passionate about what the company does.”
7. The Candidate Can’t Share a Specific Learning Experience From a Past Mistake
CodeFights says: “Everybody makes mistakes, whether you are an experienced engineer or a novice. The important traits that you want to find in your candidate are the humility and maturity to recognize one’s mistakes and the ability to learn from mistakes.”