What I Look For When I Hire Software Engineers

It Isn’t All About Code

Over the years, I have had the pleasure of being a part of the hiring process. My experiences range from being a cog in the wheel of hiring for a massive corporation, and a primary decision-maker for a small start-up.

What makes a good hire? It might not be what you think…

Get Noticed

The first step to getting hired at any job is to get noticed. That might be as simple as submitting an application. It might also be as complex as leaving a lasting impression on the CEO you happened to run into.

Before one can interview they must make themselves known.

This seems painfully obvious, I know, but it is true. Some companies receive hundreds or even thousands of applications. As an example, for the last round of hiring I did, we received over 80 applications. Our company is less than 40 employees and our dev team was less than 10 at the time.

At this stage, you must be a little more persistent. Make phone calls, send emails, stop in and get to know the person at the front desk. In a virtual world, you could follow the company and comment on their posts. You could also find people who work at that company, and maybe even interact with their posts too!

Do whatever it takes to get an interview but be friendly, respectful, and courteous. You will be more likely to leave a good impression with someone who could put in a good word for you later. You must convince them that they do actually want to spend time interviewing you.

You will be more likely to leave a good impression on someone who could put in a good word for you later. You must convince them that they do actually want to spend time interviewing you.

What I’m looking for

Your qualifications will be the first thing I look at. What if you don’t have much for qualifications? Not to worry! This can be offset by persistence or examples of past work.

A well-curated GitHub account (or any public git repository) can be a big plus, especially if your qualifications are light. I’ll usually look at a few of the most recent repos. What am I looking for exactly?

what have you worked on recently?
how do you write code?
what language(s) do you use in your projects?
what tools (if any) are you using on your projects?
are there any comments? are they good comments?
are there any tests?
how is your code structured?
is there a README and is it useful?

For me, a quality public git repository account can completely offset a weak resume.

Photo by Quino Al on Unsplash

Phone Interview

Depending on the job and the company doing the hiring, there may be a phone interview first. Consider this a pre-interview and is likely to be informal and somewhat short. Again, be friendly, respectful, and courteous. The goal here is to get a feel for candidates and see what sort of an attitude they have.

Phone interviews rarely go into deep detail. Instead, the focus on work history and broad concepts.

What I’m Looking For

Communication. How well do you communicate using only language? Where are you when doing the phone interview?

These days, this stage may actually be a hangout or zoom or whatever, but the questions are the same. If it is a video call, my favorite thing to do is what the eyes and face to see how you respond to questioning. I’m also keeping an eye out for, and try to be respectful of, nerves.

It’s okay to be nervous. You know what you should do if you’re nervous? Say that you’re nervous. For me, seeing someone nervous during an interview means that you care and that you are not a robot.

Lastly, this call serves as a control for the Interview later on. I will be able to compare your attitude between the two interviews. I’ll also be able to compare your attitude between a relaxed situation and a more stressful one (the in-person interview).

Photo by Jukan Tateisi on Unsplash

Code Challenge

Personally, I am a fan of short, concise code challenges. It doesn’t need to be complicated, just enough to prove they can code and just enough to see how they code. Something small like designing an API for a React component, or setting up a data model for some API response.

One thing I absolutely avoid here and in the following interview is anything related to algorithms. They are good to know, but not required knowledge for my team.

This is where the process starts looking at more than “can an engineer engineer?” An important part of this phase, and this is on the hiring side, is the feedback. If I ask a candidate to do a code challenge, at the very least they will get feedback on the work. That may be in the form of an email or it may be as part of the next stage; an in-person interview.

Either way, a candidate is getting some feedback!

What I’m Looking For

Did you complete the challenge successfully? I look for the same things here as do with the public repos (if available). The big items I look for here are correctness, code quality, planning, and structure.

Photo by Marten Newhall on Unsplash

Interview

Here we tie it all together. I’ll ask about your past experience, dev-related or not. We’ll make some small talk and I’ll probably ask you a few dry theory questions. If you’ve done a code challenge, we will spend a good amount of time going over that in-depth.

Whether the challenge was completed successfully is not as important as you might think. For me, I like to use challenges as a shared reference. You’ve had a chance to solve a small problem in a controlled environment that I am familiar with. At the interview, I can ask you questions about why you solved it the way you did. I can offer you constructive criticism on something that could be improved. I can poke at various parts of your solution to see what you know about the code you wrote. I can challenge your assumptions. I can ask about your thought processes and how you went about planning to complete the challenge. You did plan, right?

Pass or fail, your work is almost done. You’ve worked hard to get to this point, you made a lasting impression, and that is awesome!

What I’m Looking For

This may come as a surprise but I’m not looking for correct answers to my questions. Correct answers are awesome, don’t get me wrong, but what I’m looking for here is how you handle this poking and criticism. Are you answering confidently? If not, I’m going to dig into that to figure out what you might know and what you do not. Are you able to acknowledge when you might not know something? This is the most important part of the entire exercise. It really isn’t what you know, it’s how you handle not knowing that is important to me here.

Just as important, can you handle feedback and maybe even constructive criticism? Are you humble or arrogant? Are you vulnerable or defensive?

These are all important things to know about a person who will be joining a team. You see, I’m not just figuring out what you do and do not know, I’m figuring out if you will fit in the team. Attitude and effort are huge. Frankly, you can be fresh out of a Bootcamp, have zero qualifications, fail the challenge, and yet still get the job. If you can have a good attitude, handle feedback with grace, ask great questions, admit when you don’t know something, and want to learn, I want you on my team. Software development is a team sport. People who have a good attitude and put in the effort are what make the team work well.

I can teach people to code. I can’t teach people to not be a d***.

Follow Up!

After the interview (or interviews), no matter the outcome, follow up! Send a thank you card, send a thank you email. Add the interviewer(s) on LinkedIn, etc. Show that you have an interest in the job.

Even if you don’t get the job, memorable follow-ups can leave a positive lasting impression.

Conclusion

Interviewing can be stressful. You will improve your chances by being confident, humble, honest, courteous, and kind.

Attitude and effort can completely offset a lack of qualifications or a failed code challenge. If you’re likable, and someone who works well with others, your chances are good.

Good luck out there!