🎯Behavioral / STAR Stories

Anchor this to the MCU-DSP interface bug from my MediaTek internship — it is my single best hardware/software-boundary debug story, so I keep it for the hardest-debug question and use other projects elsewhere.

Situation: During my internship I owned resolving critical firmware interaction bugs between the Main Control Unit and the DSP components. The symptom was intermittent: under specific sequencing the MCU and DSP would disagree about state, and downstream the modem behaved as if a message had been missed or applied late. From either side in isolation the code looked correct — the MCU thought it had handed off, the DSP thought it had nothing valid to act on.

Task: Get from it fails sometimes to a reproducible root cause without prematurely blaming MCU firmware, DSP firmware, or the shared interface.

Action: I treated it as an ownership problem, not a code problem. I added low-overhead trace markers at the exact handoff points on both sides — when the MCU published, when the DSP was signalled, when the DSP actually consumed — with a shared timestamp reference so I could line up two timelines instead of reading two separate logs. Then I built a reduced repro that replayed the failing sequence instead of waiting for it in a full run. The key insight was not adding more logging; it was placing a few markers exactly at the boundary so I could prove which side last had a correct view of the shared state.

That showed the payload was fine but the handshake had a window where the DSP could observe the interface before the MCU had fully finished publishing it — a classic publish-before-consume ordering hole across the MCU-DSP seam.

Result: We made the handshake ordering explicit and added a regression around that timing edge. The intermittent failure stopped reproducing in stress runs where it had previously shown up quickly, and the interface was measurably more reliable afterward.

Then I bridge honestly: the lesson — define ownership first, instrument the ownership *transitions*, then prove whether it's corruption, stale state, ordering, or timing — is exactly how I'd approach a driver/device contract: descriptor ownership bits, doorbells, completion visibility. I haven't debugged a NIC DMA ring in production, but this is the same class of bug and the same method.

Anchor this to triaging 100+ customer and internal support issues at MediaTek — that is genuinely cross-team work, so I use it here rather than reusing a single-bug story.

Situation: I've triaged well over 100 customer and internal support issues. These land as vague, high-pressure reports — a customer says the modem misbehaves in their integration — and the truth is spread across groups: customer engineering has the field symptom, the system team has platform context, RF/calibration owns part of the chain, and L1 TX/RX firmware owns the runtime behaviour. Each group can explain its own slice; nobody starts with the full picture.

Task: Make the investigation converge instead of turning into parallel theories, and decide what's actually a firmware bug versus an integration or configuration issue — without bouncing the ticket around.

Action: My habit is to anchor everyone on evidence early. I'd reproduce or narrow the case with core dumps, traces and KPI analysis, then state plainly what the data showed: this KPI degrades only at this configuration, this counter never moves in the failing case, this trace proves the firmware applied the right setting. With customer engineering I'd pin down a minimal repro and a clear pass/fail line; with system and senior engineers I'd take the contended cases into design review and get a decision rather than letting it stall. A large fraction turned out not to be firmware defects at all — they were configuration or integration mismatches, and the fast win was proving that cleanly so the customer got unblocked.

Result: Across 100+ issues I delivered fixes, integration guidance, and design-review decisions, and consistently shortened the path from a fuzzy report to a clear root cause and owner.

Bridge: a NIC team triaging field issues with silicon and customers works the same way — define the contract between driver and device, agree which observations are authoritative, and make the debug artifact useful to more than one team. The protocol domain differs but the cross-team triage instinct is exactly what I've been doing.

Anchor this to implementing 3GPP TS 38.214 / 38.213 PHY behaviour and arbitration algorithms in the TX DSP firmware — that's where timing and correctness are genuinely coupled for me.

Situation: A lot of my MediaTek work is turning 3GPP PHY requirements into C that has to complete inside a strict slot/subframe budget on a TX DSP module. Missing the budget isn't just slower — the next stage consumes stale or missing data, so a deadline miss becomes a correctness failure. I also implement arbitration algorithms on constrained RTOS execution paths, where the decision has to be both correct and bounded in time.

Task: On a section of that path, worst-case latency occasionally exceeded the budget under load. The goal wasn't a nicer average — it was reducing the tail and being able to *explain* the budget.

Action: I separated average throughput from deadline misses. I added cycle-level timing around the hot stages and looked at distributions, not just means, tagging runs by the modulation/coding path and input size so I could see which cases pushed the tail. Then I attacked the worst cases specifically: removed avoidable copies, made memory access more linear, cut branchy control out of the hot loop, and moved non-critical accounting out of the deadline path. Crucially, I gated every change on bit-exact output by running vector regressions before and after — in PHY firmware a faster-but-wrong result is useless.

Result: The real win was a tighter latency distribution and a path that reliably stayed inside the deadline, not a headline benchmark number. We could say which stage consumed the budget and why.

