The short answer
A Google-style mock interview is a practice round shaped like the interviews Google is widely reported to run: coding and problem solving across most rounds, system design for more senior roles, and a conversation about how you work with others. On Revvox each round is 60 minutes live with an experienced engineer, scored 1 to 5 on five skills, with a written report within 24 hours. We are not affiliated with Google, and we do not claim our interviewers work there.
What a Google-style loop usually includes
Google has written publicly about using structured interviews: every candidate for a role is asked questions of the same kind and judged against the same criteria. For software engineers, the loop typically opens with a recruiter conversation and one or two technical screens, then a set of interviews, most of them about coding and problem solving. Candidates for senior roles usually also get a system design round.
Google has said publicly that it looks at general cognitive ability (how you reason through a problem you have not seen), role-related knowledge, leadership, and what it calls Googleyness: comfort with ambiguity, a bias to action and working well with others. In practice, that means the coding rounds care about how you think as much as whether the code runs, and almost every round has a moment where the interviewer changes the problem to see how you adapt.
The format changes over time and differs by role and country, so treat this as a description of the shape, not a promise. Your recruiter is the only source for your exact loop.
How it is scored
After the 60-minute round, the interviewer marks each line below 1 to 5 in your written report, due within 24 hours, with notes on what you said and wrote behind each mark. The verdict is one of Strong hire, Hire, Lean hire, Lean no hire or No hire.
| Skill (1 to 5) | What the interviewer looks for |
|---|---|
| Problem solving | You clarify an open problem, try small examples, and reach a working approach without heavy hints, then improve it when pushed. |
| Code quality | Readable code in a plain editor: clear names, small helper functions and no dead ends left in. |
| Testing and edge cases | You test without being asked: empty input, duplicates, limits, and the change the interviewer just introduced. |
| Complexity | You state time and space cost correctly and know which part of the solution sets it. |
| Communication | You think out loud, take a hint without losing the thread, and keep the interviewer with you through the twist. |
| Skill (1 to 5) | What the interviewer looks for |
|---|---|
| Requirements and estimates | You narrow a broad product into a few must-have features and size it before drawing. |
| High-level design | A clean request path with a reason for each component, at the scale the numbers call for. |
| Data and storage | A data model that fits the reads and writes, and a clear plan for partitioning as it grows. |
| Scale and trade-offs | You name the hard part early, weigh two options, and say what each costs in latency, consistency and money. |
| Communication | You lead the conversation, check assumptions with the interviewer and finish a complete design in time. |
| Skill (1 to 5) | What the interviewer looks for |
|---|---|
| Structure | Short answers with a clear situation, what you did, and the result; no ten-minute preamble. |
| Ownership | You acted when the path was unclear and say what you personally decided. |
| Collaboration | You describe working through disagreement and helping others, not winning arguments. |
| Impact | You can say what changed because of your work, in plain terms. |
| Self-awareness | You talk honestly about a mistake and what you do differently now. |
Practice questions in a Google style
Written by us in the style of these rounds, not taken from any real interview. In a mock, the interviewer picks one at your level and changes it as you go.
- Given a list of meeting times, find the smallest number of rooms needed, then return which meeting goes in which room.Sorting plus a heap, and whether you adapt cleanly when the output changes from a count to an assignment.
- A grid holds land and water. Count the islands, then count them again when cells flip to land one at a time.A first answer with search, then a better one with union-find for the streaming version.
- Design a function that returns a random element from a set in constant time, with add and remove also in constant time.Pairing a hash map with an array and handling removal without leaving gaps.
- Given a dictionary of words, find the longest chain where each word adds one letter to the previous one.Sorting by length and dynamic programming over words, with a clear explanation of the cost.
- Design a service that shows the most-searched terms in the last hour, updated every minute.Approximate counting, time windows, and where to aggregate so the read path stays cheap.
- Tell me about a time the requirements for your work were unclear. What did you do first?Comfort with ambiguity: how you found out what mattered and moved forward without waiting.
- Describe a time you changed your mind after a teammate disagreed with you.Listening, weighing the argument on its merits and what happened next.
How to rehearse it with a Revvox package
Most people preparing for a Google-style loop take the Standard package: three 60-minute rounds that mirror the loop. A common order is two problem-solving rounds first, then a system design or behavioural round, depending on your level. You pick the order when you book, and you get a report after every round, so the second round can work on what the first one found.
- Round one: coding. A medium problem with a twist part-way through. The interviewer watches how you clarify, choose an approach and test.
- Round two: coding, harder. A problem where the obvious solution is too slow. You are scored on finding a better one and explaining why it is better.
- Round three: design or behavioural. System design if you are aiming for a senior role; otherwise a conversation about projects, conflict and ambiguity.
How to prepare
- Write code in a plain editor without autocomplete. Many Google-style screens use a shared document rather than an IDE.
- Say your approach before you type, and state its time and space cost. Interviewers often stop you to ask about it anyway.
- Practise the follow-up. After a working solution, ask yourself what changes if the input does not fit in memory, arrives as a stream, or holds duplicates.
- Prepare four or five short stories from your work: a time you were unsure what to build, a disagreement, a mistake, and something you led without being asked.
- For senior roles, practise designing a system end to end in 45 minutes, starting from requirements and numbers.
Common mistakes in Google-style rounds
- Jumping to code before agreeing the problem. Ambiguity is often deliberate.
- Stopping at the first working answer when the interviewer is waiting for a better one.
- Testing only the happy path. Walk through an empty input, a single element and a large case out loud.
- Treating the behavioural questions as small talk. They are scored like any other round.