DEV Community: subbu uppalapati

The 8-Week Technical Interview Prep System That Actually Works (for Busy Engineers)

subbu uppalapati — Tue, 05 May 2026 19:24:46 +0000

Most technical interview prep fails for one reason: people optimize for volume, not system.

You can solve 200 problems and still underperform in interviews if you don’t train timing, communication, and feedback loops.

This is the 8-week framework I use for engineers who are preparing while working full-time.

Who this is for
Software engineers with limited prep time (60–90 mins on weekdays)
Candidates targeting backend/full-stack/senior roles
Anyone who wants structure instead of random grinding
Why typical prep breaks down
Common patterns:

Doing random problems with no sequencing
Ignoring system design until too late
Practicing coding, but not explaining decisions clearly
Treating behavioral prep as last-minute “story writing”
Interview success is multi-dimensional. You need:

Problem-solving accuracy
Time management
Communication quality
System design tradeoff clarity
Behavioral story depth
The 8-week framework
Weeks 1–2: Baseline + gap map
Goal: establish where you are and what to prioritize.

Take 2 timed coding mocks
Do 1 system design mock (record yourself if possible)
List your top 10 behavioral stories (conflict, impact, ownership, failure, leadership)
Build a gap map:
Coding: patterns you miss repeatedly
Design: weak areas (estimation, APIs, tradeoffs, scale)
Behavioral: unclear or low-signal stories
Output: your prep backlog, ranked by expected interview impact.

Weeks 3–5: Core build
Goal: build consistency and pattern fluency.

Weekly structure:

3 coding sessions (timed + postmortem)
1 system design session (whiteboard/doc + tradeoff discussion)
1 behavioral session (story rehearsal with STAR clarity)
1 review block (fix repeated mistakes)
Coding focus:

Don’t just solve — explain choices out loud
Track failure reasons (not just wrong/right)
Re-solve misses after 72 hours
System design focus:

Start from requirements and constraints
Practice explaining why you chose architecture X over Y
Explicitly cover bottlenecks, failure modes, and scaling path
Behavioral focus:

One story should map to multiple question variants
Add concrete metrics and decision points
Keep answers crisp and structured
Weeks 6–7: Simulation phase
Goal: convert preparation into interview performance.

Run 2–3 full mock loops (coding + design + behavioral)
Use real timing and no interruptions
Score each round with a rubric
Patch the top 3 recurring weaknesses only
At this stage, avoid collecting new resources. Execution > novelty.

Week 8: Final polish
Goal: consistency under pressure.

Company-specific prep (question style, role expectations, domain)
Light reps, not burnout
Sleep and recovery discipline
Day-before checklist:
communication warm-up
key design templates
behavioral story anchors
logistics sanity check
Weekly schedule (for full-time engineers)
A realistic template:

Mon: Coding (75 min)
Tue: System design (75 min)
Wed: Coding (75 min)
Thu: Behavioral + communication (60 min)
Fri: Coding timed mock (75 min)
Sat: Mock interview + review (2–3 hrs)
Sun: Rest or light review (45 min)
Consistency beats intensity.

Readiness scorecard (simple but effective)
Track weekly (1–5 scale):

Coding accuracy under time
Ability to explain approach before coding
System design structure and tradeoff depth
Behavioral story clarity and specificity
Recovery speed after mistakes
If a metric is flat for 2+ weeks, change method — not effort.

Common failure modes (and fixes)
“I practice a lot but still freeze in interviews.”
-> Add verbal walkthrough practice and timed mocks.

“I’m good at coding but weak in design rounds.”
-> Do weekly architecture drills with explicit tradeoff narration.

“Behavioral feels vague and repetitive.”
-> Build a story bank with measurable outcomes and decision tension.

“I’m burning out.”
-> Reduce volume, keep cadence, protect sleep.

Final thought
Interview prep is not a motivation problem.
It’s a systems problem.

If you run a structured 8-week loop with clear feedback, your confidence and outcomes improve dramatically.

