Hardware EngineerInterview Questions & Practice

Q1. How would you debug a timing failure that only appears after place-and-route?

Strong answer: Pre-route timing uses estimated wire delays, so a post-route-only failure means real routing — congestion, long detours, high-fanout nets — exceeded the estimates, or the constraints are incomplete (missing false-path or multicycle exceptions, wrong clock relationships). Work the fixes in order of cost: correct the constraints, add floorplan guidance, duplicate registers on high-fanout nets, and only then pipeline or retime the RTL.

Weak answer: A weak answer blames the tool without using the reports or verifying the constraints.

Q2. When do you prefer a SAR ADC over a sigma-delta ADC?

Strong answer: SAR wins for low-latency, one-shot, easily multiplexed conversion at moderate resolution — roughly 8–16 bits at kS/s to MS/s rates, at low power. Sigma-delta wins for high resolution (16–24 bits) on narrowband signals, using oversampling and noise shaping, at the cost of decimation-filter latency that rules it out for fast control loops and channel multiplexing. A strong answer states that selection rule before reciting datasheet specs.

Weak answer: A weak answer treats ADCs as interchangeable and ignores the application requirements.

Q3. What would you inspect first if a PCB fails EMI testing near a clock edge harmonic?

Strong answer: The usual mechanisms are a return-path discontinuity — a trace crossing a plane split or changing layers without a nearby return via — or cable common-mode current turning the harness into the antenna. Fix the return path first, then slow edge rates or add series termination, and consider spread-spectrum clocking to flatten the harmonic peak. Shielding comes last, after the coupling mechanism is identified.

Weak answer: A weak answer only says to add shielding without finding the coupling mechanism.

Q4. Why does a signal crossing between two clock domains need a synchronizer, and when is a two-flop synchronizer not enough?

Strong answer: A flop capturing an asynchronous input can go metastable — settle to neither logic level within its timing window — and a two-flop synchronizer gives that state a full cycle to resolve before the logic sees it. Two flops stop being enough for general multi-bit buses, where bits can resolve on different cycles and corrupt the value (use an async FIFO, a handshake, or gray coding for values that change one bit at a time), and at very high clock rates where the resolution-time budget shrinks and a third flop is added to restore MTBF.

Weak answer: A weak answer adds two flops everywhere by habit, including across a multi-bit bus where per-bit synchronization corrupts the value.

Q5. How do you choose decoupling capacitors for a power rail feeding a high-speed digital load?

Strong answer: Work from a target power-delivery-network impedance across frequency: bulk capacitance handles low-frequency droop, mid-range ceramics cover the band between the regulator’s response and the package, and above a few hundred megahertz mounting inductance dominates, so placement — not more small capacitors — sets the ceiling. A strong answer derives the target impedance from the load’s current transient and allowed ripple.

Weak answer: A weak answer sprinkles 100 nF capacitors near every pin without connecting the choice to current transients or impedance versus frequency.

Q6. Why do designs assert reset asynchronously but de-assert it synchronously, and what goes wrong otherwise?

Strong answer: Asynchronous assertion guarantees the design resets even without a running clock; synchronous de-assertion guarantees every flop leaves reset relative to the same clock edge. If de-assertion is asynchronous, it can land inside a flop’s recovery window and different flops can exit reset on different cycles — an FSM can wake up in an illegal state. The standard structure is a reset synchronizer per clock domain, and reset-domain crossings deserve the same scrutiny as clock-domain crossings.

Weak answer: A weak answer treats reset as a global wire that simply works, never mentioning recovery/removal timing or per-domain synchronizers.

Q7. An interviewer asks you to write a short script that flags failing paths in a timing report. What are they checking?

Strong answer: The round tests day-to-day tooling fluency, not algorithms: parse slack values, group failing paths by clock domain or endpoint, and handle malformed lines without crashing. A strong answer narrates its assumptions about the report format while writing readable code, because that narration is what reviewing real scripts looks like.

Weak answer: A weak answer stalls on language trivia or writes a one-liner with no handling for the report structure, treating the exercise as an algorithm puzzle instead of a working tool.

Q8. Walk me through taking a board from spec to validation. Where do schedules actually slip?

Strong answer: Move through the stages in order and name the gate at each: capture requirements with power and thermal budgets; select and source components, treating availability as a design input rather than an afterthought; schematic capture; layout and stack-up with the signal- and power-integrity constraints set up front; a design review against DFM/DFT before release; fabrication and bring-up; then a written validation and characterization plan that maps back to the spec. A strong answer says where it slips — usually component lead times and a bring-up that surfaces something the review should have caught — and front-loads margin there instead of spreading it evenly.

Weak answer: A weak answer lists tasks with no review gates and treats validation as “power it up and see,” so the sourcing risk and the DFM/test handoff vanish from the plan.

Q9. How do you use scripting in an EDA flow, and what would you automate first?

Strong answer: Scripting (Tcl or Python) automates the repetitive, error-prone parts of the flow: parsing timing reports to flag failing paths by clock domain, running constraint and regression checks on every revision, batching simulations across corners, and generating manufacturing outputs consistently. Automate the timing and regression report first — it runs on every change and catches drift early. A strong answer treats readable, reviewable scripts as part of the deliverable, because the team has to maintain them after you.

Weak answer: A weak answer treats EDA tools as click-only GUIs and never mentions automating reports or checks, so every revision is re-verified by hand and silent regressions slip through.