A guide to technical interviews at Medium

Here at Medium, we realize that being asked to solve an unfamiliar problem on a whiteboard, is not the same as coding in your favorite IDE while listening to your favorite tunes. The goal of our interview process is to predict how you’ll perform once you join our team. Since interviewing ability has almost no correlation with employee effectiveness, we do our best to adjust our expectations.

This post will be your study guide as we’ll cover suggested reading material, our evaluation criteria, and finally some tips on interviewing.

Recommended reading

Please take some time to read through the following posts as they not only describe our engineering culture, but also how we value bringing together a team with different perspectives, life experiences, and educational backgrounds. More importantly, we’ve publicized our engineering rubric so you can walk in on the day of your interview feeling like you’re ready to ace a midterm.

Check out the Medium Engineering Blog for more

The interview process

We conduct several different types of interviews around coding, system design, career history, and employee values. Don’t worry, we don’t expect you to be good at everything. The whole point of the interview is to understand your boundaries — areas in which you excel, as well as your limitations. Chances are if you’re amazing at one thing, you can be amazing at other things, right? The good news is that Medium is an environment that fosters a growth mindset, so you’ll have many opportunities to develop your craft.

Step 1: Exploratory. AKA the friendly “get to know you over a cup of coffee” stage. This initial chat will cover highlights in your work experience, your aspirations, and a quick summary on Medium‘s roadmap and the problems we’re solving. We want to make sure there’s mutual interest and values alignment before moving into technical screens.

Step 2: Technical Interview. This is a one-hour interview with a Medium engineer where you’ll be asked to complete a coding exercise. We emphasize coding ability in our process, so it’s important to show interviewers your ability to write clean, maintainable, extensible code. This step can be done in-person or remotely via collabedit/coderpad (we’ll have a laptop for you for in-person interviews).

Step 3: Onsite Interview. The final interview panel runs about 5 hours with an hour break for lunch.

• Coding x 2. Similar to the initial technical screen, you will be asked to complete two additional coding challenges.
• System design. We’ll be asking you to design a system that performs a given task. The prompt will be open-ended, so remember to effectively communicate your familiarity with complex systems and your approach to design.
• Career history. A non-technical interview reviewing how you to got to where you are today. We want to hear about your biggest achievements, toughest challenges, high/low points, and anything else about who you are.
• Q&A. This is an unstructured Q&A with a member of the leadership team. Take advantage of this opportunity to get all of your questions answered about our engineering org.

Some tips on coding and design

We understand the stressful conditions of a 60-minute technical interview, so we’d like your input on how we can most effectively assess your technical ability. If you’re not comfortable whiteboarding, or like to spend a few minutes brainstorming alone, please let your recruiter know and we’ll do our best to accommodate. Here are some additional suggestions to help you prepare for your interview:

• Read through these tips on whiteboarding.
• Understand the problem. If any part of the requirements seem unclear, ask the interview for clarification. You don’t want to start off making the wrong assumptions.
• Plan ahead. Don’t jump straight into coding without thinking through the nature of the problem and a high-level structure/implementation.
• Break down the problem. For more complex problems, we look for the ability to provide simplified, well-factored solutions that break things down into something more manageable.
• Communicate your thought process. This will make it easier for the interviewer to provide guidance if you get stuck. You’re not here to answer CS trivia, but we do want you to have an understanding of what’s going on beneath the hood.
• Think about edge cases. Walk through your code to make sure it produces the right result. You should try to come up with a solution that handles most if not all edge cases.

Hopefully you found this guide helpful. We’re always looking for ways we can improve our process, so please send us your thoughts. Thanks for taking the time to interview with us and good luck!