Back to all articles
Communication October 19, 2026 8 min read

How Interviewers Score Communication: What Public Rubrics Say

Interviewers score communication against a rubric agreed before the interview: whether you clarified the problem, explained your approach before coding, kept talking while you worked, and answered follow-ups clearly. Companies rarely publish their rubrics, but what they do publish agrees: Google, Meta, Amazon and OpenAI all describe how you reason aloud as part of what is assessed.

A bronze statue holding a pair of balance scales

What we can and cannot know

The exact rubrics used inside large tech companies are not public, and anything presented as "the Google rubric" or "Meta's scoring sheet" on a prep site should be treated with suspicion. This article uses only three kinds of source: what companies say on their own careers pages, rubrics that their authors have published openly, and Devana's own rubric, which we can describe exactly because we built it. Every quote below was checked on its source page on October 19, 2026; the links are at the end.

What the companies say publicly

Google: structured interviews and rubrics

Google's re:Work guide to structured interviewing is written for every role, not only engineering, but it describes the machinery. Interviews use planned questions and "standardized rubrics so that all reviewers have a shared understanding of what outstanding, solid, borderline, and poor response looks like", and "Google often documents with illustrative examples what a poor, borderline, solid, and outstanding answer would cover." Questions come with follow-ups "designed to understand the candidate's thought processes", and the guide adds that interviewers "may not be looking to assess a correct answer, but instead want to judge the analytical thought process used to explore, define, and offer a solution to the problem."

The implication for a candidate: your answer is compared with written examples of good and bad answers, and the reasoning you say aloud is the evidence the interviewer writes down.

Meta: think out loud, and explain your solution

Meta's preparation guide for software engineers (updated in 2022) is the most direct about coding rounds: "We pay a lot of attention to the way you solve problems, which can be as important as having the right answer. Thinking out loud gives the interviewer insight into your thinking process and can also help them follow along with your solution." It also says "Share your reasoning: Make sure you can talk about your solution because you will probably be asked to explain it", and "Find and fix the bugs by yourself. Don't wait for the interviewer to find them for you." For system design it adds "Be sure to ask clarifying questions" and that a good solution "makes intelligent, reasoned decisions about those tradeoffs."

Amazon: communicative, and the why behind decisions

Amazon's SDE II interview preparation page lists "Communicative" among the traits it looks for, defined as "Communicating effectively with team members, stakeholders, and customers." In system design, "you should ask questions to complete and validate your design." In the behavioral part, it says interviewers focus on "the 'what' and 'how' of your experiences, as well as the 'why' of your decisions", and asks for well-structured answers using the STAR method.

OpenAI: how you communicate your reasoning

OpenAI's interview guide says: "Our interviews are designed to help us understand how you approach problems, make decisions, and communicate your reasoning." For engineering interviews it lists well-designed solutions, high-quality code, optimal performance and good test coverage, and then: "We evaluate for strong communication and collaboration skills."

What a communication rubric looks like

Since the companies' own sheets are private, the most useful public example is a practice rubric. The Tech Interview Handbook publishes a "sample coding interview evaluation rubric, for practice", written by its author, a former Meta staff engineer. It is not any company's official rubric, and it does not claim to be. It rates four areas, communication, problem solving, technical competency and testing, on a four-step scale from strong hire to strong no hire. For communication, the signals it lists include "Asks appropriate clarifying questions" and "Constantly communicating, even while coding." The two ends of its scale read:

  • Strong hire: "communication was thorough, well-organized, succinct and clear in terms of thought process - including how they understand the question, their approach, trade-offs."
  • Strong no hire: "Could not communicate with any clarity or stayed silent even when addressed by the interviewer."

interviewing.io, where engineers practice technical interviews anonymously, has published an analysis of its own interview data in which interviewers give separate scores for technical ability, problem solving and communication, each out of 4.

Put together, the public material describes the same behaviors. Here they are side by side:

MomentReads as strongReads as weak
StartRestates the problem, asks the questions that change the answerStarts coding at once, or asks questions the prompt answered
ApproachNames an approach and its cost before coding, compares alternativesApproach only becomes visible in the code
CodingExplains each block and each change of mindLong silences, or reading syntax aloud
TestingTraces an example aloud, finds own bugsDeclares it done; waits for the interviewer to find bugs
Follow-upsShort, direct answers with a reasonRambling, defensive or off the question
Design choicesStates trade-offs and what each choice costsLists technologies with no reasons

How communication combines with the technical score

None of the companies above publishes how much communication weighs against getting the code right, and the public rubrics score each area separately rather than adding them up. What they make clear is that the areas are judged together: a correct solution reached in silence leaves the interviewer with little evidence of how you got there, and a clear explanation does not make a wrong solution right.

Devana's rubric is one concrete example, and since we wrote it, we can give the numbers. In a coding round, communication is 60% of each question's score and the code is 40%. The 100 communication points split into approach planning (30), thinking out loud (25), code defense, meaning how you answer questions about your code (20), logic explanation (15), silence handling (5) and verbal clarity (5). The grader is told that a candidate who never discussed an approach before coding cannot score more than 30 on communication for that question, and that asking clarifying questions alone earns only a small amount. In a system design round communication is 40%: requirements scoping (30), driving the discussion (25), trade-offs (25) and verbal clarity (20). In a behavioral round, delivery is 40%: verbal clarity, active listening, composure, pacing and structure, 20 points each. Every score in the report comes with what raised and lowered it.

Those weights are our choice, not an industry standard. They reflect the same thing the public sources say: the explanation is a large part of what is being assessed, not decoration on top of the code.

What moves a communication score, in practice

Things that raise it:

  • Restating the problem and asking two or three questions that change the solution.
  • Saying the brute force and its complexity, then a better approach, before typing.
  • Explaining each block of code as you finish it, and saying when you change your mind.
  • Testing out loud on an example, and finding your own bug before the interviewer does.
  • Answering follow-ups in a sentence or two, with a reason.
  • Naming trade-offs at the moment you make each design decision.

Things that lower it:

  • Starting to code without a stated plan.
  • Silences of more than a few seconds that you did not announce.
  • Long, unstructured answers that never reach a conclusion.
  • Defending a choice by repeating it, or abandoning it the moment it is questioned.
  • Answering a different question from the one asked.

How to use this

Treat the table as a checklist for practice, not a script for the interview. Each row has a page in this series: clarifying questions, thinking out loud in a coding interview, explaining trade-offs, what to say when you don't know, and how to practice all of it on your own.

To get scored against a written rubric, Devana's mock interviews grade every coding, system design and behavioral round on the metrics above, 3 interviews a month free. For problems to practice on, the worked problems by pattern each include a section on how to say the approach in the interview.

Sources

All read on October 19, 2026.

Frequently asked questions

Do companies publish their interview rubrics?

Rarely in full. Google has published how its structured interviews and rubrics work in its re:Work guide, and Meta, Amazon and OpenAI describe what they look for on their careers pages, but the scoring sheets themselves are internal.

Can good communication make up for not solving the problem?

Partly. Clear reasoning, a sound approach and good use of hints count in your favor even if the code is incomplete, but a clear explanation does not make a wrong solution right. The strongest result is a working solution you explained throughout.

Is communication scored separately from coding?

In the public rubrics, yes: communication, problem solving, technical skill and testing are rated as separate areas and then weighed together. On Devana's rubric, communication is 60% of a coding round's score, and 40% of system design and behavioral rounds.

Does an accent or non-native English lower a communication score?

None of the public rubrics in this article mention accent or fluency. They describe whether your reasoning is clear, organized and audible: whether the interviewer could follow what you were doing and why.