Engineer Technical Challenge

Last updated February 1, 2022

Why Are We Doing This?

We want to learn how you approach the types of problems we're solving. At Ashby, you'll take high-level product direction, flesh out product requirements, and turn them into a technical design and implementation.

This challenge simulates that. We want you to design and prototype an API for a relatively open-ended problem. At Ashby, this is mostly the first step of any major project—a proof of concept in which we only invest a few hours.

Take-home or Live

We provide both a take-home and a live-over-Zoom option for this challenge. We don't have a preference for what you choose; pick whatever is convenient for you!

Regardless of which option you take, we'll provide detailed feedback if we decide not to move forward.

Live (1 hour 15 minutes)

You'll spend time with us talking through the challenge in person. We don't want you to code; instead, we'll focus on the design of the data model and business logic. How you communicate is up to you (we'll provide Miro to draw and a collaborative markdown editor to write). We ask that you read this document before we meet. We'll reserve 15 minutes at the end for you to ask questions about Ashby.

Take-home (3 hours)

We'd like you to build a working prototype using any programming language you want. It should also include a write-up explaining the most critical design decisions and any open questions or future considerations. The write-up is essential: how you think is more important to us than how quickly you can write code. If you find yourself running out of time, spend it explaining what you want to do rather than building it. Other things to keep in mind:

  • We expect you to return this within a week after you start.
  • We're happy to answer any questions anytime async or over a call!
  • Spend at most 3 hours working on it (including asking us questions!).
  • We'll discuss your submission during your onsite interview.

Since the live option allows you time to ask questions about Ashby, your hiring manager is happy to book the same amount of time after you submit. Just ask!

The Challenge

Your goal is to build a proof of concept "API" to define and send custom forms like Google Forms.

The "API" can be objects and functions calling each other (similar to an ORM). We don't want you to spend time building a user interface, frontend, GraphQL/REST endpoints, or backend. Those parts are relatively straightforward once the underlying data model and business logic are defined. Focus your time on the creative stuff 😁.

Here's an incomplete example of what this "API" might look like using object-oriented design in Typescript:

1// API
2class Form() {
3  // Moar properties, functions...
4  public fields: Field[] = [];
5
6  // Adds a new field to the form
7  public addField(field: Field) { this.fields.push(Field); }
8}
9
10class Field() {
11  // Moar properties, functions...
12  public addConditional( /* TODO */ ) { /* TODO */ }
13}
14
15// Use the API
16const form = new Form();
17const field = new Field();
18form.addField(field);

With this example, we can start to see how you're organizing data, how data relates to each other, and what actions could be performed by the system to manipulate the data.

Requirements

The data model should express how custom forms are designed, sent, and submitted. For simplicity, don't define a user model or how authentication works. Assume, like in Google Forms, a survey can be submitted anonymously.

Field types

We want to support the following form fields at least:

  • Plain text box
  • Email text box
  • Single select dropdown
  • Boolean field
  • File field

Persistence

While you don't need to implement persistence for this challenge, assume that you're designing an API for a stateless server.

Conditional fields

We want a user to define a field that only becomes visible if a previous field has a specific value.

Please feel free to implement/document other requirements that you think are important for this product!

Goal

Again, the goal is not to build a fully-functional API or a user interface. We hope you can develop an interesting proof of concept (and write-up for the take-home option) that allows us to discuss the tradeoffs of your approach.