A Guide to Hiring Rockstars – Software Engineer Interview Questions (2023)

I have interviewed thousands of Software Engineers. I’ve hired some that have turned out to be superstars, some were just good, and some were mistakes. I’ve seen commonalities among those that excel, and I want to share them here. With regard to software engineer interview questions, here’s my method to deliver more rockstars.

The Cost of Hiring the Wrong Person

According to the U.S. Department of Labor, the cost of a bad hire to a company is approximately 30% of the person’s yearly earnings. For a Software Engineer/Developer, that is around $40,000. However, the CEO of Link Humans says the true cost of hiring and onboarding a new employee is close to $240,000.

Whichever statistic is more accurate, hiring the wrong person will cost you a lot of money and time.

What is a Great Software Engineer?

They are the type of people I hire for my company and any company I’m involved with. They make my life easier.

• A great developer loves learning about new technology. Like LOVES it.
• A great developer is resourceful. They will instinctively find a solution even when it’s outside the standards of the project.
• A great developer can communicate with a non-technical person effectively.
• A great developer can estimate accurately and deliver within the timeframe.
• A great developer is not a “brilliant jerk”.
• A great developer wants to be around other great developers.
• A great developer is not a robot that needs to be told exactly what to do.

A great developer can deliver 3x as much good code as an average developer. They are creative, and entrepreneurial, and bring forth ideas that a Product Owner may have overlooked. Over time, people tend to seek them out to “brainstorm” an idea with them.

Things I Do and Don’t Do

DO:

• I engage with certain recruiters that have delivered incredible candidates for me for many years. They are the best, which is why I work with them. There’s a cost for their services, but unless that’s a barrier, I reach out to them first.

• I reach out to my current rockstars and see if they have people they’d recommend. Remember – great developers tend to recommend (and want to be around) other great developers.

• If I post the opening online, but I won’t always use the standard job boards. I like to post where the developers hang out. These are places like ProductHunt and StackOverflow. It’ll be more of a general forum post, not a paid post. I don’t do this often since I’m not looking for 1000 replies that I have to sift through. I’d rather solicit replies from 10 rockstars directly if possible. So I may post only to a smaller group on these sites that I’ve networked with in the past.

• Occasionally, I may have a candidate take an online technical test from Codility.com. I have slowly moved away from this since I put a higher value on the person’s attitude, but it remains a useful tool for certain circumstances.
  

DON’T:

• I typically don’t rely on the Human Resources department to send me candidates. Most HR departments are fairly lean and may not be staffed with dedicated technical recruiters. The Engineering department is ideally positioned to do the interviewing while HR plays a supporting role when the offer is made.

• I hesitate to post a job opening to my existing network on LinkedIn or Facebook. These networks are a combination of many different experience levels, and posting directly to them is like inviting everyone to spam me about how great their cousin would be for the role.

• I don’t require the candidate to have a college degree. You don’t really learn to code in college, so the immediate value to the job doesn’t match up. Technology changes so fast that a person who has learned to program and has chosen this career path on their own is demonstrating enthusiasm. If they do have a college degree, that’s great. It’s just not a hard requirement for me.

• This one is important – I don’t care about a person’s outward appearance. They are here to do a job and do it exceptionally well. As long as they are professional and kind to their coworkers, that’s what counts. I actually value originality, since a developer needs to think fast and be creative. We’re creating a team of rockstars, and attitude is the most important attribute.

The Interview Process

In many cases, I prefer to have one or two people with me, and it’s a one-interview process.

Invite the Smart People

I like to bring in people that are currently doing the same job as the open position, so they can bring an accurate job perspective. Also, if the position will be reporting to someone besides myself (who may not be a hiring manager), I include them in the interview. They deserve to have some ownership in the process, and it gives them a bit of career experience also. We’ll all be in the room together, but I always go first and ask my questions before I let the technical-level expert(s) ask their questions.

I used to interview everyone alone, but my success rate is far higher when I get confirmation from other people here. Some candidates are good at interviewing and can sway a single interviewer. This ability goes way down when multiple people talk to them. I have overruled people on occasion, but that is not the norm.

