The interview is key to locking in the right talent for your startup. Your interview process should be air tight, exposing red flags and drawing out the crucial skills needed for success in the role.
Today we are going to share a few juicy secrets and tips from hiring managers and recruiters across the tech industry on how to interview full stack engineers.
Let’s get started.
Long-story-short, a poor interview caused by poor interview techniques are bad for your business. They lead to selecting a sub par candidate or the ideal candidate rejecting your job offer.
We interviewed:
- Traey Hatch, Big Data Practice Manager and previously a Lead Data Engineer at a Series B startup
- 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 him “Ben”)
Here’s what they told us.
Best Practices
Having established why the interview process is so important in the hiring process, we wanted to dig deeper into how interviews should be conducted. So, we asked Traey and Ben to share some of their best practices with us.
#1 Involve Their Potential Teammates
Traey explains that he adopts a low-risk, high-reward strategy by starting with fit.
“In addition to screening for fit myself, I like to give my colleagues, and potential teammates for the engineering hire, the opportunity to ask some questions themselves,” he adds. “Almost always, they will pick up on things I missed, or offer brilliant insights about a person’s character.”
#2 Know What a Startup at Your Stage Needs
Traey explained to us that the point of the growth curve on which a startup sits is a determinant of the caliber of engineer to be hired.
Early-Stage Startups:
“Early-stage startups should be looking for seasoned engineers and engineers with tremendous domain knowledge. Hiring well at this stage can help build a solid foundation for your project. As journeymen, engineers will often set up their projects for success from the very start. They have seen and made many mistakes during their career, and they will bring all this wisdom and experience with them to the project,”
Mid-to Late-Stage Startups
“Mid- to late-stage startups will often look for junior engineers to help increase throughput. Here we are often looking for solid software development foundations and dedication to improving one’s craftsmanship. A junior engineer who is inspired by his/her work will improve in skill quickly.”
#3 Assess whether they lean more towards the Front-End or Back-End
Ben believes there are no true full stack engineers, saying that to be so, skills would need to be “equally partitioned across the board”. It’s unlikely anyone is going to be equally skilled in both areas so it is important to assess whether they lean more toward the front-end or back-end, and then determine which preference better suits your needs for the role.
Ben gives the following examples of questions that could be used to determine a candidate’s skill mix:
- For a front end question, “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.”
- For the back-end ask questions such as:
- How would you deploy a 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?
Asking the right questions and digging into the answers can really help you to understand the potential hires’ preferences and depth of knowledge.
#4 Keep the Candidate Engaged Throughout the Process
The best engineers looking to make a move will move fast! Don’t let an interview process that has 5 or 6 steps slow you down. Try to have 2-3 in-depth interviews where you can identify candidate fit, gain approval or get insight from colleagues, and validate technical ability.
Most likely a candidate looking to change companies will be interviewing at other startups as well so be sure to keep them engaged by giving regular feedback on what next steps to expect and provide feedback on how the interviews are going. If a candidate does not hear back from you in a timely manner or feels unsure of where they stand in the interview process they may move forward with a different company that appears more engaged with them throughout the process.
#5 Tailor Your Questioning to Fit the Role
In your interviews it is important to distinguish between what you need and what you want. Isolate what key skills – soft or technical- that are must haves for you and your team. Then identify the skills or traits that would be desired but may not be crucial.
Know your priorities.
Also, consider the level of engineer your project requires and calibrate your questions based on that. Traey told us in depth exactly what he looks for when hiring a full stack engineer:
Seasoned Engineers:
“For seasoned engineers, I want to see code examples, to discuss software architecture, and how they will approach design decisions.
“I also want to know that they are able to create software, not just respond to a coding challenge. Seeing how the engineer will develop a project over time is important to me, and this is difficult to ascertain with a short technical exercise.
“If the engineer is open to it, I like to ask them to put together a small (Python) package, with a repo on GitHub that solves a technical problem. This allows me to see how they approach many aspects of the Software Development LifeCycle (SDLC), not just how to write a function. I want to see if the engineer can deliver this software in a way that makes it accessible to a broader team or audience and if they have the mastery of their language to handle advanced topics like package creation and design quickly.”
Junior Engineers:
“For junior engineers, I am more open to a coding challenge. I want to see their fluency with syntax and how they go about documenting their code. Additionally, we can learn how they organize their code for reusability.
Live Coding?
“Many firms like to have a live coding challenge; I am not a big fan of this practice. Although it allows us to feel confident that the software engineer is the one producing the work, it forces a social approach to what is often a solitary work endeavor.
“The SDLC for most companies consists of sprints and reviews. I prefer a similar approach to technical evaluations. Let the engineer take the requirements and come back with a working product. Note that I also like to see the engineer deliver this work via GitHub (or any Git repo) because I find basic Git skills one of the hidden deficits in many engineering hires. I want to make sure all engineers understand how to use Git for basic collaboration.”
#6 Use External Recruiters to Save Time and Create a Value-Added Hiring Process for Interviewers and Interviewees.
In a startup environment everything is created from nothing. This freedom on how to run your business is one of the most exhilarating parts but can also lead to an organizational nightmare.
Creating a process out of nothing can be intimidating and the importance of each early member on the team is vitally important to the success of the project. Recruiting a little help to organize your hiring process, get insight into the market, and cut the wasted time of scrolling through endless unqualified resumes is well worth it.
External recruiters can definitely seem like the enemy because they charge a fee for any individual they place with your company. They earn their keep though by only charging you if they find a suitable candidate that you decide to hire. They cut through the headache of searching tirelessly for the right fit candidate, get them into the interview process, and act as a mediator between both parties to facilitate negotiations and ensure all needs are being met — often with a replacement guarantee if things don’t work out.
Some of the best engineers and managers are extremely talented individuals – but not necessarily great interviewers. That isn’t their day-to-day job, so Kofi Group helps with that process.
In short, working with a recruiting specialist can simplify your process, save you a lot of time, and give you the end results you really care about.
Example Technical Questions to Ask
These questions are in no particular order of importance but may help to guide your interview. We aren’t going to lie, these questions were given to us by our interviewed sources and pulled from the internet as well.
We’re recruiters…not engineers.
Question: If you were to write an endpoint for checking if a resource exists, what path and method would you use?
The purpose of this question is to test the candidate’s knowledge of RESTful API standards. A common mistake when building endpoints is to use descriptive verbs in the path, instead a truly RESTful path should only contain nouns- the method used on the endpoint should determine the action.
Determining whether a resource exists is an action that is frequently required in APIs, but is rarely done correctly according to the RESTful and industry standards.
Question: Consider the following database table design. What is wrong with it and how could it be improved?
CREATE TABLE `notifications` (
`id` INT NOT NULL AUTO_INCREMENT,
`type` INT(8) NOT NULL,
`notifiable_id` INT unsigned NOT NULL,
`notifiable_type` VARCHAR(10) NOT NULL,
`relation_id_1` INT unsigned,
`relation_type_1` VARCHAR(10),
`relation_id_2` INT unsigned,
`relation_type_2` VARCHAR(10),
`updated_at` TIMESTAMP NOT NULL,
`created_at` TIMESTAMP NOT NULL,
PRIMARY KEY (`id`)
);
The key issue with the proposed table design are the object_id_X and object_type_X fields. It is considered poor design to increment named fields when the data could be stored in a related table.
Question: A common issue when integrating third party services within your own API requests is having to wait for the response, and as such, forcing the user to have to wait for longer.
How would you go about avoiding this? Name any relevant technologies if appropriate.
This is a good question to ensure they know how to properly use queues.
When a request is made to our API, a separate job is then created and added to a queue. This job will then be executed independently to the requested endpoint, thus allowing the server to respond without delay.
There are many queue providers they could suggest for the relevant technologies.
Question: How would you prevent a bot from scraping your publicly accessible API?
This question is a bit of a trick question.
If the data within the API is publicly accessible then, technically, it is not possible to completely prevent data scraping. However, there is an effective solution that will deter most people/bots which is rate limiting (also known as throttling).
Throttling will prevent a certain device from making a defined number of requests within a defined time. Upon exceeding the defined number of requests, a 429 Too Many Attempts HTTP error should be thrown.
Note: It is important to track the device with more than just an IP address as this is not unique to the device and can result in an entire network losing access to an API.
Other less-than-ideal answers include:
- Blocking requests based on the user agent string. Which is less-than-ideal because it’s easy to circumvent.
or - Generating temporary “session” access tokens for visitors at the front end. The problem here is this isn’t secure: Storing a secret on the front end can be reverse-engineered, thus allowing anyone to generate access tokens.
Hopefully these questions have got you thinking of a few good questions of your own to separate the average engineers from the greats.
But wait, there’s more!
Open Ended Brainstorming Questions:
Let’s run through a quick open ended brainstorming session or white boarding example to shed some light on how to do this efficiently.
Start by asking the candidate about a system that he/she worked on and ask them to design a small-scale system on the whiteboard.
Let the candidate design the database, middle-tier, and front-end. Then ask the candidate questions while he/she is creating the design.
Then dig deeper by asking these questions:
- 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.
- 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?
- Ask about how he or she would work with the other team members and how they currently work together.
- If management gave requirements to the full stack developer, and he/she is not familiar with the solution, what would they do?
- Ask questions about how to secure the full stack internally and externally.
- Ask them to build a task list application and describe how they would go about building it.
Ben further explained this last question and how his company uses it to identify really great engineers:
“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.”
Asking questions like these can clearly help you identify the experience and knowledge of the engineer you are interviewing. With this information it will be easier to identify which candidates can do the work required and succeed at your startup.
Interviewing a full stack engineer can clearly be a highly involved process. You need to consider if you’ll use an internal or external recruiter to find them, then see if they are a culture fit by including their future teammates in the process, find out if they are more geared towards front-end or back-end, and also thoroughly test their depth and breadth of knowledge and ability.
While the process can be tedious and time consuming, finding the right person for the role can make all the difference and be a huge value add for your team.
7 Red Flags To Look Out For
#1. Communication.
It’s a red flag if the candidate is not clear in his or her communication and very hard to follow in their answers. This is a difficult one because, let’s be real- they might just be nervous!
But pay attention to see if they have difficulty explaining themselves or their thought process.
#2 Having a complex design for a simple problem.
#3 Stubborn or over confident.
For example: You tell the candidate there is a solution for something and they get defensive or tell you (in so many words) that there is not a solution.
#4 Not willing to learn new technology.
#5 Bad or irrelevant questions.
This can show a lack of preparation and interest or it could mean they are out of their league in this level of work.
#6 Use of unknown technologies/frameworks that are not popular in the marketplace or known to most developers.
The interviewee could think this is a flex to showcase their skills in a rare technology but it could also be a ploy to hide technical ability in areas that are more applicable in the workplace.
#7 Giving vague or generic answers.
They may be in over their heads if you see them continually giving generic answers and unwilling to discuss things at a deeper level.
Next Steps
We hope this article helped you learn more about interviewing full stack engineers!
If you enjoyed this article you may also enjoy How to Assess Data Engineers in a Virtual Interview or How to Find A Remote Software Architect for Your Startup.
Kofi Group offers a multitude of resources to help you learn more, improve your career, and help startups hire the best talent. If you are interested in learning more get in touch today!