“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.
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.
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.
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.
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:
The take-home exercise dives deeper into the question of technical fit. The specific prompt will vary, but the exercise will generally:
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?”
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.