From tasks to outcomes

A task and an outcome are not the same sentence

Diego, a pleno developer at a Brazilian e-commerce company, got a screening call for a remote role at a US company. He was asked to describe a project he was proud of. His first draft, said out loud, was "I moved the checkout confirmation email out of the request cycle and into a background job." True, and forgettable. The interviewer followed up with "okay, what did that change?" Diego's second attempt landed better: "The checkout request used to average around two seconds, from our own logs. It came down to under 300 milliseconds once the email stopped blocking it, and the support tickets from customers stuck on a spinning checkout screen mostly stopped." Same project, same pull request, but only the second sentence is the one an interviewer remembers an hour later. A task tells someone what you did. An outcome tells them what changed because you did it, and mid-level rounds are graded almost entirely on the second kind of sentence.

Four signals interviewers grade at this level

Underneath every pleno-level behavioral question, an interviewer is listening for four things, whether or not they say so out loud. Scope: how big was the thing you owned end to end, versus the piece you stood next to while someone else carried it. Influence: did you move a decision for someone who didn't report to you and wasn't required to listen to you: a teammate, another team, a stakeholder. Conflict: what do you do when someone more senior disagrees with you and you turn out to be right, or wrong. Ownership: can you describe being wrong, or a project that partly failed, without quietly smuggling in an excuse that moves the responsibility somewhere else. A junior round mostly checks whether you can work inside a team. A pleno round checks whether the team can hand you a real slice of the system and trust what comes back. Each of these four signals is a different angle on that same question. Diego's checkout story answers scope and ownership at once: he owned the migration from the first line of code to the on-call rotation covering it after launch. His disagreement with a teammate over a service object, which lesson 3 builds out in full, answers conflict. And a story about onboarding a junior teammate, covered in lesson 4, answers influence in a quieter form: moving someone's habits and confidence, not a single decision.

Prepare two stories per theme, not one

A common failure in a pleno round has nothing to do with the stories themselves: it's running out of them. An interviewer who likes your ownership story will often say "great, now tell me another one," testing whether that story was your only real example or one of several. Walking in with one strong story per theme means the second question exposes you; walking in with two means it doesn't. This doesn't require twice the preparation. Most developers already have more raw material than they think, once they know to look for a second angle on the same few projects. The checkout migration is an ownership story and a scope story at once, told slightly differently depending on which word the question uses. Before a real round, it's worth writing down three or four projects you'd reach for. Then label each one with every theme it could answer (scope, influence, conflict, ownership) instead of assuming each project belongs to one bucket. Most pleno-level candidates find they already have the two stories per theme; they've just never sorted their own material that way before.

What's different from the junior round

If you took the junior-level "Behavioral interviews for juniors," you've already built real team stories (a disagreement, code review, a mistake owned honestly) and this course doesn't rebuild that foundation. It assumes you can already tell a clean STAR story, the format introduced in the intern-level course "Telling your story: behavioral basics." It doesn't re-teach blameless postmortems or code review culture either, since the junior course covers both in depth. What's new at this level is the size and shape of the story itself: a junior story usually centers on a single ticket or a single interaction. A pleno story usually centers on something you owned across weeks, something you changed someone else's mind about, or something you were responsible for when it broke. The mechanics carry over. The material you reach for changes.

Concretely, a junior candidate might describe fixing a specific N+1 query once someone flagged it. A pleno candidate is expected to describe deciding, on their own initiative, that a whole area of the codebase needed attention. They made the case for the time to do it, and they were the one accountable if the fix introduced a regression. The story format doesn't change. The weight riding on it does.

The Brazil layer, and the global remote round in English

At a Brazilian company, a pleno round tends to ask directly about ownership over results and mentoring less experienced colleagues. "How have you contributed to a junior's technical growth?" is a normal, expected question. A remote round for a US or European company raises the bar differently. The same four signals get graded, but live, in English, with no chance to reread the question or rehearse the phrasing beforehand. Diego's stories don't change between the two rounds: the checkout migration and the disagreement over a service object are the same events either way. The English version takes real rehearsal out loud, beyond reading the story silently. The gap between writing a good sentence and saying one live under pressure is real, and worth closing before the call rather than during it. It's worth naming the reverse honestly too. A candidate who has only told a story in Portuguese sometimes finds that a phrase doesn't translate cleanly when said in English for the first time. Discovering that in rehearsal costs nothing. Discovering it mid-answer on a real call costs the story its momentum.

Where this course goes

Lesson 2 turns a plain task description into an outcome sentence, and covers where a mid-level developer finds real numbers to back one up. Lesson 3 builds a conflict story that doesn't need a villain: two reasonable people optimizing for different things, and how the disagreement got resolved. Lesson 4 covers mentoring and onboarding someone less experienced, even without a title that says "mentor." Lesson 5, "Ownership when things break," covers owning a production incident at pleno depth. Lesson 6, "Disagreeing with your lead," covers the harder version of lesson 3's conflict story: one where the other side outranks you. Lesson 7, "Impact stories: putting it all together," runs a full round that moves between all of it.