Why Communication Skills Matter More Than Students Think

CLEAR ANSWER — FIRST 90 SECONDS:

Interviewer: "How did you find each
customer's most recent order?"

Candidate: "Let me explain it in plain
words first, then the SQL.

The problem: for each customer, I needed
their most recent order — one row per
customer, not every order.

The approach in plain words: I lined up
each customer's orders by date, newest
first, and kept the top one. That gives one
row per customer with their latest order.

The SQL: a window function — ROW_NUMBER()
over a partition by customer, ordered by
date descending — and then I filter to
row 1. It's the standard way to do 'top N
per group' without a self-join.

The trade-off: a window function is cleaner
and usually faster than a correlated
subquery, but it scans the whole table once.
For our 2M orders, it takes about 1.2
seconds — I measured it against the
subquery version, which took 8 seconds.

The caveat: if a customer had two orders on
the same day, the window function picks one
arbitrarily unless I add a tiebreaker. I
added order_id as the second sort key, so
the pick is deterministic.

Since you're on the business side — the
outcome was that the sales team could see
each customer's latest order on the
dashboard, which they couldn't before."

What the interviewer thinks in 90 seconds:
- "Plain words first, jargon second." ✅
- "The structure is clear: problem, approach,
  trade-off, caveat." ✅
- "The trade-off is measured: 1.2s vs 8s." ✅
- "The tiebreaker is a real edge case." ✅
- "They adapted to my audience." ✅

Signal: clear. The answer lands.

JARGON ANSWER — FIRST 90 SECONDS:

Interviewer: "How did you find each
customer's most recent order?"

Candidate: "I used a ROW_NUMBER() window
function partitioned by customer_id ordered
by order_date desc, then filtered to rn = 1.
Alternatively you could use a correlated
subquery with a max(order_date) or a
DISTINCT ON in Postgres. I went with the
window function because it's more performant
in most cases."

What the interviewer thinks in 90 seconds:
- "That's a code translation, not an
  explanation." ❌
- "No business context — why does this
  matter?" ❌
- "No trade-off numbers — 'more performant'
  than what?" ❌
- "No edge case — what about same-day
  orders?" ❌
- "They didn't adapt to me." ❌

What happens next:
- The interviewer asks "What did the sales
  team do differently?"
- The candidate says "They could see the
  data."
- The interviewer asks "How much faster was
  the window function?"
- The candidate says "I don't remember the
  exact number."

Signal: confused. The answer is technically
correct and communicatively poor.

Why it failed:
❌ Jargon before plain words
❌ No business context
❌ No trade-off numbers
❌ No edge case
❌ No audience adaptation
❌ The answer proves knowledge, not
  judgment

STRUCTURE ANSWER — WHAT DECIDES:

Interviewer: "Walk me through a project."

WHAT THE CANDIDATE SAYS:
"Three parts: the problem, the approach, and
the outcome. I'll spend most of the time on
the trade-off, because that's where the
judgment is.

Part one, the problem: the sales team
reviewed monthly, using a report that took 6
hours. By the time they saw the number, the
month was over.

Part two, the approach: I rebuilt the
pipeline — a star schema, incremental loads,
and a cache — so the report runs in 20
minutes. The trade-off was 2 days of ETL work
and a fanout bug I caught with a
reconciliation check.

Part three, the outcome: the team moved from
monthly to weekly reviews and caught two
slipping regions before quarter close.

The trade-off I'd revisit: the star schema
is heavier to maintain than raw queries. I'd
revisit it if the team grows to 8 analysts,
because the ETL overhead starts to matter.

Should I go deeper on the pipeline, or is
that enough detail?"

What the interviewer thinks:
- "I knew the structure from sentence
  one." ✅
- "They spent time where the judgment
  is." ✅
- "The trade-off is named." ✅
- "They asked me what I need." ✅
- "This is a professional answer." ✅

Signal: confirmed communication.

Why it decides:
✅ Structure is announced
✅ Time is spent on judgment
✅ Trade-off is named
✅ A question back is asked
✅ The interviewer controls the depth

AUDIENCE ANSWER — WHAT DECIDES:

Interviewer: "Explain the pipeline to a
finance lead."

WHAT THE CANDIDATE SAYS:
"Sure. Let me put it in finance terms.

Think of the pipeline as a pre-check before
the report goes to your team. It asks two
questions for every row: does the total
match the ledger, and does the date fall in
the right month?

If both answers are yes, the row goes into
the report. If not, it goes into an
exceptions file that your team reviews — with
the reason in plain English, like 'total
mismatch' or 'missing date.'

The 2% tolerance is the same tolerance in
your policy, so nothing changes for you —
you just see fewer manual checks. The one
new thing: if the source file is malformed,
the pipeline stops and tells you which column
is wrong, instead of half-loading it.

The trade-off: if the source is late, the
report waits rather than showing yesterday's
number. You'll get an alert in the finance
channel.

Should I show you the exceptions file, or
explain the reconciliation check first?"

What the interviewer thinks:
- "They translated to finance terms." ✅
- "They tied it to the existing policy." ✅
- "They named what changes for finance." ✅
- "The trade-off is in the listener's
  terms." ✅
- "They asked what I want next." ✅

Signal: confirmed communication.

Why it decides:
✅ Business language, not code language
✅ Tied to the listener's policy
✅ Named what changes for the listener
✅ Trade-off in the listener's terms
✅ A question back

DEBUGGING STORY — CLEAR VS. CONFUSING:

Scenario: "Tell me about a bug you fixed."