Confession – one rockstar I hired was a candidate that I probably would have passed on. The person seemed tired (he came in after he got off work at his current job) and I didn’t feel any energy from him. I knew he was good but it was between him and another person, and I was leaning toward the other person. I had two other people in there with me and they both loved him. I reluctantly said ok, and the result was one of the best hires I’ve made. I’m not always right, which is why having some very smart people with me results in a higher success rate.

One and Done

Also, I also don’t like to do multi-stage interviews (where they come back in for a second and third interview). I think it wastes time for me and the interviewee. I want everyone to get all the information they need within 60-90 minutes. Overthinking kills productivity, so I am always trying to eliminate it.

I actually timebox myself and my colleagues to make a decision during the interview about whether or not the person is a good fit. This process has an amazing success rate. It keeps people focused on whether the person can do the job and add value to the department.

Software Engineer Interview Questions

Anyone that has performed a lot of interviews can relate to this… you ask the same questions over and over. This is actually a good thing as it “standardizes” the interview.

The only drawback is that the candidates tell their recruiters exactly what I asked them when the interview is over. Like word for word. So any future candidates from these recruiters seem to be a little bit more prepared and ready for these questions.

Since I have at least one technical-level expert in the room with me, I know they’ll pepper them with very specific coding-level questions. I tend to ask more high-level questions to gauge their personality and commitment.

So what questions do I ask? Here they are:

Do you know what we do?

They better have looked us up on the web at a minimum. They should know what industry we’re in and be interested in it. If they come from a recruiter, they’ve been updated by them. It’s important that they have an accurate idea about the company and overall vision.

Are you currently working?

If they’re not working, why not. Any gaps in work are a giant red flag for me. Layoffs are understandable, as long as they weren’t the only person laid off. I want to know if they were let go from a previous job (and why) or if they quit the job without the security of having another job. The answers here can tell me the mindset of the person. If they quit one job for any reason without having another job first, it’s almost a dealbreaker for me. I want everyone on a team to have the right mindset from the start.

What do you like about your current job?

This will tell me what they value highly.

What do you dislike about your current job?

This may tell me the most about a person. Do they dislike having to work overtime if the job requires it? Do they have issues with a coworker? I’m trying to see if they have legitimate complaints or if they just whine about job challenges.

Why do you want to leave your current job?

Is it a legitimate reason, or are they thinking the “grass is greener” somewhere else? Again, we want to avoid job hoppers that will leave after six months.

What are you most proud of in your career?

Did they win “Employee of the Year”? Did they save the company a million dollars by rewriting some legacy applications? Maybe they’re not proud of anything?

What have you done that you wish you could do over?

What do they regret? Perhaps they’re embarrassed by something. This could be a good indication of what they value if they wish they could go back and improve it.

What would you like to improve about yourself?

This is more of an easy question for them to answer before the next one. People tend to have a rehearsed answer for this as well.

What kind of job would you be passionate about?

This is a huge question that tells me about what really drives them. You have to be careful that they don’t give you a rehearsed answer though. I may follow up with another question like “tell me why that is so interesting for you” or similar. This answer may also be a deal breaker if they are describing a situation that is the opposite of this job. You want people to thrive, not get hired and be unsatisfied. That is costly.

Can you tell me about a time when you had to learn a new technology or programming language quickly? How did you approach that challenge?

This one is important to me. A rockstar is always learning new things and actually embraces new technology. The answer that I want to hear is that they were under pressure to deliver and they worked all weekend to learn something new and ultimately saved the day. Something like that. Not all heroes wear capes ya know.

Where do you see yourself in 5 years?

Similar to the above answer, this one is pretty important. You want their desire to be close to the position’s career path. If I’m hiring for a developer role, but this person really wants to be a salesperson in 5 years, I have to question how engaged they will be in this position.

Do you have any personal software projects you’ve created and maintained? Or Do you have any Github repositories?

