Technical Live Interview Example Question
This is a sample interview question that can be used for a ~90 minute live technical interview.
Don't forget! Before you choose the right interview question and rubric, create a Job Kit. A job kit is your chance to really think deeply about who you want to hire, how you want to market the role, and how you want to find world-class talent.
Create From A Template
Feel free to create your own technical interview question and rubric off of the template below!
Create your own technical live interview off of this template
Intro
This question is designed to let a full-stack or backend engineer quickly write some working code. From there, depending on their area of expertise, there are a number of further challenges that would allow you to go deeper into an area of their strength.
Appropriate for IC1 - IC4 software engineers. Rubric varies a bit by level.
Problem Statement
We'd like to build a simple chat application today, with both a client and a server. You can use the frontend and backend language of your choice. Our first goal is to get an MVP running as quickly as possible using. From there, we'll hopefully have enough time to start digging deeper into a few more challenges.
Feel free to use any language of your choice and ask as many questions as you'd like. I'll be pair programming with you — you can think of me as another engineer on the team who is happy to give opinions/thoughts/guidance. You're also welcome to use Google or other tools you'd normally use — obviously, use your judgment and don't Google things like "how to solve chat/server interview question".
We'd like for you to talk through things as you solve the problem. This is important to us as it helps us a ton to understand your thinking and how you'd communicate with a coworker on the job. We want to understand your processes for debugging, problem solving, asking for help, etc.!
What happens next?
Timing: The first working version of the chat client/server should be completed within 30 minutes. Once the MVP is done, encourage them to test it as if they were about to send a PR. Have them spend another 10-15 minutes getting the code tested.
From there, ask them which direction they'd like to take things deeper. The typical directions are:
- Let's add 1-3 small product features. What would you add and why?
- Let's pretend this new chat app was blowing up and needed to support a much higher scale. What would you do as a stopgap to get to reasonable scale within a week? What would your long-term architecture evolve to?
Skills
Refer back to this rubric when evaluating a candidate to help determine if the signals gathered from the interview match your job requirements.
Correctness
- [ ] Does the code work as the candidate has explained?
- [ ] Are there any edge cases that the candidate hasn’t handled? Client handling of the server being down? Sending blank messages? Other bad user inputs, especially if more product features were added?
- [ ] Is there anything the code does that the candidate doesn't understand?
Comfort with tools
- [ ] Is the candidate fluent with their editor?
- [ ] Is the candidate fluent with their language/stack?
- [ ] Is the candidate using Google/Stackoverflow/Copilot/etc. efficiently?
Clarity/Simplicity
- [ ] Is the final solution showing high clarity of thought on how things work?
- [ ] Is the final solution as simple as you'd want to see in a production environment?
Documentation
- [ ] Is the code well-documented such that another engineer could come along and make edits?
- [ ] Is there an appropriate level of commenting showing code maturity? (eg., commenting tricky parts, not commenting silly things)
- [ ] Do they have a sense about what they'd write in a PR review?
Testing
- [ ] Is there a reasonable amount of unit testing?
- [ ] Can they articulate how they'd bring this to production safely?
Level Rubrics
Rubric - IC1 ("Junior" Engineer)
Strong No - candidate is not able to get to a basic "correctness" solution in 90 minutes.
No - candidate is able to get basic correctness, but either "comfort with tools" or "clarity/simplicity" is lacking.
Yes - candidate is able to get to a correct solution within 60 minutes, and is able to demonstrate strong instincts in the other categories, with one category a little weaker.
Strong Yes - candidate is able to get to a correct solution within 60 minutes, and is able to demonstrate strong instincts in all the other categories. Iteration into harder variants of the problem not necessary for IC1.
Rubric - IC2 ("Mid" Engineer)
Strong No - candidate is not able to get to a basic "correctness" solution in 90 minutes.
No - candidate is lacking in one of the major categories outlined above.
Yes - candidate shows proficiency across all categories outlined above within 90 minutes.
Strong Yes - candidate is able to make meaningful progress on one of the iteration challenges around scaling the infrastructure or product features.
Rubric - IC3/IC4 ("Senior" / "Staff" Engineer)
Strong No - candidate has a weakness in correctness, comfort with tools, or getting driving to a clear/simple answer.
No - candidate is able to demonstrate the basic categories, but isn't able to show comfort with documentation and/or testing.
Yes - candidate shows proficiency across all categories outlined above within 60 minutes and makes solid progress on one of the challenges around scaling the infrastructure or product features.
Strong Yes - candidate does all of the above and knocks one of the iteration challenges out of the park within 90 minutes.
Note: differentiation between IC3 and IC4 should come from some sort of engineering architecture interview, not this exercise.
Create your own technical live interview off of this template