I’m interviewing a little differently this time round.

3 min readOct 19, 2022

While I was at PayPal, I did a metric ton of interviews, and I heard interview feedback from a bunch of different colleagues and friends.

I’ve made plenty of mistakes, and I’ve seen others make some obvious blunders too. Now I’m building OneText, and I can finally start hiring on the engineering side. So I’ve put together a list of things that are non-negotiable for our engineering interviews:

1. You’ll get the questions in advance

I put together a quick summary of what we’re doing so far and what we’re looking for in an engineer. It’s here:

https://gist.github.com/bluepnume/a6a7c793527067b770e49d2fa8cab3e2

At the bottom, I listed out most of the questions I’m planning to ask.

Interviewing should not be a pop-quiz, or a memory exercise, or an attempt to outsmart the interviewee. By sending the questions in advance, I’m going to get better, more prepared candidates.

2. Keep the coding to a minimum.

Engineers in the real world don’t write code with someone watching over their shoulder, under a strict time limit.

Honestly, I actually hate that I even need to do coding exercises at all in my interviews; so I hope to make this as brief as possible.

Sadly, one thing I realized over the years is that there are a confusingly large number of people who can talk-the-talk, but somehow just can not code.

So for me, the coding section of the interview is just a checkbox. Can you do it? Yep? OK, let’s move on to talking about something more interesting.

3. Real-world questions only

This is especially important when it comes to coding exercises.

I’ve seen so many engineers try to ask a clever sounding algorithm question that literally has no relevance to the job they’ll be doing.

Yes it’s great that you can sort an array in place. No, you will never need to do that.

I’ll be picking something small that I recently built, and asking the candidate to do that. Maybe a small component, maybe a utility function.

If it’s not something I’d do as part of my job, it’s just going to be a fake, contrived question, likely with a single predefined answer, and getting someone to do it will only prove if they’ve heard that specific question before or not.

No whiteboards. We don’t code on whiteboards in real life.

Language, library, or framework of choice. I want to see your real-world strengths. If I hire you, it’s because I think you can quickly learn whatever else you need to learn.

4. Googling is fine

My rule is, if it’s something you would normally do as part of the job, it’s kosher for the interview.

The number of times I’ve seen bad interviewers fail a candidate because they didn’t remember the nuances of a very specific, slightly obscure api, and they weren’t given the opportunity to google, is insane.

Google away. That way I actually get to see how you research a problem, and we don’t get stuck and waste time on some stupid detail.

5. Only plan for the first 25% of the interview.

The worst interview formats are question, response, question, response, ad infinitum.

The best ones start with a few questions and answers, then evolve into more of an in-depth conversation; the kind you might actually have when working with someone.

Sometimes it can be difficult to keep these conversations on track; that’s part of the skill of being a good interviewer, and not just falling back into the lazy question/response format.

I want to have a conversation, not an interrogation.

Like the sound of this kind of interview? Hit me up!

Here’s a rough description of what we’re doing at OneText: