The Most Effective Ways to Interview a Full Stack Engineer

Tips to Structure the Interview Format and Questions

When hiring for a full stack engineer, your final decision will be highly influenced by the candidate’s performance in the interview process.

If your interviews are poorly designed and you ask the wrong questions, the candidate you select is likely to be the wrong one. And that will be costly. In fact, Harvard Business Review found that 80% of staff turnover is because of bad hires. (See our article describing how to retain top frontend engineering talent.)

A poor interview experience also impacts the way in which the candidate feels about your organization. Ill-prepared and nervous interviewers, poor questions, long pauses between questions, and repetitive questioning do not convey a positive company and working environment.

In short, poor interview outcomes caused by poor interview techniques are bad for your business. They lead to selecting a below par candidate or the ideal candidate rejecting your job offer.

We asked Senior Application Development Manager Walid Amro, and a Vice President of Engineering at a Series-A startup in San Francisco (who wishes to remain anonymous, let’s call them ‘X’) – both with extensive full stack engineer interviewing and hiring experience – for their feedback to the question, ‘What is the most effective way to interview a full stack engineer?’

Here’s what they told us.

First, Define Your ‘Full Stack Engineer’

It’s critical to understand the requirements of the role to interview candidates effectively. We asked for definitions of a full stack engineer.

Walid tell us, “A full stack developer is a developer expert in developing front-end, middle-tier, and back-end development and frameworks. We have many types of full stack developers based on technologies and front-end development such as full stack web developers or full stack desktop developers. A full stack developer is expected to have extensive experience in all these development stacks, business logic, data design, networking, hosting environments, and user experience.

X says, “In my opinion, this is someone who’s capable of building applications from end-to-end. It’s sort of a bad term because it assumes an implicit notion… but in practice, it means an engineer can build interfaces (whether web, mobile, command line) along with implementing back-end services, APIs, network protocols, and design the data models that support a system. From a data layer perspective, they should also be able to build any of the supporting scaffolding, tooling, and automate deployments in the context of CI/CD. Overall, they should be able to look at things holistically.

In practice, they may not necessarily be able to or need to do all of those things. It’s possible that they may operate within the context of an engineering team with DevOps engineers… they may have the support of front-end engineers and have to chip in, but not bear the brunt of the front-end requirements. 

With your ideal candidate described, you can structure the interview and design appropriate questions to identify the best-fit candidate.

Structuring the Interview for Full Stack Engineers

Not all candidates need to be interviewed the same way. The seniority of a full stack engineering role for which you are hiring should help to determine how you structure the interview.

The general process would be one that involves some kind of screen to better understand their background,” says X.It’s important for all companies to prioritize diversity and inclusion at this stage. It also gives you the chance to strike a chord with the individual without being biased from what you’ve seen on their resume or the information available about them on a public forum.

It’s important to have fine-tuned interview formats,” X continues. “If you have senior engineers, panel interviews are much more effective compare to one-on-one meetings… having them demonstrate how they would do things is even more important. For example, giving them a pull request and have them give you feedback. 

Whatever the structure of your interview, it is also important to interview and review consistently. You should decide how you will do this before you begin interviewing candidates. A structured ‘scoring system’ will help to ensure that unconscious bias is removed and that all candidates are fairly and equally assessed.

7 Effective Interview Questions for Full Stack Engineers

During the interview, you should check and test the candidate’s technical ability and experience, and assess their cultural fit.

X says that, “during an hour you will uncover a lot about an engineer. You can assess their product pulse, how they deal with abstraction and complexity, and how they think about the overall solution.”

They need to demonstrate that they have the technical skills to do the job; the best way to assess this is with coding exercises along with subsequent conversations about them with other ICs. Not just about how they’ve done the work, but how they communicate about it. I strongly believe in value fit… to make sure the candidate can walk the talk and display teamwork, passion, and a results-focus.” 

The process changes depending on the grading of candidates. Some of the things you use to vet junior candidates would not be effective for senior candidates. Senior engineers or managers already know how to give good answers to the basic interview questions.

Walid agrees. “Interview questions for candidates usually align with which type of full stack developer you are looking for, but we can have generic questions to make sure that we cover the basics.

Walid also says to “make the interview as a brainstorming session on a project,” noting that, “you always need a whiteboard.

Brainstorm Interviews

