Let’s talk
← Back to experience
01 / Experience Currently

Fremont, California · Aug 2026 — present

Closer to
the hardware.

Understanding a system means knowing what happens when it doesn’t work.

Quanta Manufacturing Fremont

Test Technician

Working in the testing department with switches, compute trays, and the connections that keep them running.

  • Support rack-level testing and debugging across compute trays, switches, power, cabling, and system state.
  • Built Python/Excel tooling to organize test results, surface recurring failures, and automate daily reporting.
  • Created an OSFP-board replacement SOP and improved technical documentation to make repeat procedures easier to follow.
Hardware DebuggingSystemsPython AutomationDocumentation
Inside the debugging process

From rack to resolution.

Skip walkthrough ↓

Scroll through the debugging walkthrough.

GB300 / Engineering workflowIllustrative systems · Fabricated data
Production line / Observe
Operate / Observe

Which system needs attention?

Not every problem announces itself the same way.

CT-01 · PASS
CT-02 · TESTING
CT-03 · TEST FAIL
CT-04 · IDLE / CHECK STATE
CT-05 · TESTING
CT-06 · PASS
CT-07 · TESTING
CT-08 · PASS
FailureUnexpected stateIdle testRecurring error

Monitor the line. Identify what needs attention. Route the next investigation.

Operate / Triage

Read the evidence first.

Decisions depend on context and history.

Failure messageTest stagePrevious attemptsRepeat historySystem stateKnown procedure
VERIFY / RERUNKnown transient issue; procedure permits.
DEBUGRepeated or hardware-indicative failure.
ESCALATE WITH CONTEXTUnknown or outside documented procedure.
TT investigation → TE / PE
Failure signatureSystem statePrevious attemptsKnown-good comparisonSuspected domainRelevant logs

Signature + state · attempts + comparisons
Suspected domain + relevant logs

Selected example: investigate a repeated failure.

00 / System context

GB300 system debugging.

One system. Several fault domains.

NetworkComputeComponentsSystem state
Test fixture ─ Network / Cat6A ─ Power

Testing starts with the infrastructure around the system.

01 / Configure

Bring-up starts here.

Is the environment ready for testing?

CONSOLE-01 / Serial console
console > connect
switch > configure
interface > status
network > verify
IP 10.x.x.x
MAC XX:XX:XX:XX:XX:XX
Shop floor configurationCONFIGURED
KNOWN GOOD ─────────CURRENT ───── ×
02 / Isolate

Change one variable.

Where does the failure follow?

CT ACable APort A
TEST FAILFailure returns with Cable A. Original cable implicated.
CT? · less likelyCable A · implicatedPort? · less likely
01 · Cable A TEST FAIL
02 · Cable B PASS
03 · Cable A TEST FAIL

Evidence > assumption. Reintroduce Cable A to confirm the failure follows it; keep the CT and port constant.

03 / Physical path

Inspect the connection.

A failed test is an observation, not a diagnosis.

LINK UPInspect → Reseat → Verify
Cable seatingConnector damagePowerPort stateComponent seating
Isolate / Alternate power fault

Measure. Divide. Narrow.

The same reasoning, through a different tool.

System / Power-on failureLeft normal / Right abnormalArea A normal / Area B suspect

Compare regions, set aside what tests normally, and narrow the suspected fault domain. Measurements guide the next investigation.

04 / Verify

Read the system state.

Does the observed state confirm the reported failure?

RECENT HISTORYPrevious: cable reseatedCurrent: same failure
CT A / Linux · BMC · System state
sensor_01     OK
sensor_02     OK
temperature   42 C
power         OK
nic_state     UP
device_state  READY
firmware      CHECKED
logs          REVIEWED
sensor_03     WARN ↗

An observation guides investigation; it does not prove cause. Outside the procedure? Package history, comparisons, and logs for escalation.

05 / Repair

Service. Then retest.

What needs physical investigation?

LocateInspectRemoveReplace / ReseatRetest
RETEST PASSComponent seated. System state verified.

Alternate service example / OSFP board. A warning guides investigation; it does not establish the cause by itself.

06 / Document

Make the next diagnosis easier.

Hands-on process + experienced engineer input → shared knowledge.

SOP / Generalized debugging flow
Failure detected↓Verify sensor / state↓Inspect / Reseat↓Retest
PASS ↓
Document / CloseFAIL ↓
Escalate with evidence

One debug session.
A procedure the team can reuse.

Improve / Data & process

Make the process easier to see.

Reduce complexity until the useful signal becomes visible.

PYTHON / ILLUSTRATIVE ANALYSIS
$ python analyze_tests.py
normalize → group → report
Normalize failuresGroup recurring signaturesKeep hardware contextFormat the daily report
Illustrative raw rows / excerpt
CT-01PASS
CT-02LINK_FAIL
CT-03PASS
CT-04SENSOR_WARN
CT-05PASS
Grouped failures / full fabricated dataset
LINK_FAIL3
SENSOR_WARN1
POWER_STATE1

13 tested · 8 passed · 5 debug · 0 retest
Pass rate 61.5%. Context: cable / port state, previous occurrences, current stage.

Less time formatting. More time investigating.

Which failures keep coming back?

  1. configure
  2. isolate
  3. verify
  4. repair
  5. document
Scroll to inspect ↓
Read the debugging workflow
  1. Observe and triage. Monitor test state, recognize failures and stalled tests, then read context and history. Rerun when appropriate, investigate repeated failures, or escalate unknown issues with evidence.
  2. Configure. Connect to the serial console, verify network state, and use sanitized device values to complete bring-up.
  3. Isolate. CT A + Cable A + Port A fails. Change only to known-good Cable B: pass. Reintroduce Cable A: fail. The original cable is implicated; CT and port are less likely.
  4. Inspect the physical path. Check connector damage, cable seating, power, and port state. Reseat the RJ45 connector and verify the link.
  5. Electrical isolation. For an alternate power-on failure, compare broad regions, then narrow the abnormal side to a suspected board area. Normal readings set regions aside; abnormal readings guide further investigation.
  6. Verify. Check sensors, temperatures, power, NIC, devices, firmware, and logs. Map an abnormal sensor observation back to the related hardware region.
  7. Repair. Locate and inspect the representative OSFP board, remove and replace or reseat it, then retest. A sensor warning alone is not a component diagnosis.
  8. Document. Convert the component view into a technical diagram and a generalized SOP. After retesting, document a pass or escalate a failure with evidence.
  9. Improve. Use Python/Excel tooling to normalize results, group recurring signatures, preserve context, and prepare reports. Automation organizes evidence for engineering judgment.
Documentation is infrastructure too.

Static PDF → editable reference → searchable sections → working links → glossary

Find the failure.
Understand the pattern.
Make the next one easier.