Engineer Technical Challenge

Why Are We Doing This?

We want to learn how you approach the 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 everything until implementation, with the output being a written artifact that we consider critical to any project larger than a bug fix or small improvement.

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 your option, we'll provide detailed feedback if we decide not to move forward.

Live (1 hour 15 minutes)

We'll talk through the challenge in person and document decisions. You'll lead, and we'll ask questions to clarify details and understand your tradeoffs. How you communicate is up to you (we'll use 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 (2 hours)

We'd like you to write a document specifying the product requirements, technical requirements, and implementation details. The document should be in a format that we can view easily from a browser (e.g., Markdown, Google Docs, Notion).

Other things to keep in mind:

• We expect you to return this within a week after you start. We understand that life can get in the way; just let us know if you need more time.
• We're happy to answer any questions anytime async or over a call!
• Spend around 2 hours on it (including asking us questions!). If you want to spend less that's fine. If you want to spend more that's fine as well, but spend it thinking not writing pages of text or expanding scope significantly. We like succinct submissions (which mirrors how we write internally).

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 define the data model persisted in the database and any non-obvious business logic to create and send custom forms like in Google Forms. You should approach this problem as if you're building Google Forms, not a feature in Ashby.

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 user can submit a survey anonymously.

Field types

We want to support the following form fields:

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

Persistence

The data model should reflect what is persisted in the database and, for simplicity, should be represented as objects with properties and relationships to other objects. Define it as you would in an ORM like ActiveRecord (rather than as tables in SQL). 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. Users can combine conditions with ANDs and ORs. For example:

1. Do you like lunch? (Y/N)
2. Do you like toast (Y/N)
3. Do you like pancakes? (Y/N)
4. Do you like brunch? (Y/N) Conditional on (1 == Y AND (2 == Y OR 3 == Y))

You must represent conditions as structured data (e.g., don't model it as a string).

And Anything Else

Document other requirements, details, or future considerations that you think are important for this product!

Expectations

Data Model

Here's an incomplete example of what a data model definition could look like:

1# Data Model
2
3Form
4 - id
5 - title
6 - field: Field[] // Order in array is order displayed
7
8Field
9 - id
10 - question: string

With this example, we can see how you're organizing data, how data relates to each other, and how that data is used to satisfy product requirements.

Explain what might not be obvious, and don't agonize over every detail, only the ones that matter. Notice that we don't specify types on every property.

What Does Excellent Look Like?

We like to be upfront about what excellent looks like — in doing so, we get the chance to see what you're capable of at your best.

Think about what Google Forms does and what kind of users it has. Consider what the product should do and then start defining the technical details. Engineers at Ashby put on their product manager hats, and we expect you to do the same here (but within the confines of the time allotted)!

Excellent writeups or live sessions:

• State assumptions made
• Consider product and technical edge cases
• Focus on explaining why the design is like it is
• Consider and describe what might need to change or be built to make this product better (e.g., support more use cases, handle scale)
• Are succinct and easy to read. Strong submissions are often under 2 pages

Also, remember that it's an interview, and you have less time than you'd have in a typical work environment. Cover the essential requirements and be intentional about where you go above and beyond.