What is it like to interview at Trunk?

Few people would admit that they love coding interviews, but they’re ubiquitous in the industry. What gives? Companies need to rapidly gain technical and cultural signals from you. At a startup like Trunk, everyone we bring on board is expected to contribute both in terms of writing code and participating in larger design decisions. Technical engineering interviews are the best simulation for estimating real on-the-job performance and for evaluating what makes a good engineering teammate.

So let’s start with what the Trunk interview is not. We won’t ask you any strange or esoteric questions like how many ping pong balls fit in a school bus. We won’t make you write out code by hand on a whiteboard. Our interviews aren’t structured to be antagonistic. We aim to frame our interviews more like pair programming exercises and design sessions in order to see what it’s like to work alongside you.

We’re publishing this interview guide in the interest of maximum transparency. We’d like you to enter our interview process as informed as possible, ready to show off the skills that we’re looking for and that you’ve worked so hard to acquire.

Engineering Interview Timeline

The first step in applying to work at Trunk is an initial screen. You’ll meet with one of our recruiters and be evaluated for general role fit. Expect to talk a little bit about your technical background and about what attracted you to Trunk.

Next is a one-hour Technical Phone Screen (TPS), where you’ll meet with an engineer. See more about problem-solving interviews below.

Finally, you’ll attend our onsite, which lasts about 4 hours. If you’re in the Bay Area, we’ll invite you to our SF office, but otherwise, we are a hybrid- and remote-friendly company. If you’re interviewing for a backend role, the onsite will consist of Problem Solving, Code Design, and Systems Design interviews. For Full Stack as well as for less experienced roles, the systems design interview will be replaced with a frontend coding problem in React.

The One-Hour Technical Interview

All of our technical interviews are with Trunk engineers. You’ll start with 5-10 minutes discussing your background and get an intro to Trunk. During your first screen, our Recruiter will ask you the technical project that you worked on that you’re most proud of and pass this along to the engineer who interviews you for the technical. Be ready to take us through this project in more technical depth and talk about your career experience, so we can get a sense of what you’ve worked on.

The next 40-50 minutes will be a technical interview using CodeSignal. Time permitting, the last few minutes will be reserved for any questions you may have about Trunk.

These are not meant to be “pass or fail” interviews but are geared more to see how you think through solving problems and how it aligns with how we do it at Trunk. We don’t do take-home tests because we respect your time–and we want to give you the opportunity to meet with more of our team and see how we work, collaborate, and ask questions.

Problem Solving

The Technical Phone Screen and one of your on-site interviews will be devoted to a programming problem, solved collaboratively via CodeSignal.

A programming language is a tool to get a job done, and we want you to put your best foot forward. The goal here is to produce clean, tested, and robust code. The programming language is your choice out of anything that CodeSignal supports–we’ve seen some uncommon ones! Note that we will adapt the problem as you progress to assess how you evaluate tradeoffs in design.

With that being said, we do have a preference for typed languages, especially if you have a few years of experience. That’s not to say you can’t use vanilla JavaScript or Python if that’s what you know best, but in those cases, you should put extra care into variable naming and legibility. Remember that you’ll have the compiler/interpreter to help you, and it’s ok to look something up mid-interview if you forget!

For our backend services and front end, we mainly use TypeScript, so this is a natural choice for these roles. If you’re applying for a C++ engineer role, we require at least some comfort coding in C++. We are looking for people who are thoughtful about expressing types and memory usage, etc. If you’re using Python, we recommend learning about type annotations and using those where appropriate.

There is nothing wrong with consulting the internet as a reference! This is a normal part of an engineer’s workflow. Questions may be ambiguous. This is by design. If you’re not sure about a detail, make sure you’re asking for clarification–clarifying ambiguity is one of your most important engineering skills!

While we don’t use questions that are particularly algorithm-heavy, we expect you to be solid on the fundamentals of computer science—common-in-real-life data structures and algorithms, big-O analysis, and so on. You won’t be expected to demonstrate knowledge of anything too specific or esoteric in an interview. Make sure you are intentional about how you handle functions and state.

Code Design

