Breaking The Mold: Interviews At Checkr
Most engineering interviews in the Bay Area follow the same standard pattern — some amount of whiteboard coding, most often with a focus on algorithms and data structures, maybe some high level architecture design for more senior engineers, and a tiny bit of time getting to know about your future work environment over lunch or through a few minutes of (frequently rushed) Q&A with your interviewers.
This is a pretty broken process. Whiteboard coding is extremely contrived — no one actually codes blind with no access to an IDE or documentation or Stack Overflow on your actual job. In thirteen years of being an engineer, I've never had to balance a red-black tree or write out the implementation of insertion sort from memory as part of my job (even though both are interview questions I've encountered at very respectable tech companies). And when your most critical decisions during an interview are "should I use BFS or DFS?" or "should I use a map or a list?", you're not really getting a chance to show your potential employer what you bring to the table.
Every engineer I've spoken to acknowledges that this kind of interview is silly, and yet very few companies seem to be doing anything different. Two stand out in my recent experience — Stripe, which has been a notable trailblazer for the last few years when it comes to interview practices, and Checkr, which I was particularly impressed by (and eventually ended up joining).
Interviewing at Checkr
Checkr's interview loop starts, as most others do, with a phone screen, and then moves to a full day onsite. However, Checkr doesn't use any questions with "one magic answer", so there's no secrecy around the loop. My recruiter told me what each interview would be like weeks before I came onsite, and each of them evaluated things that good engineers do instinctively.
For example, one of my favorite questions during the day was a refactoring exercise, where I was given a chunk of bad code and asked to clean it up. This measures multiple things: 1) the ability to look at new code written by someone else and understand what it's trying to do 2) the ability to recognize ugly or inefficient code 3) the ability to change existing code without breaking functionality and 4) the ability to explain your changes to someone else and point out why you think it makes the code better.
This is what a majority of engineers spend most of our time on, so this ends up being a far better evaluation of engineering ability than an artificial toy problem on a whiteboard. In addition, throughout the entire interview, I was on my personal laptop, on an IDE of my choice, with full freedom to pull up any resources I needed (syntax, documentation, data structures, blog posts, etc.).
Two other coding interviews were also very hands-on, one focused on building a small end-to-end system and the other on solving a problem very relevant to Checkr's product space. All these exercises required me to spend more time thinking about testing, API design, and code cleanliness, and less time worrying about whether I could discover the "trick" that got me to the most elegant solution.
A second interview was a high level architecture problem, which is pretty standard practice, but instead of a standalone imaginary system, I was asked to basically design the Checkr system. The first half of the interview, I collected requirements from my interviewers and came up with a design I liked; the second half of the interview, my interviewers spent time talking about how their actual system differed from or matched what I had designed. By the end of the interview, both sides had had a good opportunity to evaluate each other, and I had learned a lot about what I would potentially end up working on.
Besides the technical interviews, I also got to have lunch with a small friendly group, which was far less awkward than the usual 1:1 lunch which my natural introversion always struggles with (I never really know if I should use a lunch break to talk more about myself, make small talk, ask more questions about the company, or, well, just eat. Being part of a group takes a lot of pressure off). And finally, I met with someone from HR and had a chance to ask questions about the company culture and career growth options, and generally get a sense of what life at Checkr was like.
At no point during the whole process did I feel like I needed to have "prepped" for these interviews. And that's how all interviews should feel. After all, I don't prep for a normal day at work. I don't spend time on weekends reading through books and posts that talk about the quickest way to "crack" code before I feel ready to come in on Monday. The best interviews should measure your real self, not who you are after a week of frantic studying.
I'd love to see more tech companies switch away from the traditional whiteboard interview. The whiteboard has had its time in the sun, and the technical interview is long overdue for a bit of disruption (sorry, I couldn't resist — I've been talking to way too many startups.)
Finally, quick recruiting plug :) Don't go and put yourself through yet another contrived graph traversing interview loop — come talk to us at Checkr!! We're hiring!
Also, read more about Checkr's interview loop here (this includes more detailed descriptions of what to expect with each interview, and what we look for when evaluating candidates.)
An Engineer’s Guide To Interviewing at Checkr
We've all spent endless nights cramming for an interview with no clue as to what will or will not be asked. At Checkr, we wanted to make the process better from an engineering perspective and remove all the things that make us cringe while interviewing. That is why we put a lot of thought and empathy into designing our interview process. Our goal is to make it to be indicative of who you are as a software engineer. The hardest thing isn't finding talented engineers, it's finding engineers that people want to work with. Our ideal candidate needs to embody Checkr's core values:
drive and grit, humility, smart and resourceful, connection, learning, excellence with purpose, transparency, positivity, and appreciation.
What we look for in a candidate
An ideal candidate to us is someone who likes to explore and learn things that are outside their scope and comfort. It is someone who can demonstrate a high degree of drive and grit tempered with authenticity. Someone who values forming real and meaningful connections in order to create an inclusive community which helps bring the entire team up rather than just themselves. We value those who exhibit honesty and appreciation from the simplest solution to the most complicated one. People who appreciate diverse backgrounds and understand that diversity is not just an initiative but a mentality tend to thrive at Checkr.
Our Web Application Team working hard =)
"Who you are at home is who you should be at work. We want the best version of you and want you to be comfortable here."
— Khoi Ho (People Ops)
Key To Success
Communication, communication, communication! This is the key to success at Checkr. We are looking for engineers who are able to convey their thoughts, help us understand their process, and most importantly, ask for guidance when they hit a roadblock. We are here to help! We want our interviews to be the best representation of who you are as an engineer. Don't be afraid to ask questions, this will allow your interviewer to better understand your problem and provide the right guidance for you to succeed. We want you to be part of the Checkr team.
Environment Setup
In order to avoid any hiccups or unseen problems, here is what you will need during the onsite interview:
- a working datastore
- a working dev environment with a web programming language of your choice
- a testing framework
We don't mind what languages and tools you're using, just use the ones you're most comfortable with!
Here's what our interview process looks like:
1. Resume Screen
We're evaluating whether you're a good fit for the position you applied for. We receive many amazing candidates but not everyone will be a good fit for Checkr or vice versa. We're not interested in what school you went to, what your GPA was, or even what clubs you were a part of. What matters most to us is that we fit well together and that you're passionate in what you're doing.
2. A Call with Our Technical Recruiter
This process takes about 30 minutes and the main focus is talking about your interests and what it is you're looking for. It helps us determine whether we may be a potential fit for each other.
3. Live Coding Session Done Through Coderpad (We're fans of Python, Ruby or node.js but any language is fine)
As a background check company, it's crucial that we match the identity of the applicant with any data we have, pull or find. The accuracy of determining and matching names is our business. Our live coding session consists of a name matching exercise that is the foundation of your success at Checkr. We found out quickly this is a great indicator for future performance and success on the job. The challenge will consist of verifying names in a given list. You will have a few test cases to test your solution against and one bonus transposition question.
We give our candidates an hour to complete this exercise. We're looking for code that is clean, DRY, readable, and expressive. We want you to talk us through your process, help us understand your decisions — your interviewer is your best advocate. They will help guide you through potential roadblocks and help discover things that you may not have seen.
4. Onsite interview (4–5 hours — 5 interviews)
Our onsite interview is meant to simulate what your day to day would be like at Checkr. These interviews will consist of design, implementation, debugging and refactoring. You can use whatever programming language, environment or editor that you are most comfortable with. We want our interview to be indicative of who you are as an engineer, so please feel free to use any online resources you would normally (Wikipedia, Google, Stack Overflow, etc.) during work. Remember, your interviewer is a collaborator, share what you're thinking and ask for help when needed.
A. Whiteboarding Architecture
This portion is to demonstrate your understanding of microservices and explain an API request life cycle.
B. API Design
We will provide you with a dataset that needs to be imported into your selected datastore. You will be tasked in building out a light JSON API that can read, delete and update. The objective of this interview is for us to gauge your understanding of your datastore, web framework and approach to testing.
C. Object design
This exercise focuses on designing an existing feature at Checkr. More specifically, we'll collaborate on exploring a rule-based system to assist in automating background check processing. Areas to cover will include building a data model and its respective application interface for rule evaluation. Be ready to discuss your schema and thoughts on how to optimize for performance.
D. Refactoring
The slot is used to understand how you communicate, collaborate with your interviewer, and familiarity with your selected language. We want you to show us how you work in your natural dev environment from utilizing known and unknown resources to asking follow up questions, we are curious to see your workflow.
5M background checks reached — 2016
After the interview, we tend to move fairly quickly! You can expect to hear from us within 48 hours with a decision. We strongly believe in transparency so providing feedback is crucial. We want to thank you for taking the time to interview and expressing interest in a career at Checkr! We hope your experience at Checkr is delightful and as pleasant as humanly possible. If you have any questions at all, please let your recruiter know so we can help ensure your success. On behalf of the Checkr team, good luck!