If helpful, I can share a free one-page version of this framework with a weekly checklist.

What Amazon, Google, and Meta actually test in coding interviews (with specific problems)

subbu uppalapati — Tue, 14 Apr 2026 13:57:09 +0000

Meta: Two stages, two completely different problems
Google: The problem that reveals who actually prepares
Amazon: The company where coding is table stakes
The pattern across all three
What to prioritize per company

Background

Most interview prep advice is generic. "Know your trees." "Practice dynamic programming." "Be comfortable with graphs." It's not wrong — it's just not enough.

After building company-specific interview prep paths from confirmed candidate reports going back to 2022, here's what the data actually shows about how Amazon, Google, and Meta interview — and specifically where most candidates go wrong.

Meta: Two stages, two completely different problems

Meta's process has a phone screen and an on-site. The problems that dominate each stage are different, and conflating them is a common prep mistake.

Phone screen staples:

LC 680 — Valid Palindrome II (near-certainty)
LC 408 — Valid Word Abbreviation (common warm-up, finish under 10 min)
LC 88 — Merge Sorted Array (expects O(1) space reverse-merge immediately)
LC 3 — Longest Substring Without Repeating Characters

The phone screen pattern: sliding window and two-pointer problems where you're expected to jump to the O(n) solution within 3 minutes of reading the problem. Spending more than 2 minutes on brute force is a signal Meta interviewers watch for explicitly.

On-site: the #1 most-reported Meta problem

LC 1249 — Minimum Remove to Make Valid Parentheses. Appears in 95%+ of reported Meta on-sites.

The trap is pushing characters instead of indices:

def minRemoveToMakeValid(self, s: str) -> str:
    stack = []       # stores indices of unmatched '('
    to_remove = set()

    for i, c in enumerate(s):
        if c == '(':
            stack.append(i)
        elif c == ')':
            if stack:
                stack.pop()          # matched pair
            else:
                to_remove.add(i)     # unmatched ')'

    to_remove |= set(stack)          # remaining stack = unmatched '('
    return ''.join(c for i, c in enumerate(s) if i not in to_remove)

The junior vs senior answer at Meta:

A junior pushes characters and tries to rebuild the string on the fly.

A senior says: "I push the index of every open paren. On a close paren, if the stack is non-empty I pop — matched. If empty, I mark that close paren's index for removal. After the pass, everything still on the stack is an unmatched open paren — mark those too. One reconstruction pass."

The follow-up Meta always asks: "What if you need to handle square brackets too?" Answer: extend the stack to track pairs — push both the index and the bracket type.

The Jedi round (behavioral) is one round, culture-fit-heavy. Pick disagreements with real technical dimension — architecture, reliability, API design. Technical depth in behavioral answers impresses Meta interviewers even in that round.

Google: The problem that reveals who actually prepares

Google's reputation for broad scope is real — arrays, binary search, trees, graphs, DP, heaps, backtracking, data-structure design, and Google-specific problem types. But there is one problem that shows up as a diagnostic filter more than any other:

LC 238 — Product of Array Except Self

Google asks this specifically because division is prohibited. The question is whether you'll independently derive the prefix/suffix product trick or whether you'll ask "can I use division?" and get stuck.

def productExceptSelf(nums):
    n = len(nums)
    output = [1] * n

    prefix = 1
    for i in range(n):
        output[i] = prefix
        prefix *= nums[i]

    suffix = 1
    for i in range(n - 1, -1, -1):
        output[i] *= suffix
        suffix *= nums[i]

    return output

The junior vs senior answer at Google:

A junior asks "Can I use division?" and gets stuck when told no.

A senior says: "Division is forbidden and breaks on zeros anyway. Two passes — left prefix products into the output array, then multiply in a right suffix product in-place with a single variable. O(n) time, O(1) extra space, zeros propagate naturally with no special cases."

The complexity proof standard

Google cares more about this than Meta or Amazon. Saying "O(n log n)" is weaker than:

"The sort dominates at O(n log n). The merge pass is a single O(n) scan. Total: O(n log n) time, O(n) output space."

Handwaving complexity is a yellow flag at Google even when the solution is correct.

Top K Frequent Elements (LC 347) is another Google-specific diagnostic. They want both the heap solution (O(n log k)) and the bucket sort solution (O(n)) — and an explanation of why bucket sort is valid here (frequencies are bounded by n, which makes the index trick possible). The transition between the two is where they assess depth.

Googleyness is a structured rubric in the final behavioral round — intellectual curiosity, collaborative problem-solving style, comfort with ambiguity. It's a full interview section, not an afterthought.

Amazon: The company where coding is table stakes

Amazon's loop includes a bar-raiser round dedicated entirely to Leadership Principles. But more importantly: every interviewer in the loop asks LP questions, not just the bar-raiser.

There are 16 LPs. The most tested at senior levels:

Deliver Results — "How did you measure success? What were the metrics?" Have your numbers ready: latency reduction, defect rate, revenue impact, customer satisfaction score.
Have Backbone; Disagree and Commit — The drill-down: "Did you fight for your position? Then what happened? Did you fully commit after the decision was made?"
Customer Obsession — "Tell me about a time when doing right by the customer conflicted with a technical constraint." They want the tension, not the easy version of the story.

The rule: have 2+ STAR stories per LP. Amazon interviewers are trained to ask for a second example if the first is weak.

For coding, Amazon patterns skew toward well-known mediums where clarity and communication matter as much as optimization.

LC 128 — Longest Consecutive Sequence

The O(n) HashSet approach is required. The key insight: only numbers with no left neighbor (num - 1 not in the set) should trigger a count — otherwise you recount the same sequence multiple times and degrade to O(n²).

def longestConsecutive(nums):
    num_set = set(nums)
    longest = 0

    for num in num_set:
        if num - 1 not in num_set:    # only start from sequence beginning
            length = 1
            while num + length in num_set:
                length += 1
            longest = max(longest, length)

    return longest

Amazon interviewers specifically appreciate when you articulate why the O(n log n) sort approach misses the stated O(n) constraint — it signals you read requirements carefully.

LC 139 — Word Break

The insight worth knowing: Word Break is structurally identical to Coin Change. Both are "try each option from each position" tabulation problems. If you understand the Coin Change recurrence, Word Break follows immediately — same DP shape, different domain.

The pattern across all three

Pattern	Amazon	Google	Meta
Hash map / complement lookup	✓	✓	✓
Prefix sums	✓	✓	✓
Sliding window	—	✓	✓✓
Stack with index tracking	—	✓	✓✓
Trees (BFS / DFS / LCA)	✓	✓	✓✓
Graphs	✓	✓✓	✓
DP (1D tabulation)	✓✓	✓✓	—
System design	✓✓	✓✓	✓✓

If you're doing multi-company prep, master hash maps, prefix sums, sliding window, stack with index tracking, and BFS/DFS on trees first. That's the overlap that pays off across all three.

What to prioritize per company

Meta: Narrow to the 30–40 problems that appear most in confirmed reports. Get the sliding window template automatic before your phone screen. Know Valid Parentheses → Minimum Remove → Basic Calculator I → II → III as a progression — each builds directly on the last.

Google: Go wide but practice explaining your reasoning out loud the entire time. Google's diagnostic isn't whether you solved it — it's how you reason through it. Prove complexity claims step by step, not just state them.

Amazon: LP prep deserves as much time as coding prep. Build 8–10 strong career stories. Map each story to multiple LPs it could cover. Know your metrics cold — every LP story needs a quantified result.

I've been building these prep paths at streamprep.dev — company-specific tracks built from confirmed interview reports, each problem with a guided discovery flow and the "what the interviewer is actually testing" framing shown above. Free during beta.

Explore company-specific interview paths on StreamPrep (Free during beta)

Curious what patterns people are seeing that aren't covered here — drop a comment.