Bridge: a NIC datapath has the same discipline — you care about p99/p999, cache locality, ring/DMA ownership, and keeping slow-path work out of the packet fast path. I've been reasoning about deadlines-as-distributions for years; the objects change from subframes to packets.

Anchor this to a real moment in my UL-DAI / DL DCI feature work, where I own the feature from spec analysis through implementation and release.

Situation: On a feature in the UL-DAI / downlink DCI reporting area, I made a change that passed the functional tests I'd written and looked complete — but it was correct for the steady-state cases I'd focused on. I'd under-tested an edge in the reporting/sequencing behaviour, and it surfaced later under a less common integration scenario rather than in my own unit tests.

Task: Own it, fix it quickly, and make sure that class of issue couldn't slip through again — especially since I'm the feature owner, so the gap was mine.

Action: I reproduced it with the smallest case I could construct, then went back to my assumptions: which states I'd actually exercised versus assumed, and where the spec implied behaviour I'd treated as a corner. The honest root cause was that I'd validated the common path well and the rare state transitions thinly. I fixed the specific defect, but the durable change was expanding the Google Test coverage to hit those transitions explicitly and tightening what done meant for me before integration — derived from the spec, not from the happy path.

Result: The bug was fixed and the feature got a stronger regression around the edge cases, which mattered because it was a feature I'd carry through CI/CD and release support.

What I learned — and what I'd carry to driver work — is that in low-level systems the rare state transitions are often *the product*. For a NIC driver I'd be deliberately careful around descriptor exhaustion, queue stop/wake, completion ordering, and error recovery, because those are exactly where code that passes the obvious tests still fails.

Anchor this to a design-review disagreement during support triage, where I had to push back on whether a reported issue was actually a firmware defect.

Situation: On one escalated support issue, the initial consensus was that the fix belonged in our L1 firmware — a customer was seeing degraded behaviour and the quickest narrative was firmware bug, patch it. My read from the traces and KPIs was different: the firmware was applying the configuration correctly, and the symptom tracked an integration/configuration mismatch on the platform side. Patching firmware would have masked it, not fixed it, and risked side effects for other customers.

Task: Avoid both extremes — neither stubbornly defending not my code nor accepting a firmware change I believed was wrong — and get to the right fix without slowing the customer down.

Action: I made the disagreement a measurable question instead of an opinion. I laid out the evidence: which counters and traces proved the firmware path was correct, and what configuration difference correlated with the failure. I agreed up front what observation would change my mind — if a trace showed the firmware misapplying the setting, I'd own it. I brought that into the design review so the decision was made on shared evidence with senior engineers, not by whoever pushed hardest.

Result: The evidence showed it was a configuration/integration issue; we fixed it at the right layer and gave the customer integration guidance rather than shipping a firmware change that would have hidden the real cause. The principle I use: don't try to win the argument, expose the hidden state — counters, traces, ownership — and let that settle it.

Bridge: in a NIC context I'd apply the same thing to a driver bug vs. hardware/config dispute — prove with device counters and ring state where the truth is before changing code.

Anchor this to the 5G non-terrestrial-network (NTN) proof of concept I joined during my internship — connecting phones to satellites in coverage-limited environments.

Situation: NTN was new ground: satellite links bring long and varying propagation delays, Doppler, and timing behaviour that terrestrial 5G assumptions don't cover. I had a strong PHY/DSP foundation but had to get useful on the satellite-specific parts quickly, as an intern, without pretending I already understood them.

Task: Contribute to the PoC and build test-automation for firmware validation, while genuinely learning the NTN-specific timing and protocol behaviour.

Action: I learned through the system boundary rather than abstractly. I started from the contract — inputs, outputs, timing assumptions, what changes when the link delay is much larger — then traced one working case end to end and one edge case. To make that repeatable I built Python test-automation scripts that exercised firmware validation and cut the repetitive manual testing, which doubled as a forcing function to actually understand what correct looked like. Then I asked targeted questions *after* doing the homework: what timing reference holds under this delay, what's the expected behaviour at the edges.

Result: I became useful on the PoC quickly and left behind automation the team kept using, because I was mapping a new domain onto concrete invariants and tests rather than trying to absorb it in the abstract.

Bridge — and I say this plainly: that is exactly how I'd approach the Linux NIC-driver ramp. I'm not claiming I already know netdev. I'd trace a real driver end to end, build or use small repros, and map each new piece (NAPI, the DMA API, ring ownership) onto invariants I already reason about. The learning method is proven; the domain is what's new.

Anchor this to the internal developer tooling I built at MediaTek — Python/Flask, Electron, React.js, C# tools including LLM-assisted developer-productivity workflows.

Situation: Nobody assigned me to build tooling. But across my firmware and support work I kept seeing the same friction: repetitive developer workflows, debug and triage steps people redid by hand, and tribal knowledge that slowed everyone down. The recurring failures weren't all independent — a lot of them were the same missing visibility or the same manual step.

