Full-stack Take-home Assessment Example

This is a sample interview question that can be used for a 2-4 hour take-home assessment.

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 take-home interview question and rubric off of the template below! 

Edit and add skills you want to measure in the template
Create your own takehome assessment off of this template

‍

Intro

This take-home is designed to let a full-stack developer showcase their skills. In this example, we are looking to primarily gain signals of their: problem solving and debugging, building a full-stack feature, and database design skills.

Before you start: reflect if these skills are representative of what is important to your role/job description. We highly recommend that you edit this takehome so that is more suitable for your evaluation needs. If you are looking for any specific skills, here are a few examples of how you would remove/add/modify tasks to gain certain signals:

  • If you would like to evaluate for styling or frontend proficiency, you can instruct that following the design or making the application function according to the design is required.
  • If you would like to evaluate for the ability to work with third party libraries/API, you can instruct candidates to implement a translating feature into chat messages

This takehome challenge is designed to take between 2-4 hours.

Starter Code

To create a realistic working environment, where a developer would work on top of an existing code base and not always start from scratch, we recommend providing a starting code. This can either roughly represent the exact tech stack someone would work with on the job, or the option to choose from a couple of options (language, libraries, packages, etc.) so that developers can showcase their skills best with their tech stack of choice.

Instructions

Below is the problem statement that can be shared with candidates. You can share by one of these options:

  1. Email
  2. Google document or Notion document. Ensure you version these documents properly to keep track of the set of instructions each candidate was provided.
  3. When a candidate creates a new repository, have them invite you into it. You can create an “Issue” with the instructions.

Problem Statement

In this takehome assessment, we will be fixing a bug, implementing a new feature, and completing a database redesign.

Task 1 - Familiarize yourself with the project

Clone the project and familiarize yourself with the starter code. You can fork this starter code here: https://github.com/hatchways/messenger-starter. There are instructions on how to run the application in the README. Ensure you can run the application before moving on to the next task.

You will be submitting by opening a pull request. Please ensure you create and work on a new branch before you start.

Task 2 - Bug fix: Sending messages

Our starting code has some bugs that need to be investigated and resolved. One issue is that new messages do not appear immediately on the screen. We want new messages to show up instantly in the chat UI for both existing and new conversations. Additionally, messages are shown in the wrong order when the page loads. They should be displayed in chronological order, with the oldest messages at the top and newest messages at the bottom.

Cypress tests are included in the starter code for this ticket (bug-fix-ticket.spec.js).  These tests should pass once both bugs are addressed.

Create a new markdown file at the root of the repository called bug-fix.md. Please share in this file the steps you followed to debug this issue. What tools did you use?

Task 3 - Feature: Implement a read status for messages

We want to keep track of whether the recipient has read each message, and update the front-end UI accordingly. This includes showing the number of unread messages in a conversation. To see the different updates required to show unread messages, refer to this Figma file (Note: The Figma file contains other specs not relevant to this feature).

Create a new markdown file at the root of the repository called read-messages.md. In this file, please explain a couple different ways we could have stored the read status in the database for this feature. What are the benefits and drawbacks of each?

Submission

To submit, open a pull request. This pull request should illustrate clearly what changes you made compared to the starting code.

What happens next?

After submitting, review the code and refer to the rubric. Based on that, you can use the results from this assignment in different ways depending on when you use it in the interview process. The usual options are:

  • Follow up interview: To understand the candidate's work better, review the takehome with them. Ask about their decision-making process or how they would approach creating a new feature if product skills are important for the position.
  • Review and adapt: You can give feedback on their work and ask for changes, or let them keep going if you want to see more code in a certain direction.

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

  • [ ]  Is read status feature implemented according to the instructions?

Best Practices

  • [ ]  Does this submission follow React best practices?
  • [ ]  Does this submission follow general front-end best practices?
  • [ ]  Does the code prioritize performance? For example, does it avoid unnecessary re-rendering, nested loops, or API calls?
  • [ ]  Are any new routes introduces written with security in mind, such as making proper use of protected routes?
  • [ ]  Is the back-end code written with performance in mind, such as accessing the database efficiently and minimizing unnecessary nested loops?

Attention to details

  • [ ]  Does the submission show consistency across the files?
  • [ ]  Does submission show care about consistently maintain high quality output?

Problem solving & Debugging

  • [ ]  Was the async/await bug found and fixed?
  • [ ]  Was the mutating state bug found and fixed?
  • [ ]  Was the messaging display bug fixed properly?
  • [ ]  Was there evidence that the resources available were utilized well to solve issues?

Code Organization Readability and Maintainability

  • [ ]  Is the code written that keeps readability in mind?
  • [ ]  Is the code maintainable and extensible?
  • [ ]  Is the code consistent with the starting code base?

Written Communication

  • [ ]  Are the answers to the follow up questions easy to understand?
  • [ ]  Do they answer the questions asked?
  • [ ]  Do they provide a deep technical explanation?

Levels

Customize categories that would be important to evaluate for each level. For example it might be a higher priority to evaluate for strong written communication in a IC2 compared to IC1.

IC1 (”Junior” Engineer)

  • Strong No: Candidate is unable to submit an application that satisfies the basic requirements.
  • No: Candidate is able to submit a partially working application, but might have missed one of the bugs or left the read status incomplete
  • Yes: Candidate is able to get to the correct solution, but solutions to the bugs may be more work arounds than proper solutions, or there may be inefficiencies in the solution.
  • Strong Yes: Candidate is able to get to the correct solution for all parts of the assessment and is able to demonstrate strong instinct in several of the other categories.

IC2 (”Mid” Engineer)

  • Strong No: Candidate is unable to submit an application that satisfies the basic requirements.
  • No: Candidate is able to submit a partially working application, but the bugs are handled with work arounds rather than proper solutions, or the read status is incomplete.
  • Yes: Candidate is able to get to the correct solution for all parts of the assessment and is able to demonstrate strong instinct in several the other categories.
  • Strong Yes: Candidate is able to get to the correct solution for all parts of the assessment and is able to demonstrate strong instinct in most of the other categories.

IC3 (”Senior” Engineer)

  • Strong No: Candidate is unable to submit an application that satisfies the basic requirements.
  • No: Candidate is able to submit a working application, but attention to details lack and does not demonstrate strong instincts in most categories.
  • Yes: Candidate is able to get to the correct solution for all parts of the assessment and is able to demonstrate strong instinct in several the other categories. In written answers, candidate is able to communicate their thoughts thoroughly.
  • Strong Yes: Candidate is able to get to the correct solution for all parts of the assessment and is able to demonstrate strong instinct in most of the other categories. In written answers, candidate is able to demonstrate thoughtfulness when it comes to design and architecture and can provide a thorough technical explanation.

A follow-up interview is recommended to delve deeper into the candidate's understanding of their submission, particularly for those applying for IC2 and higher positions.

Want more take-home assessment questions and rubrics? Take a look at our free catalogue of assessments that cover full-stack, front-end and back-end roles.