charlie-morrison

Posted on Apr 30

How to Prep for a Developer Interview in 48 Hours (When You Just Got the Call)

#career #beginners #productivity #discuss

The interview starts in 48 hours. You found the posting yesterday. You haven't prepped at all.

This is the reality for most developers. You finally get the callback, and now you're cramming behavioral questions like it's a college exam.

I've been on both sides. Got rejected from interviews I was qualified for because I rambled through STAR answers. Got offers from interviews where I felt underqualified because I prepared the right way.

Here's the 48-hour prep system I use now.

Hour 1-2: Decode the job posting

Most candidates read the job description once and then practice generic questions. That's backwards.

The posting tells you exactly what they'll ask. You just have to read it properly.

Take the requirements section and split it into three buckets:

Must-haves they'll test directly: These are the technical skills they mention first. "3+ years of React" means you'll get a React architecture question. "Experience with distributed systems" means a system design round.

Culture signals they'll probe: Phrases like "fast-paced environment" mean they'll ask about handling ambiguity. "Cross-functional collaboration" means they want stories about working with non-engineers. "Ownership mentality" means they'll ask when you went beyond your job description.

Nice-to-haves they'll bring up casually: "Familiarity with GraphQL" won't get its own round, but someone might ask "have you worked with GraphQL?" in passing. Have a 30-second answer ready.

Run the posting through a keyword extractor to catch terms you might miss on a manual read.

Hour 3-4: Build your story bank

You need 5-7 stories from your experience. Not scripts. Stories with specific details that you can adapt to different questions.

Each story needs:

The situation in one sentence (what company, what project, what was at stake)
What you specifically did (not the team — you)
The measurable result (numbers, percentages, time saved, bugs prevented)
What you'd do differently (shows self-awareness, interviewers love this)

Pick stories that cover these themes:

A technical challenge you solved
A time you disagreed with someone and handled it well
A project that failed or went sideways
A time you learned something quickly under pressure
A time you helped someone else grow
A time you made a mistake and fixed it
An initiative you started without being asked

Most behavioral questions map to one of these seven themes. If you have a story for each, you can answer almost anything without making stuff up on the spot.

Hour 5-6: Practice the technical round

This depends on the role. But here's what most people get wrong: they practice on LeetCode when the interview is a system design round, or they study architecture when the interview is a coding screen.

For coding screens: Pick 10 problems at the level the company tests (check Glassdoor for recent interview questions). Focus on explaining your thinking, not just getting the right answer. Practice talking while you code. Silence is what makes interviewers nervous, not wrong answers.

For system design: Pick the system closest to what the company builds. If they're a payments company, design a payment processing system. If they're a social platform, design a feed. Use interview prep tools to generate questions specific to the role and company.

For take-homes: Read the requirements twice. Build the simplest thing that works. Add one small touch that shows you care (a README, error handling, one test). Don't over-engineer. They're testing judgment, not complexity tolerance.

Hour 7-8: Research the humans

This is what separates candidates who get offers from candidates who get "we'll be in touch."

Find your interviewers on LinkedIn. Read their recent posts or talks. Check if they've written blog posts or given conference talks.

In the interview, reference something specific: "I saw your talk on migrating to microservices — we faced a similar challenge at my last company." This shows genuine interest, not the performative kind.

Check the company's engineering blog. Read the last 3 posts. Note the tech stack, the problems they're solving, the tone they write in. This tells you more about the team culture than any Glassdoor review.

The day before: logistics and mindset

Logistics checklist:

Test your video/audio setup (camera, mic, headphones)
Have a backup internet plan (phone hotspot)
Close all tabs. Turn off notifications. Tell your roommate.
Have water nearby. You'll talk for 45 minutes straight.
Keep a notepad for jotting down question details before answering

Mindset shift: You're not auditioning. You're evaluating them too. Prepare 3-4 questions that actually tell you something:

"What does the first 90 days look like for someone in this role?"
"What's the most frustrating part of working here that I wouldn't see from the outside?"
"How does the team handle disagreements about technical direction?"
"What happened to the last person in this role?"

These questions show you're thinking about the job, not just hoping to get it.

After the interview

Send a follow-up within 24 hours. Not a generic "thanks for your time" — reference something specific from the conversation. Keep it to 3 sentences. A follow-up email tool can help if you're stuck on wording.

If you don't hear back in a week, one polite follow-up is fine. After that, move on. Chasing hiring managers doesn't work.

The uncomfortable truth

Most interview prep advice tells you to practice hundreds of questions. That's comfort-seeking disguised as preparation.

The candidates who get hired know 7 stories cold, understand the specific company they're interviewing at, and can explain their thinking clearly.

That's it. No magic framework. Just preparation that respects the interviewer's time and your own.

How do you prep for interviews? Especially curious about the time-constrained version.

DEV Community