This is a design problem, where you’ll be expected to produce working code about a real-world problem. Take a sample application–how do you break down the problem? What interfaces will you create, and how would they change when you’re presented with new constraints? We want to see how you’re thinking about and using concepts such as inheritance, composition, encapsulation, and mutability.

To prepare, make sure you’re comfortable with a high-level language and be thoughtful about the class and functional designs you are making and encountering in your regular work. This problem is in between the scope of a Problem Solving and Systems Design interview. You’ll still be writing code, but we will be mainly indexing on your design choices. Make sure you’re pacing yourself and moving at an appropriate pace through the different parts of the problem.

For example, if you are designing a command line tool, prioritize how you are controlling the flow of data, and design sane and maintainable interfaces for how your components talk to one another. It would be less valuable to implement different output formats than it is to make sure your code is extensible enough to support such a feature.

Systems Design

The Systems Design interview is an open-ended collaborative exploration of the architecture of a larger software system. You will be asked a fairly broad question (e.g., “Design YouTube”) and begin to sketch out different components, guided by feedback and questions from the interviewer (note: more junior candidates may be asked to describe the design of a project you’ve worked on).

You should be able to zoom in and out on particular design details. You don’t have to know how to do everything from scratch, but you should call out the boundaries of your expertise and what you would research in order to inform your design.

For parts of the system that you can describe in more detail, you should also highlight the tradeoffs of each major decision and justify them (e.g., “I will choose rate-limiting strategy X because I expect this traffic pattern, but if the pattern turned out to be quite different, then maybe I’d go with Y…”). It’s important that you take an informed stance in order to get through the rest of the problem.

These interviews tend to be very much a choose-your-own-adventure. Make sure to budget your time well and be explicit when highlighting tradeoffs. While this may sound stressful, fortunately, it’s easy to practice–just choose any system and think through how it’s designed! Additionally, System Design Interview: An Insider’s Guide by Alex Xu is an excellent resource that has come out recently.

For virtual interviews, we generally use CodeSignal’s “Whiteboard” feature (powered by a diagramming tool called Miro). Some candidates have positioned themselves in front of a whiteboard that’s visible to their webcam, which is a fine option as long as it’s legible. Some candidates might prefer just sketching out their thoughts textually and using a little bit of ASCII art. Whatever gets the job done! In any case, make sure you’re comfortable with your preferred method (and okay with another one in case something goes wrong).

Frontend Interview

During the Frontend Interview, you’ll be asked an open-ended question on implementing a web page based on an existing application. All of our frontend components use ReactJS, so deep knowledge of it is a big plus. Depending on your level, this question can include designing an API skeleton, building out an example Single Page Application, asking about core features within ReactJS, discussing interactions between frontend and backend components, etc.

To prepare, make sure you’re comfortable coding in JS/TS and have at least a basic understanding of working with ReactJS. If you’re a frontend-only candidate, we don’t expect you to have a deep understanding of the full stack, but we will be diving into your knowledge of working with and communicating with backend services.

Culture Fit

Some of our interviews are non-technical. During the onsite you will also have the opportunity to chat again with a recruiter and with one of our co-CEOs. Be prepared to talk about yourself!

• What have been your experiences, positive or negative, with DevEx/DevOps/tooling at previous projects?

• What is a challenging project you’ve worked on that forced you to learn something new and grow?

• What are some of the process takeaways from iterating on past projects?

• What attracts you to working at Trunk?

We are still small and growing quickly, and every new person we bring on board will significantly shape our culture. How can you contribute? How would you like to contribute?

What makes someone a good fit for Trunk?

We’re looking for people who are willing to wear many hats. We are a young company, and our engineers frequently cross project boundaries or work on unfamiliar parts of the codebase. We are relatively light on process, so we are looking for people who love collaboration but are self-motivated and able to thrive in a less structured environment.

We build tools for engineers, so we’re especially interested in product-minded people who care about user and developer experience. We love a good story about improving an engineering process or practice. Every company has go-to engineers to manage complex internals and guardrails that keep things running smoothly. We’d like to think of adopting Trunk as being similar to adding those engineers to an organization. How will you make a difference in building the next generation of developer tools?

What is engineering like at Trunk?

Check out our blog to learn more about what kinds of problems we’re tackling!