Below is an article originally written by Ritu Vincent, Engineering Manager at PowerToFly Partner Checkr, and published on May 23, 2017. Go to Checkr's page on PowerToFly to see their open positions and learn more.

I recently switched jobs after spending four years with a company and team that I absolutely loved, and while I was ready to move on and find something new, I told myself that I had to find something pretty amazing before making any decision to switch. This meant I spent a lot of time (far too much, to be perfectly honest) interviewing with and talking to a LOT of different companies in San Francisco, so I could be absolutely sure I was making the right call.

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.)