The best thing you can do in an interview is make the interviewer picture you already doing the job.
Once that image takes hold – you on their team, solving their problems, relieving their stress – they start to feel relief, maybe only subconsciously, at the idea of you being hired. And when it comes time to make a decision, loss aversion kicks in. It’s psychologically harder to say “no” to someone you’ve already imagined saying “yes” to.
I got this idea from Ramit Sethi’s Briefcase Technique. The idea is simple: before a freelance or consulting pitch, you research the client’s problems, prepare a tailored proposal, and pull it out of your briefcase at the right moment when they least expect it. It can work really well. I’ve used it myself.
But it’s a lot of work. You need deep research on the company, the team, and the role. You need to guess right about what they care about.
The technique stuck with me, though, because underneath all that prep is a powerful principle about what motivates interviewers. They’re not hiring because they like interviewing. Interviewers hire because they need help with problems that stress them out.
But how do you paint that picture without a briefcase full of prep?
Gather intel in real time 🔗︎
Most interviews give you a chance to ask questions at the end. I think that’s backwards. At the end of the interview, it’s too late. Asking questions lets you shape your answers to the interviewer’s underlying problems.
I’ve interviewed hundreds of candidates. Almost nobody does this.
Most candidates are passive – they answer my question and wait for the next. Some candidates are aggressive in the wrong way. They hijack my questions to tell me their story at length instead of finding out about mine.
Look for opportunities to ask brief, targeted questions early at natural breakpoints throughout the interview.
For example, after the interviewer introduces themselves is a natural spot to respond: “Thank you. Do you mind if I ask a quick question? Given that you mentioned [something from their introduction], what do you see as your biggest priorities right now and how does this role fit into that?”
Learning about the person, the team, and the role will let you answer their future questions as if you were already on the team.
A few guidelines:
-
Don’t hijack the interview. Find natural pauses. You’re looking for openings, not creating interruptions.
-
Keep it brief. There’s limited time. You don’t want to come across as stalling or avoiding their questions.
-
Aim for curiosity, not interrogation. Ask one or two questions that flow naturally from what they’ve just said.
Customize your story in behavioral questions 🔗︎
Consider a common behavioral question:
“Tell me about a time you had to resolve a conflict with a coworker.”
Most candidates launch straight into a rehearsed STAR-method story.
Instead, try this first:
“I’d be happy to! Quick question – is conflict common on the team? Are people really combative with ideas, or is it more of an occasional difference of opinion?”
Now you have context. And you can shade the same real experience you have to match how things actually work on their team.
If they say the team runs hot:
“Well, if people have strong opinions, then if I were on the team, I’d want to quickly shift heated conversations to face-to-face. For example, at my current job, there’s an engineer who just sees the world differently than I do. I find that if we’re communicating asynchronously, things tend to escalate, so I make a conscious effort to meet in person when we disagree because that makes it easier to find common ground. Usually the real problem is that we have different engineering priorities, so I try to find meta-priorities we agree on and work from there.”
If they say it’s pretty chill:
“Well, if people mostly agree on things, then if I were on the team, I’d always want to assume best intentions and ask whether the conflict is worth our time. For example, at my current job, there’s an engineer who just sees the world differently than I do. When we disagree, it’s usually about priorities. We’ve learned to ask each other ‘on a scale of 1-10, how important is this to you?’ – usually one of us is willing to defer if there’s a big gap.”
Notice: it’s the same underlying experience. You’re not making anything up. You’re choosing which facets of a real story to emphasize based on what you just learned is relevant.
And by saying “if I were on the team, I’d want to…” you’ve done something subtle. The interviewer is now imagining your actual experience playing out with their actual team.
You don’t want to repeat that exact phrase robotically, of course. Vary how you plant the image. “On your team, with that dynamic, I’d want to…” or “If [specific thing they mentioned] came up in my first week…” The key is to reference something concrete they just told you. The more specific to their context and the more you allude to a future of you on the team, the sharper the picture.
Adapting this technique for coding interviews
This is harder to pull off, but you can still briefly contextualize the exercise as real work:
“I know this is an exercise, but if this were a ticket I was assigned, I’d want to understand the business context first. Are we already at scale where efficiency is critical, or would a simpler approach shipped faster be good enough?”
That single question does double duty. It sets up the Big-O tradeoff discussion that interviewers look for in coding interviews. But it also paints a picture of how you’d actually behave on the job – someone who thinks about impact and tradeoffs before diving into code. Keep it to one brief question here; you don’t want to eat into coding time.
Deepen the picture with your questions at the end 🔗︎
Asking questions early helps frame your story, so your questions at the end should reinforce the picture you’ve been building.
When you reach the “do you have questions for me?” section, don’t waste time on things you could find on the company website or Glassdoor. Ask questions that make the interviewer continue to imagine you in the role.
For example, you could encourage them to visualize you being helpful quickly:
“If I joined the team, what are your expectations for ramping? What would you want me to be able to do in my first month or first three months?”
“If I joined the team, what would you have me work on first?”
“Is there a project or initiative you’d want me to take ownership of early on?”
“Six months from now, what would make you feel like hiring me was a success?”
Time permitting, use their answer as a jumping-off point to tell a brief story about a time you did something similar.
Let empathy do double duty 🔗︎
You might be wondering: doesn’t this risk coming across as presumptuous? Couldn’t it backfire?
It could, if you do it clumsily. It takes empathy. If you can read the room, sense whether the interviewer is engaged or annoyed, and judge whether a question would feel curious or intrusive from the other side of the table, you’ll adjust your approach naturally.
The empathy you need makes it good for both sides.
From the candidate’s perspective, empathy allows you to gather your intel and paint your picture without overstepping.
But from the interviewer’s perspective, someone who naturally puts themselves in the hiring manager’s shoes – who asks about the work, anticipates challenges, and contextualizes their experience for the specific team – stands out from the crowd. That ability is itself a signal of high EQ and high agency.
I believe candidates who do this well are also genuinely better employees who can hit the ground running. (I don’t have data for that – just a couple decades on the other side of the table.)
Yes, the technique is a psychological trick. An honest one. It leverages loss aversion to improve your odds, and if you pull it off well, you prove that you’re the kind of employee they ought to be hiring anyway.