This one is extremely important to me. This alone shows me if they work on tech OUTSIDE of work hours. Do they really love tech or are they burnt out after 8 hours? Do they go home after work and write an app to start their coffee maker at 6 am every morning simply because it’s a challenge? That’s the kind of person you want. They tend to bring in new solutions because they solved a similar problem outside of work.

Have you ever launched a product on ProductHunt?

Same as above. Did they personally create anything that others find useful? Do they know what ProductHunt is? This would show if they are entrepreneurial or if they are active in the startup community. It’s not really a requirement, but it will tell you more about their mindset as a “creator”.

I’d like you to rate your skills on a few things 1-10, 1 being no experience and 10 being that you know everything about it.

These tell me their confidence levels in their skills. I can generally tell if someone really knows their stuff before I ask this, but I want to hear their own opinion. If a novice gives themself a 10, it can be telling. Also, I will alter these based on the type of Software Engineer position (i.e. – I won’t ask a PHP developer about their Java skills). Below are for a .Net Developer:

• C# skills – 8
• SQL skills – 7
• Selenium skills – 7
• JavaScript skills – 5
• Amazon Web Services skills – 3
• Github skills – 9 (currently using BitBucket)

Note – If English is not their first language, I will give them a communications score. Productivity is impacted if everyone has to interpret what was said by someone. It’s important that they are fluent in whatever spoken language your team uses.

Do you do anything fun outside of work?

This is my standard final question to wrap my portion up. I will use it to see if they have much in common with other members of the team, but it’s not really something used to hire or reject them. It’s more of my cue to the other interviewers that their moment has arrived.

Technical Questions

Next, I let my coworkers commence with the more technical part of the interview. They grill the candidate with technical questions like, “what’s the best structure for a multidimensional array when retrieving three levels of data from a client’s API”?

This portion takes the majority of the time (as it should). The person should know their stuff. You can sit back and gauge the person’s communication skills during this portion. Did they answer the exact question asked or try to talk around it?

If you are an expert in software development, you know when someone else is flustered. It’s ok if the person is confused by a question, but do they ask for more information? This is critical as a Software Engineer, so I want to see that behavior here. They shouldn’t be trying to make us think they’re smart. They should just be smart, and it should be apparent to everyone in the room. That may sound odd, but you’ll know it when you see it.

Finally, I ask them if they have any questions for us, which everyone should have at least one or two. We answer them and when they don’t have anything else, we politely thank them for their time.

How I Grade a Candidate

Immediately upon the completion of the interview, I give the person a score from 1-100. I don’t spend a ton of time on this but I do write a few notes down like pros and cons. I tend to have a short list of items that I want to remember. Kind of like highlights to sum up the interview.

I also have the people that assisted in the interview score the person as well. The scores given are a cumulative “gut check” from each person.

As a group, we’ll discuss our scores immediately after the interview for 5 minutes. This needs to be immediate when our memory is fresh about the candidate. I feel this is respectful to the candidate and allows us to make a decision and move on to other tasks. There’s no big debate here, but we quickly bring up the pros and cons. No overthinking is allowed.

• If a person scores below 85, they are rejected.
• If the person scores an 85-89, that’s hireable but I’ll probably continue to interview other candidates depending on urgency.
• If the person scores a 90 or above, I have no concerns and this person and they will probably get an offer from me.

It’s typically a “go or no-go” situation unless they fall in the 85-89 range. If that’s the case, a final decision may be made in a few days (I generally hate doing this) after we interview additional candidates.

Conclusion

That’s the majority of my proven system. Attitude is so important to a Software Engineer role. Technology changes overnight, and stress is part of the job. With the right interview questions, you can greatly increase your chances of adding rockstars to your team.

Remember to tailor the interview process to the company’s needs and be open-minded to candidates from non-traditional backgrounds. The best Software Engineers often have a rebellious streak burning in them. This seems to work in their favor when they need to find alternative solutions to tough problems.

If you are struggling with your hiring process, I encourage you to reach out to me for a chat.