We've decided to make less money: We've slashed our pricing for session replay. They're now more than 50% cheaper for most customers.

Interview technique - principles to follow

Last updated:

|Edit this page

Reminder: hiring the right team is the most leveraged activity we can do. Whatever you do, focus on getting the strongest signal from a candidate in an interview. Do not focus on scalability / efficiency.

Focus on themes

Many well-intentioned interviewers will create a long list of questions that they'll follow rigorously. This is likely to lead to shallow answers.

You're trying to understand how a human being operates, so go deep. It'll be more interesting for both of you, and will give a stronger signal.

Prepare the themes in advance you'll want to ask about. For a cultural interview, it might be something like:

  • scrappiness
  • low ego
  • ambition
  • able to write code
  • optimist

For each of the above themes, consider some good questions in advance. Use these as starting off points.

Ask permission to get what you need

Candidates' expectations of interviews vary wildly.

Less experienced candidates, or those in less competitive markets, often expect an intense questioning.

The reverse is true for more experienced candidates - who will want to understand if the company is performing well, aligned, and many more things to help them pick the right place to work.

At the start of the interview, "name it". Say to the candidate something like "hey, I need to go deep on how you work to do the best assessment of a good fit here, is it ok if I focus this interview primarily on that for the first 20 minutes? Then I'll leave 10 minutes at the end for questions. If we overrun, I can book more time with you." Other times, you'll need to explain the opportunity more - for example, if the candidate came through cold outreach. Have a clear idea before you start, and explain it to the candidate up front.

Work as a team

Focus your questions on the areas you're stronger at. If you're great at scrappiness, you're probably best suited to spotting it in others.

It's more important to validate a few things well, and to get others to dig deeper in other areas, than it is for you to do a shallow interview across everything. If you miss something, just create a clear ask of your next colleague to cover the area you missed, or to dig deeper on an area you felt uncomfortable with.

Don't bias yourself

When you do your final write up on a candidate, do this ahead of reading the feedback from others.

Humans are evolved to stick to their tribes - if you know that your colleagues believe X, you're much more likely to believe X. Reading others' feedback means you are less likely to say no to someone because of minor concerns or to push for a candidate with hidden talent. Both things we need to do.

Bonus points - writing your own independent decision in front of your peers, forces you to clarify your feedback properly.

Figure out why you're not excited

You will be asked to give a score out of 4 for each interview (where 4 is the highest). If you don't give a 4/4, please articulate as clearly as you can why, even if it's a minor concern. This helps (i) subsequent interviewers to dig further into a concern to validate/invalidate it and (ii) it may cause other people to spot/mention the same issue - which can stop us moving forward with someone that won't be a good fit.

Some of the hardest decisions are when lots of people are fairly lukewarm on a candidate. This is particularly likely when a candidate has relevant experience but is a poor cultural fit.

Beware of how you're feeling through the interview, and adapt as you go.

If a technical interview makes you feel worried someone isn't fast, energetic, or intelligent enough, or whatever else - do some digging on those themes.

Write out mild concerns

Imagine any perceived issue being magnified 10x when the candidate starts. Mention in your feedback to others if you had a mild concern about something. Sometimes you'll find that everyone shares this concern, which means we shouldn't hire.

Get specific

Going into detail helps you figure out the difference between someone that sounds good and someone that is good at their job.

How did they solve the impressive sounding technical problem? Why did they solve it like that? Did they drive the project or were they a passenger? Who actually wrote the code?

In one interview, assessing organization skill, I've even found out how a candidate used to organize her fridge. "What's something you've done that is so organized, that it was weird".

Keep it on track

Some candidates, due to nerves, will go down rabbit holes. The ability to sum up information concisely, under pressure, usually isn't something that appears in our job descriptions.

Therefore, if a candidate goes way off track, it's in their interest for you to politely interrupt "hey I think I've got what I need here on this question, I'm going to move on so we cover everything - is that ok?"

Focus on slope

... and be very wary of getting seduced by companies rather than people. Candidates who've worked at places with strong product market fit will have had an easier time achieving results. Some of our best people have come from a string of very average startups.

As the interviewer, you should feel a little nervous

A short interview has a huge impact on our company - either hiring the right or wrong person. There are lots of hard-to-reverse consequences of not getting it right.

Bring energy into the interview. Be engaged. You are part of our brand.


Was this page useful?

Next article

Engineering Hiring

Engineering hiring at PostHog Engineers make up around 60% of our team, and we are almost always hiring for Engineering roles. Please check our careers page for our open roles. What we are looking for in engineering hires Beyond the specific skills listed in the job description, we generally look for: Experience with relevant technologies (Python or similar, React or similar, something to do with big data is a bonus) We don't care how many years of professional experience you have, but…

Read next article