Task: My core deliverables were firmware features and support, but the friction was slowing the whole team, so I took ownership of making those workflows easier — on top of my assigned work, not instead of it.

Action: I built actively-used internal tools: Python/Flask and Electron/React front-ends, some C#, and LLM-assisted workflows that automated developer-productivity tasks. I focused on the high-frequency pain — turning a manual, error-prone step into something repeatable, and making debug/triage information consistent rather than reverse-engineered each time. The point wasn't to write a clever tool; it was to remove a step the team kept paying for.

Result: The tools got real adoption inside the team and improved both efficiency and tooling maintainability — durable leverage, not a one-off script. That's the part I care about: I didn't just close my own tickets, I removed friction from the system.

Bridge: in a NIC group I'd look for the same opportunities around driver diagnostics — ring-state dumps, DMA-mapping-failure visibility, queue state, reproducible packet-path tests — the kind of tooling that makes the whole team debug faster, not just me.

Anchor this to translating ambiguous 3GPP spec text (TS 38.214 / 38.213) into C — a real, recurring judgement situation in my work, distinct from my debugging stories.

Situation: A 3GPP spec is precise in intent but not written as an implementation. Owning UL-DAI and related DCI behaviour, I'd regularly hit clauses where the required behaviour at a corner case was genuinely ambiguous — the spec constrained the common case clearly but left an edge open to more than one reasonable reading, and the wrong reading would show up as an interop failure with a real network.

Task: Turn that into correct, release-quality C without the luxury of a definitive answer on day one — and without quietly guessing.

Action: I narrowed the ambiguity instead of picking arbitrarily. I cross-referenced the related clauses, since 38.213 and 38.214 constrain each other, and reasoned from intent: what is the procedure actually trying to guarantee, and which interpretation is consistent with the rest of the chain. Where it was still genuinely open, I made the assumption explicit in the design and in review rather than burying it in code, picked the interpretation that was safest for interop, and structured the implementation so that pinning down the behaviour later wouldn't mean rewriting it. I also took the contended readings into design review with senior engineers rather than deciding alone.

Result: I shipped correct, testable behaviour on a defensible interpretation, with the assumption documented so it could be revisited cheaply if a clarification or a customer case proved otherwise — and that traceability paid off during integration.

Bridge: low-level networking has the same shape — a spec or hardware doc that's ambiguous at the edges, where you reason from intent, make the assumption explicit, choose the interoperable reading, and keep it cheap to revise. That's exactly how I'd approach an under-specified corner of a protocol or a device contract.

I'd frame it as an adjacent-domain move, not a career reset. The common core of my four-plus years has been moving bits fast and correctly at the hardware/software seam under real-time constraints. Concretely: production RTOS modem firmware, TX DSP modules, turning 3GPP PHY requirements into C inside slot timing budgets, debugging across L1 TX/RX firmware, RF, power amplifier and calibration, and the MCU-DSP interface work. The domain objects in this role change to PCIe, DMA, descriptor rings, Ethernet/TCP-IP and Linux network drivers — but the engineering discipline is the same.

The risk is real and I won't pretend otherwise: I haven't shipped a production Linux netdev driver, and my protocol depth is wireless, not Ethernet/TCP-IP. I manage that by being explicit about the ramp. I can contribute from day one on C, hardware/software-boundary debugging, real-time and tail-latency thinking, datapath performance, and cross-team work with silicon and test. I'd deliberately ramp on the Linux-specific pieces — driver lifecycle, NAPI, the DMA API, SKB/XDP-style packet flow, PCIe probe/remove and error handling, and your own NIC architecture.

What attracts me here specifically is that it's exactly the seam I want to work at — low-level C, NIC datapaths, and AI-cluster networking, still close to silicon. With Pollara and UEC the networking is central to AI infrastructure, not a support function. So the honest answer: there's a domain gap, but it's a controlled gap on top of years of the same underlying engineering pattern.

I do my best work in teams that are evidence-led and close to the system. I like clear ownership but not siloed ownership. The best conversations in this kind of work are concrete: what did the hardware do, what did the driver or firmware publish, which counter moved, which invariant was violated, what's the smallest test that proves the fix. That's the register I've been working in on support triage and feature design at MediaTek.

As a senior engineer I try to contribute three ways. First, I make debugging systematic — define the boundary, instrument the ownership transitions, avoid guessing; that's what the MCU-DSP work taught me. Second, I protect the hot path — keep performance decisions measurable and slow-path complexity out of latency-sensitive code, the way I had to with DSP timing budgets. Third, I help teams communicate across specialties; I've worked across DSP, firmware, RF, calibration, test and customer engineering, and I'd bring that same style to a team spanning driver, firmware and silicon.

I also value direct feedback, especially while ramping on a new domain. If I'm coming up to speed on Linux netdev internals, I'd much rather get early correction on the team's conventions than quietly diverge. My goal is to become useful quickly while respecting the existing codebase and the hardware contract.