Walid provided this example of a brainstorm structure interview:

  1. Ask the candidate about a system that he/she worked on and to design a small-scale system on the whiteboard. Let the candidate design the database, middle-tier, and front-end. Ask the candidate questions while he/she is creating the design.
  2. After the candidate finishes the design and you’re satisfied with the answers, try to find one part to change because of new business rules; for example, if the CTO decided to move the database and middle-tier to the cloud, what would you do? Or we needed to containerize the middle-tier and host it on Linux even though we are using .NET Full Framework. See how the candidate reacts to the change, and always pay attention to his or her questions – questions usually reveal if the developer has real experience or not.
  3. Ask about failure of one of the parts of the stack and how he or she would find the root cause and mitigate problems. For example, the website is giving a 500 error and the whole company website is down! What should the candidate do? What would they check?
  4. Ask about how he or she would work with the other team members and how they currently work together.
  5. If management gave requirements to the full stack developer, and he/she is not familiar with the solution, what would they do?
  6. Ask questions about how to secure the full stack internally and externally.

X added further detail by saying that you should:

  • Give the candidate large, complex problems around a product to be built – and ask system design-type questions
  • Talk about all the consistent pieces around all the components and details you’re looking for in the role
  • Dive deep into specific areas like data model design and designing/developing front-ends to be performant and responsive

One of the recent questions we used which we like a lot involved a task list,” X says. “Almost everyone uses some sort of task list. The apps may be simple in terms of functionality but can be tricky to build. So, we ask candidates to build a task list application and describe how they would go about doing it. This is sort of a leading question: we expect them to ask the right questions to understand the requirements and then transition into the solutions part.

Differentiate Between Front-End and Back-End

X believes there are no true full stack engineers, saying that to be so, skills would need to be equally partitioned across the board. Therefore, it is important to assess whether they lean toward the front-end or back-end, and assess this against major requirements. X gives the following examples of question direction that could be used to determine a candidate’s skills mix:

  • A question “to do with a design that we’ve done for our own product. We present a screen in a single-page web application, describe what it’s trying to accomplish, and ask the candidate to design a front-end around it.
  • Questions such as:
    • How would you deploy back-end API?
    • Which cloud provider would you pick and why?
    • If you could choose any form of compute, which one would that be?
    • What kind of tooling would you use to package and provision the application?

Beware the Red Flags

An effective interview will draw out red flags when questioning full stack engineers. Many candidates claim to be full stack engineers, but lean too heavily to front-end or back-end to really be considered as such.

Asking a candidate whether they lean toward the front-end or back-end will tell you much about their understanding and what they really know. However, a greater leaning one way does not mean you shouldn’t employ them if they demonstrate that they are enthusiastic learners.

Equally important is to consider soft and interpersonal skills.

X says, “The most important red flag is the lack of collaboration and communication skills… they will be expected to work with a lot of people. They won’t just be working with a UI designer or just hunkering down and building systems and tools for the back-end. Even if they’re not a staff engineer, they will have several touchpoints. Are they humble and even-keeled? Are they sure-footed enough to ask the right questions? This is critical.

The seven red flags that Walid describes are:

  1. Communication: if the candidate is not clear in his or her communication and very hard to follow.
  2. Complex design for a simple problem.
  3. Stubborn/over confidence: you tell the candidate there is a solution for something and they tell you that there is not solution.
  4. Not willing to learn new technology: if the candidate said that they are not willing to learn a new thing, this is usually a red flag.
  5. Bad, irrelevant questions.
  6. Use of unknown technologies/frameworks that are not popular in the marketplace or known to most developers.
  7. Giving vague or generic answers.

In summary

Interviewing is both an art and a skill, finding the best-fit candidate and ensuring that fit starts at the beginning of the hiring process. By ensuring you understand the exact candidate you require for your full stack engineer job, you can refine your job description and help to ensure that the candidates you receive have the required mix of technical and soft skills.

With this understanding, you can design an appropriate interview structure and line of questioning that will properly determine suitability – and this will help you hire full stack engineers who will not become another statistic in your staff turnover column.

To Hire Quality Engineering Candidates, Partner with Kofi Group

X also describes their experience of working with Kofi as a recruitment partner. Here is what they had to say:

I’ve used a variety of contingency and retained firms for the past 10 years. I previously worked at Oracle, who had internal recruitment, but they weren’t very good at it. I would definitely factor Kofi to be one of the top firms I’ve worked with over the past 10 years, especially when hiring software engineers.

One of your strongest attributes is clear communication. (Recruiter) Joseph Gordon is fantastic about that. He asks the right questions, is very specific, and sets the right expectations on both ends. We don’t waste time interviewing candidates who aren’t a good fit. We calibrated quickly on different positions and stayed on a steady path with good volume.

I look at good recruiters as being more of my partners instead of me being their clients. Looking at one party as a vendor or client never results in the best candidate outcomes or recruitment outcomes, especially with candidate experience.

Joseph, even though he works for Kofi, did a good job of representing us as a company. All of us are communicating the same message, are on the same page, and continuously assessing and closing candidates. With other recruiters, I ended up on three-way conversations at the offer stage. Joseph helped simplify the conversations and made sure the candidate experience was seamless.

To benefit from the Kofi Group experience, get in touch with Kofi Group today.