Dev Hiring Process


“Good fit” can be boiled down to the question “Do I want to work with this person?” The criteria we use to judge fit fall into two broad categories: technical skills, and culture fit.

Technical Skills

Part of good fit is ensuring that the technical background is a match for contributing to the work at Narrative. This means not only being able to write code “to spec,” but being able to write good code. While “good code” can be as subjective as “good art,” we generally think of good code as being correct, performant, and maintainable. Or, if we’re being more tongue-in-cheek: “Would I be OK working on this person’s code in 6 months?”

Experience in our specific stack is a plus, but we don’t need a strict match on a list of buzzwords. However, showing deep knowledge in a given area is important – someone who identifies as a “data engineer” should know about map reduce, a “frontend developer” should know how the http lifecycle works, and so on.

Culture Fit

Do we agree on the principles by which work gets done? See the Company Culture page for more information on how we think about culture overall.

Steps in the Process

While there can be some variation depending on the candidate, the process generally follows these steps: initial chat, take-home exercise, follow-up on the exercise, and then in-person meeting.

Initial chat

The initial chat is the proverbial “jerk test.” The goal here is to have a quick chat to start gauging fit and discover any potential dealbreakers up front. Logistically, this means:

  • A quick (30 - 45 min) call, usually via Google Hangouts or over coffee locally if applicable.
  • Conversation about the background of the business and the team, where we are now, where we are looking to go.
  • Conversation about the candidate’s experience. What are their areas of expertise, and what have they been working to improve? How much overlap is there with what Narrative is looking for?
  • Conversation about the candidate’s goals. What type of technology do they like/dislike? Do they prefer more autonomy or more structure? Can Narrative provide the type of environment that the candidate is looking for? Fit goes both ways.
  • Conversation about next steps in the process and overall expectations.
  • No FizzBuzz. We’re pretty sure everyone has memorized all the variations in printing odd numbers, animals, and the contents of shopping carts by now. It’s tiresome to the applicant and low signal to us.

Take-home Exercise

The take-home exercise dives deeper into the question of technical fit. The specific prompt will vary, but the exercise will generally:

  • Be completable within a couple of hours to a day, depending on how deep the candidate dives. We don’t want anyone to do free work for a week.
  • Be agnostic enough to tech stack that the candidate can work with the tools of their choice.
  • Resemble day-to-day software development as it happens at Narrative, as opposed to algorithmic trickery from Project Euler.

Since this is a sample exercise, we don’t expect fully production-level code. e.g. it’s okay if the database is H2 instead of dedicated Postgres, or if the schema doesn’t take sharding into account, or if a web service doesn’t handle thousands of requests per second out of the box.

On the other hand, at the end of the day this exercise is a still a work sample. What edge cases were considered? How is ambiguity in the prompt handled? How is the code organized, and is it idiomatic to the language and tools being used? If we were just looking at “Can this person write any code?”, then FizzBuzz would do just as well. What we’re trying to figure out with the sample is, “Can this person write good code?”

Follow-up Discussion(s)

The follow-up discussion dives deeper into the prompt from the take-home exercise. The first part is discussing the submission itself. Are there any bugs in the submission? Are there any style or design choices that we want to get into? The second part is taking things to a higher level. How would this code change as we take it to production? If it’s a backend system, how would the architecture look at scale? Are there any bottlenecks as it is currently written? If it’s a frontend system, how would we adapt to new UI requirements? What might we do to streamline the workflow and make the user experience more pleasant?

Finally: Overall, how was the communication during this process? Do both sides feel they could work together effectively after this?

For remote candidates, there will also be a follow-up call to meet the founder/CEO just to go over some more aspects of the company and the business that are not covered in as much depth during the technical calls.


Assuming everything prior to this has gone well, we should be 80% sure that we would like to move forward. The final step is a trip out to the New York office, where the candidate can meet the CEO as well as the rest of the NYC folks in person. The goal here is to dot the i’s and cross the t’s, and really nail down the culture fit and make sure everyone is on board before moving forward.