DEV Community

Cover image for What Google, Amazon, Microsoft and Meta actually say about their interviews (and a free prep site I built from it)
Payanai
Payanai

Posted on

What Google, Amazon, Microsoft and Meta actually say about their interviews (and a free prep site I built from it)

Most interview prep online is a mix of leaked questions, hearsay and "Top 75" lists. I wanted the opposite: what each company says about its own interview process, in one place, with practice questions I could trust.

So I read the official hiring pages for Google, Amazon, Microsoft and Meta, and turned them into free guides on Nokku: nokku.payanai.com/interview-prep. No sign-up.

Here's what stood out, then how I built it.

What the companies actually say

Google describes structured interviews: every candidate for a role gets the same questions and the same scoring rubric. Its own guide names role-related knowledge, problem solving and leadership. In 2025 Google also said it's bringing back at least one in-person round, citing AI-assisted cheating in virtual interviews.

Amazon runs a phone screen of 30 to 45 minutes, then a loop of 4 to 6 interviews of 45 to 60 minutes each, including a Bar Raiser: a trained interviewer from outside the hiring team. Every interview checks for its 16 Leadership Principles, and about half of a technical loop is behavioural. Amazon suggests STAR answers of about 2 to 3 minutes.

Microsoft is refreshingly specific: code in your strongest language, no pseudocode, know at least one O(n log n) sort in detail (preferably two), and manage your time in a ~45-minute round. It also says it looks for a growth mindset.

Meta describes a 45-minute tech screen (roughly 5 minutes of intros, 35 of coding, 5 for your questions), then a loop of coding, design and behavioural interviews. The process usually takes about 2 to 3 months. And the big change: Meta's hiring page says technical interviews now include an AI assistant built into the environment.

The common thread across all four: think out loud, get to working code, then improve it. Meta says it plainly: non-optimal but working code beats just an idea.

How I built it

A few decisions mattered more than the code:

  • Official sources only. Every guide lists its sources and a "facts checked" date. If something is widely reported but not official (for example Google's "Googleyness" or its hiring committee), the guide says so.
  • Original practice questions. No leaked or copied problems. Each one is written in the style of common interview questions, with hints you reveal one at a time and a full solution.
  • Every solution is tested. Each one is che version on thousands of random inputs before it ships. Writing the test caught one of my own wrong "expected answers".
  • Content as Markdown. Guides are plain `.m rendered with the same components as the site's courses: flashcards, quick checks, step-throughs, and a new "practice question" block.
  • Infographics from data. Each guide's "at rs, a timeline, how time splits) is generated from frontmatter. The facts live next to their sources, and the hub builds a side-by-side comparison of all four companies from the same data.

What's inside each guide

  • The process as a step-by-step timeline
  • What interviewers score you on
  • Pattern flashcards (two pointers, sliding winn's Leadership Principles
  • Behavioural scenarios with feedback on each choice
  • 3 original practice questions with tested sol
  • A 4-week prep plan

Try it

👉 nokku.payanai.com/interview-prep

It's free, with no account. I'd love feedback: which company or topic should I add next? And if you've interviewed at one of these recently, does the process match what

Top comments (1)

Collapse
 
launchgatecheck profile image
Launch Gate •

Keeping the comparison and infographics driven by the same source data is a good choice. For the next topic, I'd add role and region exceptions: which guidance applies to all candidates, versus one technical track or location? A company-wide "facts checked" date can otherwise make a narrow source look universal. Per-fact source links and scope labels would also let you mark one claim stale without making the whole guide look outdated.