How you are scored

Meta's own interview guides name these four focus areas. Google says every candidate is assessed with clear rubrics. The Tech Interview Handbook, written by an ex-Meta engineer, describes nearly the same four areas (communication, problem solving, technical skill, testing) across big tech companies (community-reported).

• can you find a way?

  Problem solving

  Do you understand the problem, compare approaches, and reach a good one, with or without a hint?

  show it by

  • Saying the brute force first.
  • Naming the slow part and the data structure that fixes it.
  • Stating time and space for each idea.

  train itpatternscomplexity

• can you build it?

  Coding

  Can you turn the idea into working, readable code? Meta's guide asks: "Can you convert solutions to executable code?"

  show it by

  • Real Java, not pseudocode.
  • Clear names and small helper methods.
  • Using the standard library well: HashMap, ArrayDeque, PriorityQueue.

  train itJava toolkit

• does it really work?

  Verification

  Do you test your own code and catch your own bugs? Meta's guide says finding and catching bugs in your code is a positive sign.

  show it by

  • A dry run on a small example.
  • Two or three edge cases, said out loud.
  • Fixing bugs calmly, before you say "done".

  train itedge-case checklists

• can we follow you?

  Communication

  Do you ask for requirements, explain your thinking and work with the interviewer? Meta's guide asks if you are "just diving into the code".

  show it by

  • Clarifying before coding.
  • Thinking aloud.
  • Taking hints and building on them.

  train itwhat to say

Communication matters, but it can't replace a working solution. interviewing.io looked at over 100,000 interviews on its platform (mock and real) and found that the coding and problem-solving scores mattered far more for passing than the communication score (community-reported). So: talk while you solve, never instead of solving.

Short notes from official prep pages. Read the full pages before your own round.

• official

  Google

  The interviewer is looking at your thought process, not only the answer. Asking for clarity, or for a few moments to think, is okay. Take the interviewer's tips seriously: they are hints.

• official

  Meta

  Four focus areas: communication, problem solving, coding, verification. The interviewer is there to collaborate, not trick you. They won't compile your code, so small typos are not the end.

• official

  Amazon

  From the SDE II prep page: write syntactically correct code, no pseudocode. Scalable, robust, well-tested code is the main evaluation criteria. Expect to give time and space complexity in almost every question.

• official

  Microsoft

  Ask clarifying questions and plan before you code; the round is 45 minutes. Test before you say "done" and point out your corner cases. Explain the Big-O.

Each of these is fixable in the moment. One recovery line is often enough.

• red flag

  Coding before clarifying

  Meta's guide flags "just diving into the code". The CtCI prep sheet says: don't dive into code without the interviewer's sign-off.

  recover

  1. Stop typing.
  2. Ask your two most important questions.
  3. Confirm the plan, then continue.

  say

  • Before I go further, let me confirm a couple of things about the input.

• red flag

  Long silence

  Google and Microsoft both say they want to see how you think. Silence hides it.

  recover

  1. Say what you know so far.
  2. Say the part you can't see yet.
  3. Try a smaller example out loud.

  say

  • Let me share where I am: the brute force works, and I am looking for a way to avoid the inner loop.

• red flag

  Ignoring a hint

  Google's intern guide calls interviewer tips helpful hints. Missing one wastes it.

  recover

  1. Repeat the hint back in your own words.
  2. Try it on your example.
  3. Say what it changes in your plan.

  say

  • Sorry, let me go back to your suggestion. You mean I could sort first?

• red flag

  Saying "done" without testing

  Microsoft asks you to test before you say "done". The Tech Interview Handbook says interviewers expect you to start scanning for mistakes on your own (community-reported).

  recover

  1. Take it back.
  2. Dry run one example.
  3. Check two edge cases.

  say

  • Actually, let me test it before I call it done.

• red flag

  Pseudocode instead of code

  Amazon and Microsoft both say: don't use pseudocode.

  recover

  1. Keep the pseudocode as comments.
  2. Write real Java under each comment.

  say

  • I will keep these steps as comments and write the real code under each one.

• red flag

  Wrong or missing complexity

  Amazon's SDE II prep page says you will be asked for time and space complexity in almost all your interview questions.

  recover

  1. Name n.
  2. Count the loops again, out loud.
  3. Correct yourself clearly.

  say

  • Let me correct that: the sort makes it O(n log n), not O(n).