Your manager has asked you to review a stack of resumes and pick a couple candidates that you think are worthy of an interview. What do you do? How do you decide? When you get to interview people, what are the approaches you can take to do it effectively?

I’ve interviewed over 100 people for various software engineering roles, and I’ve probably been to about 100 interviews myself as a Senior Software Engineer. I’ve seen what works and what doesn’t. Interviewing can be a daunting process since you want to be sure to distill down to the right candidate, but these tips can help you find the perfect fit for your company.

The basics

To effectively understand who to interview, you need to start with criteria and an understanding of what the expectation is for the new hires. Sometimes, it’s to increase all levels of skill, other times you need specialized developers who are experts in API design or Frontend Development. Gather the understanding of the role they need to take, then evaluate what skills would be needed.

For example, at my current company, I knew we needed several senior and junior front end developers. We want people with some experience, even completion of a tech boot camp, to fill our junior roles. The most important criteria for all candidates, though, was resilience: the ability to adapt to change with a good attitude.

Having a good attitude was the primary factor in whether or not a candidate progressed to the next step, because as a technology organization we are constantly changing directions and figuring out our market.

Given our criteria, who works best? From a technical perspective, we needed savvy people who could learn quickly, so out of the piles I picked the senior developers with the most diverse technology experience and the juniors with the most unique backgrounds.

The interview

This is probably the most important step. You have two goals as a interviewer: sell the candidate on the company and evaluate their skills.

Selling starts with a good story

Selling starts with a good story: why are you the right team/company/technology for the candidate? What are the pros and cons of working with you guys? Talk about your culture and share your accomplishments. Show them your rad office space, talk about the mad ping pong skills you have and how cool it is to work with you.

Most of all, talk about the why. Why are you guys making the biggest impact? What are you doing? When I interviewed at this big insurance company, my soon to be manager got me excited about helping millions of people find and get affordable health insurance. You’re making a real impact on the daily lives of the customers you serve. That’s what you need to understand and communicate.

The interview questions

There are a couple of different styles of questions that are effective for different levels of experience. Interviewing interns and junior developers can be extremely difficult. Developers from boot camps tend to have limited and specialized experiences in developing software. It’s good to ask entry level questions such as:

  • Tell me about Test driven development.
  • Talk about Agile and Scrum.
  • Tell me about your class projects.
  • How do you handle conflict?
  • What do you want to learn?

The questions tend to lean more toward a behavioral style of interviewing. You want to understand his or her process, learning styles, and manners of communication. For these positions, you’ll be expected to train and coach a lot more than for the more senior candidates.

When interviewing for a more senior position, focus on 3 main areas:

  1. Personality
  2. Working styles
  3. Experience


You need to use some behavioral style questions. Common things are: how do you handle conflict? How do you handle disagreements? Are you confrontational? Are you passive? Asking targeted questions about projects and people while trying to let the candidate do most of the talking can reveal a lot about a candidate’s potential fit for the position.

Work Style

The next major piece you need to understand is how s/he conducts the job. Does the tooling used matter? Does s/he work best in Scrum or XP? Does s/he prefer to be solo or in a pair or a mix? These are easy questions, like:

  • Describe your ideal working environment.
  • Tell me about your favorite Agile development Methodology.
  • When you get a new work item, walk me through the process you use to see it all the way through.
  • Etc.


This is key to the position of a senior. Junior developers should know things like the command line, conceptual and be able to write some code on their own. Seniors on the other hand should be able to talk and demonstrate their:

  • Design and approaches they’ve used -as well as defend them with pros and cons.
  • Depth of technical knowledge

For understanding their technical knowledge, I prefer the machine gun approach. That is, I want to explore all topics in the related field. I often hire web developers so my machine gun belt looks like:

  • Explain from when you type “Key Lime pie” into Google and click search - what happens?
    • What I’m looking for:
      • Can they talk about DNS? Routing? Servers? Load balancing? Networking? HTTP? TCP/IP? How deep is their knowledge in how the internet works?
  • Explain how the DOM works in the browser
    • What I’m looking for:
      • Talk about DOM trees, Nodes and Leafs, how does the browser do async calls? How does it evaluate scripts, css, and tags?
  • Can you explain concepts such as: polymorphism, inheritance, functional vs OOP, design patterns, MVC, composition, etc…
    • What I’m looking for:
      • What’s the breadth and depth of your knowledge?
  • Tell me about XYZ framework on your resume, ask questions, pros cons, ask about security, performance and risks
    • What I’m looking for:
      • Can you explain in well enough detail Node, Rails or whatever else you’ve worked with such that I can tell you actually know the technology and can communicate the benefits?
  • Explain how DNS works
  • Explain how you would create a data model of any part of an amusement park (This is very open ended, but gets them to think of a bigger system, can they connect the pieces.)
  • Explain how HTTP works
  • Explain REST
  • Explain the relationship between REST and HTTP

Using these and other questions, I can gauge a candidate and quickly figure out how well they know the technology stack.

What not to ask

Other things, though, like: “Do you drink? What’s your favorite scotch?” or “Do you like to ski?” tend to also be unprofessional and could get you into serious trouble with the law, especially if the interviewee thought it might be discriminatory.

Other silly things not to ask are things like, “What’s your favorite developer joke?”

What about coding challenges and white board sessions?

I think white boarding is effective for demonstrating depth of knowledge; ex UML. If you’re hiring for a code monkey, then sure, have tons of contrived challenges to discover their “knowledge” of the language.

Code is great, but it’s like written language. You can write syntactically perfect Javascript with all the forms, looks and lines but still miss the mark. Compare that to English, you need a subject, a verb and an object. Sure you can put random words together that look well, but the point is to communicate your ideas not to have perfect looking syntax.

Likewise code changes, standards change and people can change how they write code. What is much harder is to get people to express themselves clearly. I’d rather have to coach a teammate on Javascript 6 syntax then coach them on how to communicate their ideas.

Clear communication + depth of conversation = really good technical interview. The goal is to figure out what they know, how deep do they know it without getting hung up on syntax or other unneeded details. I want people who are learners, who want to grow and can share their ideas. You’re job here is probably going to go from working in one specific language to working with many within the next year, I would expect that you can learn and grow with those challenges.

Making a recommendation

In my experience, you don’t get to make a hiring decision, but you may get input. Typically I’d weigh the candidate’s personality and skills with the needs of the team. In my current role, attitude and playing nice with others is a bigger deal than technical fit. For that reason I may choose a candidate that is better suited due to their skill in interpersonal relationships than their pure technical knowledge. The question often comes down to: “Can I get lunch with this person?” or “Can this person teach the team something valuable?” It’s not just experience nor is it just personality that should drive hiring decisions. It should be a blend of both.

Hopefully you’ve gained some valuable intel to help you make your next hiring decision.

What are your biggest interviewing tips or go-to questions?