CONFUSING SIGNAL:
"The report was wrong. I checked the join
and it had a fanout. I fixed the join and the
number was right."
What the interviewer thinks:
- "What was the report?"
- "What's a fanout, in this context?"
- "What was the business impact?"
- Signal: confusing. The answer is correct
  and unusable.

CLEAR SIGNAL:
"The monthly revenue report was 8% too high.
Finance caught it before I did — which is the
part I'm least proud of.

The cause, in plain words: the report counted
some refunds twice. When a customer got a
partial refund, the order appeared twice in
the report — once for the order, once for the
refund.

How I found it: I compared the report total
to the finance total and saw the 8% gap. Then
I counted rows — 13,100 in the report versus
12,400 in the table — and the 700-row gap was
exactly the number of partial refunds.

The fix: I combined the order and the refund
into one row per order, then summed. The two
months corrected to the finance number.

The prevention: I added a daily check that
compares the report total to finance — if
they diverge more than 0.5%, it alerts. It's
caught two smaller issues since.

The lesson: I now test every join for
duplicate keys before I trust it. A 30-second
check would have caught this.

Should I show you the check, or explain the
root cause in more detail?"

What the interviewer thinks:
- "Plain words: counted refunds twice." ✅
- "The method is specific: compared totals,
  counted rows." ✅
- "The fix is clear." ✅
- "The prevention is a check." ✅
- "They asked what I need." ✅
- Signal: confirmed communication.

Why it decides:
✅ Plain words for the cause
✅ The method is specific
✅ The fix is clear
✅ The prevention is a check
✅ A question back

INTERVIEW FOLLOW-UP — CLEAR VS. CONFUSING:

Scenario: "You said you used a cache. What
does that mean for the stakeholder?"

CONFUSING SIGNAL:
"The cache reduces the latency by storing
hot data in Redis, so the query doesn't hit
Postgres every time."
What the interviewer thinks:
- "That's an explanation for an engineer,
  not a stakeholder."
- "No business impact."
- Signal: confusing for the audience.

CLEAR SIGNAL:
"For the stakeholder, the cache means the
dashboard opens in about 2 seconds instead
of 40.

Here's the plain-words version: the data the
dashboard needs is stored in a fast,
in-memory copy, so it doesn't have to ask
the database every time. The copy refreshes
every 5 minutes.

The trade-off, in the stakeholder's terms:
the number they see can be up to 5 minutes
old. For a dashboard used in a weekly review,
that's fine. For a real-time alert, it
wouldn't be — and I'd build that differently.

The cost: the cache adds about $80 a month
in infrastructure. I chose it because the 40
seconds it saves is the difference between a
dashboard people use and a dashboard people
abandon.

Should I explain the refresh, or the cost
breakdown?"

What the interviewer thinks:
- "Translated to the stakeholder's terms." ✅
- "Named what changes: 2s instead of 40s." ✅
- "The trade-off is in business terms." ✅
- "The cost is named: $80." ✅
- "They asked what I want next." ✅
- Signal: confirmed communication.

Why it decides:
✅ Translation to business terms
✅ A specific before/after
✅ Trade-off in business terms
✅ Cost is named
✅ A question back

Communication Checklist:

FIRST 90 SECONDS:
☐ Plain words before jargon
☐ Structure announced: problem, approach,
  outcome
☐ Audience awareness: terms the listener
  knows
☐ No sentence starts with "basically" or
  "obviously"

WHAT DECIDES:
☐ The structure is followed
☐ Jargon is translated, not avoided
☐ A trade-off in the listener's terms
☐ A specific impact: 2s instead of 40s
☐ A cost: $80 a month, 2 days of ETL

WHAT CONFIRMS:
☐ A question back: "Should I go deeper?"
☐ The listener can repeat the answer in
  one sentence
☐ The answer survives a follow-up
☐ The candidate adapts when the audience
  changes
☐ The listener doesn't have to ask "what
  do you mean?"

RED FLAGS:
❌ Jargon first, no translation
❌ No structure — a stream of details
❌ No audience awareness
❌ "Basically" and "obviously" as filler
❌ A trade-off in engineering terms only
❌ No question back
❌ The listener has to ask "what do you
  mean?"

Why this works:
- The first 90 seconds set the signal
- The rest of the answer confirms or
  overturns it
- Plain words, structure, and audience
  awareness are the three things that make
  a correct answer land

30-DAY PRACTICE PLAN (FOR STUDENTS):

Week 1 — Plain words
☐ Pick 5 technical concepts you know
☐ Explain each in one sentence, no jargon
☐ Record yourself; listen for jargon
☐ Rewrite until a non-technical friend
  understands
☐ Cut every "basically" and "obviously"

Week 2 — Structure
☐ Pick 3 projects
☐ For each, write: problem, approach,
  trade-off, outcome
☐ Announce the structure in the first
  sentence
☐ Record yourself; check you follow the
  structure
☐ Compare with the un-structured version

Week 3 — Audience
☐ Explain the same project to 3 audiences:
  an engineer, a manager, a finance lead
☐ For each, change the terms and the
  trade-off
☐ Record all three
☐ Listen for which version sounds like a
  professional

Week 4 — Mock interviews
☐ Run 2 mock interviews with a peer
☐ Ask them to repeat your answer in one
  sentence
☐ If they can't, the answer was confusing
☐ Rewrite and re-record

Signs it's working:
✅ Plain words before jargon
✅ The structure is announced
✅ The listener can repeat the answer
✅ You adapt when the audience changes
✅ You ask "should I go deeper?"
✅ The interviewer asks "what else?"
  instead of "what do you mean?"