How to ask a senior colleague for help in a way that gets you a fast, useful answer instead of a frustrated one — what to include, what to try first, and why 'it doesn't work' is the least useful sentence in tech.
Early in any technical role, there's a real fear that asking for help signals incompetence. In practice, the opposite is usually true: how you ask for help is one of the clearest, fastest signals of how you think — and a well-formed question often gets a faster, more generous answer than a vague one, precisely because it respects the other person's time.
"It doesn't work" is the least useful sentence in tech. It tells the other person nothing about what you tried, what you expected, or what actually happened instead. Replace it, every time, with three specific things: what you were trying to do, what you expected to happen, and what actually happened (the exact error message, screenshot, or output — not a paraphrase).
Show what you already tried. Before asking, spend a genuine, bounded amount of time (not an unbounded one) trying to solve it yourself — checking the obvious things, searching for the exact error message, re-reading the relevant guide. When you do ask, say what you already tried and ruled out. This does two things: it often solves the problem before you even need to ask, and when you do ask, it lets the other person skip straight past the things you've already eliminated.
Include the exact error, not a summary of it. "It gave me some kind of permission error" is far less useful than pasting the actual error text. Exact error messages are often searchable, specific, and immediately recognizable to someone who's seen that exact failure before — a paraphrase strips out the one detail most likely to be the actual clue.
State what you expected, not just what happened. Two people can look at identical output and disagree about whether it's actually wrong, unless you say clearly what you expected instead. This single sentence often resolves a surprising number of "is this even a bug" questions on its own.
Ask the right person, for the right reason. A quick clarifying question to a teammate is different from a genuinely unresolved technical blocker that needs a senior engineer's time. Match the size of the ask to the size of the interruption you're causing — and it's fine to say explicitly, "this is a quick one" or "this might take a bit of your time," so the other person can calibrate.
Next time you're stuck, write your question down fully — problem, expectation, exact output, what you've already tried — before sending it, even if you end up solving it yourself while writing it out. That's not a wasted exercise; it's one of the most common ways a clearly-articulated question turns out to answer itself.
This same discipline — being specific, showing evidence, stating what you expected versus what happened — is exactly the habit that makes Root Cause Analysis effective, whether you're asking someone else for help or investigating a problem entirely on your own.
Part of: Freshers, Support Engineers, Incoming Students, First Year