Engineering Tradeoffs interview questions

10 questions, easiest first

1. 1Your manager tells you: 'The new sensor board needs to run for a long time on a coin cell.' Before you can pick a battery chemistry or design the power tree, what specific numbers do you need to pin down, and how would you go about getting them?intro

   This is about converting a vague requirement into something you can actually design and test against, which is the first thing an intern has to do on almost any hardware task.

   Answer this one, graded

   Or just show what a strong answer covers

   I'd push back on 'a long time' and get a real number, like 1 year of operation on a CR2032. Then I'd figure out the coin cell's usable capacity, say roughly 200mAh after derating for self-discharge and low-current cutoff, and divide by the target lifetime in hours to get an average current budget -- for a year that's on the order of low tens of microamps. Then I'd break that budget down by duty cycle: how much time is spent in deep sleep versus active sampling or transmitting, what each state draws, and whether the weighted average fits under the budget. If it doesn't, I know before committing to hardware that I need to either extend the sleep interval, cut active time, or accept a bigger battery.

   • Defines a concrete lifetime number — Answer states that 'long time' must become an explicit target such as 1 year, not left vague.
   • Derives average current budget — Answer computes or describes computing average current = battery capacity / target lifetime as the key design number.
   • Accounts for duty cycle / sleep current — Answer distinguishes active current, sleep current, and wake frequency as the levers that determine the average.
   • Mentions real-world derating — Answer notes self-discharge, temperature effects, or safety margin reduce usable capacity below the datasheet number.

   Where answers go wrong: Picking a battery chemistry before establishing any current or lifetime number. · Treating 'a long time' as good enough and moving straight to component selection. · Ignoring sleep current and self-discharge, assuming datasheet capacity is fully usable.

2. 2You're building a small sensor board for a demo in three weeks. It uses a wireless radio chip you've never worked with before, mounted in an enclosure design you've used many times. You can only build and test one thing first this week. Which do you tackle first, and why?intro

   Assume the radio chip's datasheet is dense and you have no prior experience with its RF matching network or driver stack. The enclosure is a minor variant of a mechanical design you've built successfully before.

   Answer this one, graded

   Or just show what a strong answer covers

   I'd start on the radio chip immediately, even before the rest of the board is done, because it's the unknown. The enclosure is a variant of something I've built before, so I already know roughly how long it takes and what can go wrong — that risk is already bought down. The radio is different: I don't know its RF matching requirements, its driver quirks, or how long bring-up will take, and if it turns out to need a redesign of the matching network or a different antenna, that could blow the whole three-week schedule. So in week one I'd get a minimal bring-up going — ideally on a breakout or eval board if one exists — just enough to confirm the chip talks over its interface and can transmit/receive at all, before investing time in the enclosure or full board layout. I'd rather find out on day three that the radio has a problem than on day eighteen.

   • Identifies the radio as the higher-risk item — Answer explicitly states the unfamiliar wireless chip is riskier than the enclosure because of unknown failure modes and lack of prior experience.
   • Ties risk to schedule impact — Explains that if the radio doesn't work, discovering that late leaves no time to recover, whereas enclosure issues are easier to fix quickly given prior experience.
   • Proposes a concrete first test — Suggests a specific fast, cheap way to de-risk the radio early, e.g., a breakout board, vendor eval kit, or minimal bring-up test before full integration.
   • Avoids treating both risks as equal — Does not simply say 'build both in parallel' without acknowledging one deserves priority given limited time.

   Where answers go wrong: Saying you'd work on whichever is easier to build first instead of whichever is riskiest. · Trying to do both simultaneously with no prioritization, which doesn't reflect limited time/attention. · Focusing on the enclosure because it's tangible, ignoring that its risk is already well understood.

3. 3You need to add a 5V-to-3.3V, 500mA regulated rail to a prototype board that's due for a demo in two weeks. Would you use an off-the-shelf buck converter module or design a discrete buck converter from scratch? Justify the choice and say what you're giving up either way.easy

   Answer this one, graded

   Or just show what a strong answer covers

   For a two-week demo, I'd use the module. The main risk here is schedule, not cost -- a discrete buck converter means picking an inductor and caps, laying it out cleanly, and validating it doesn't ring or oscillate, and any mistake there could easily eat the two weeks I have. A module is pre-validated, so I can drop it in and move on to the rest of the board. What I give up is per-unit cost, since a module might cost several dollars versus under a dollar in discrete parts, more board area, and less control over noise performance if this were feeding something noise-sensitive like an ADC reference. For a one-off demo those costs don't matter; if this were headed to production in volume, I'd revisit and design discrete once I have time to validate it properly.

   • Weighs schedule against cost — Answer explicitly connects the two-week deadline to favoring lower engineering risk over lower per-unit cost.
   • Names concrete tradeoffs of the module — Answer identifies at least two of: higher BOM cost, larger footprint, less control over switching noise/EMI, less flexibility in output tuning.
   • Names concrete tradeoffs of the discrete design — Answer identifies that discrete design needs component selection, layout, and validation time that a demo timeline may not allow.
   • States a clear decision — Answer commits to module or discrete for this specific scenario rather than staying neutral.

   Where answers go wrong: Recommending the discrete design 'because it's cheaper' without acknowledging the two-week deadline makes validation risk the dominant factor. · Listing generic pros/cons of modules vs discrete parts without ever answering the actual question for this scenario. · Ignoring that a badly designed discrete buck can introduce noise or instability that eats into the two weeks fixing it.

4. 4You just received the first prototype PCBs for a new board. Before you apply power for the first time, walk me through what you check and in what order, and explain why you prioritize those checks the way you do.easy

   Answer this one, graded

   Or just show what a strong answer covers

   First I'd visually inspect the board under magnification for solder bridges, missing components, or anything obviously wrong compared to the schematic and BOM. Then, before any power touches the board, I'd use a multimeter to check resistance between each power rail and ground to catch a dead short -- that's the cheapest check and the one that prevents the most expensive failure. Once that's clear, I'd bring the board up on a bench supply with the current limit set low, ramping voltage slowly and watching the current meter rather than trusting a fixed supply. If current climbs abnormally I stop immediately rather than letting something cook. Only after the rails look sane on a scope or DMM would I start bringing up digital sections one at a time, checking clocks and resets before touching firmware. The ordering is deliberate: catch the failures that would damage hardware first, since those are both the most costly and the cheapest to check for in advance.

   • Visual inspection before power — Answer mentions inspecting the board for solder bridges, missing/wrong components, or obvious defects before power is applied.
   • Continuity/short check with a multimeter — Answer explicitly checks resistance or continuity between power rails and ground to catch shorts before powering up.
   • Current-limited bench supply with slow ramp — Answer describes using a current-limited supply and watching current draw as voltage is brought up, rather than connecting a full-current source directly.
   • Justifies the ordering — Answer explains why these checks come first, in terms of preventing damage or catching the most likely/costly failure early, not just listing steps.

   Where answers go wrong: Jumping straight to checking if the microcontroller boots without first ruling out a short. · Connecting a fixed-voltage, non-current-limited supply directly to a first-run board. · Listing checks with no reasoning about why the order matters.

5. 5You're picking between two microcontrollers for a four-week internship project. MCU A is cheaper per unit but has sparse documentation, no reference design, and you've never used its toolchain. MCU B costs three times as much but has extensive app notes and you've used it before. Cost isn't the real constraint here — your four weeks is. Walk through how you'd decide, and then tell me what would change your answer if you had six months instead of four weeks.easy

   Assume unit cost matters for a future production run but this specific project is a one-off prototype under a hard deadline.

   Answer this one, graded

   Or just show what a strong answer covers

   For the four-week version I'd pick MCU B, the one I've used before, even at three times the cost. On a one-off prototype, that price difference is probably a few dollars total — trivial compared to the risk of burning a week of my four fighting an unfamiliar toolchain or chasing a bug because the datasheet doesn't cover an edge case. Unfamiliar parts have unpredictable debug time, and unpredictable debug time is the one thing I can't afford on a hard deadline. If MCU A had an eval board with a working reference design I could copy, that would change my calculus, since it removes a lot of the unknown. For the six-month version, I'd lean toward MCU A instead, because now I have enough runway to absorb the learning curve, and if this project could turn into something produced in volume, the lower unit cost actually starts to matter and is worth the upfront investment in learning the new toolchain.

   • Picks MCU B for the 4-week case with a stated reason — Selects the familiar, well-documented part and justifies it in terms of reducing schedule risk, not just personal preference.
   • Explicitly deprioritizes unit cost for this scenario — States that the 3x cost difference is a small absolute number for a one-off prototype and shouldn't drive the decision here.
   • Identifies what could still make MCU A viable — Mentions conditions like an evaluation board, community support, or a colleague's prior experience with it that could de-risk it even short-term.
   • Gives a coherent answer for the 6-month case — Explains that with more time, the unfamiliar MCU's risk shrinks relative to the schedule, and unit cost or long-term suitability becomes a bigger factor in the decision.

   Where answers go wrong: Picking based purely on price without addressing the time constraint stated in the prompt. · Treating documentation quality as a minor inconvenience rather than a direct schedule risk. · Giving the same answer for both time horizons without explaining what actually changes.

6. 6You're picking a microcontroller for a project. Option A costs $2 and has just enough flash and RAM to fit the current firmware with zero margin. Option B costs $5, has double the flash and RAM, and is pin-compatible with Option A. You're about to order 50 boards for a semester-long project that has two more feature additions already planned. Which do you choose, and walk me through the reasoning, including any numbers you'd use to decide.medium

   Answer this one, graded

   Or just show what a strong answer covers

   I'd go with Option B. The total cost difference across 50 boards is only about $150, which is small compared to the cost of getting stuck mid-semester. Zero margin on Option A means the very first feature addition, or even adding debug logging to chase a bug, could blow the flash budget and force either a painful optimization pass or a part swap -- and since I don't know yet how big those two future features are, that's a real risk, not a hypothetical one. Because B is pin-compatible, switching to it costs nothing in board redesign, so there's no schedule penalty for taking the safer option now. If B weren't pin-compatible, or if the future features were fully specified and I knew for certain they'd fit in A's margin, I might reconsider, but as stated, the $150 buys a lot of insurance against a much more expensive problem later.

   • Quantifies the total cost difference — Answer computes or references the total added cost across 50 units (roughly $150) rather than just per-unit cost.
   • Identifies memory margin as the real risk — Answer explains that zero margin becomes dangerous once more features and debug/logging code are added later in the semester.
   • Compares against the cost of running out of margin — Answer weighs the $150 delta against the cost/time of a respin, reflash cycle, or being stuck unable to add features, and shows the latter is larger.
   • Uses pin-compatibility in the reasoning — Answer notes that because the parts are pin-compatible, choosing B doesn't cost board redesign time, lowering the switching cost of picking the safer option.

   Where answers go wrong: Choosing based on per-unit price alone without considering the total project cost or the cost of a failure. · Ignoring that firmware tends to grow over a project's life due to added features and debug instrumentation. · Failing to use the pin-compatibility fact, which removes most of the risk of choosing the larger part.

7. 7The spec for a temperature sensor project just says: 'must work outdoors.' Your job is to turn that into a testable requirement before you can choose a sensor and design an enclosure. What questions would you ask, what would the resulting numeric spec look like, and what would you consider the biggest risk to test for first?medium

   Answer this one, graded

   Or just show what a strong answer covers

   I'd ask where it's being deployed and over what season, whether it sits in direct sunlight, whether it's exposed to rain or just humidity, how long it needs to survive unattended, and whether altitude or wind matters. From that I'd write a real spec: something like ambient air temperature of -20C to 45C, but internal enclosure temperature spec'd separately at up to 70 or 80C because a sealed enclosure in direct sun runs well above ambient from solar loading, plus an IP65 rating for rain and dust. The risk I'd worry about most isn't the cold extreme, it's that daily heating and cooling cycles inside a sealed box can drive condensation, which is a common field failure for outdoor electronics. I'd want to validate that early with a thermal chamber cycling test combined with a humidity soak before locking the enclosure design, rather than finding out about condensation after units are already deployed.

   • Asks clarifying questions before specifying — Answer lists specific questions such as climate/location, exposure to direct sun, rain/humidity, deployment duration.
   • Produces a numeric ambient and internal temperature range — Answer states explicit temperature numbers (not just 'wide range') and distinguishes ambient air temperature from enclosure internal temperature due to solar loading.
   • Specifies ingress protection — Answer proposes a concrete ingress protection level (e.g. IP65 or similar) or equivalent qualitative sealing requirement tied to rain/dust exposure.
   • Identifies the dominant risk and a way to test it early — Answer names a specific likely failure mode (solar loading raising internal temperature, or condensation) and proposes an early test such as a thermal chamber or humidity soak to validate before committing to the design.

   Where answers go wrong: Picking a sensor's operating temperature range straight from a datasheet without questioning what 'outdoors' actually implies for the enclosure's internal temperature. · Treating ambient air temperature and enclosure internal temperature as the same number. · Stopping at listing clarifying questions without ever converting them into a numeric, testable spec.

8. 8You need to add wireless connectivity to a sensor board for a one-month class demo. Would you use a pre-certified, plug-in Bluetooth module, or design your own radio circuit around a bare RF chip and antenna? Walk through your reasoning, then tell me how your answer changes if this design were instead headed toward a production run of 100,000 units.medium

   Assume you have basic RF layout knowledge but have never designed an antenna matching network from scratch, and no certification lab access.

   Answer this one, graded

   Or just show what a strong answer covers

   For the one-month demo, I'd use the pre-certified module. Designing your own RF front end means getting the antenna matching network right, which typically takes multiple board spins and access to a network analyzer or spectrum analyzer to verify, and I don't have that kind of iteration time in a month. A module also sidesteps certification concerns since that's already handled by the vendor. The cost premium per unit is real but small in absolute terms for a one-off demo. If this were headed to 100,000 units, though, that same per-unit premium turns into a large recurring cost, so I'd revisit the decision — but only if the team actually has RF design expertise, the test equipment to characterize the antenna, and budget and schedule for certification, because those are the real costs of 'build' that don't show up in the BOM. If we don't have that expertise in-house, sticking with the module even at scale might still be cheaper than the risk of a failed launch.

   • Chooses module for the demo case with risk-based reasoning — Selects the pre-certified module and explicitly cites RF tuning/certification risk as the reason, not just convenience.
   • Names a specific risk of the custom path — Mentions at least one concrete failure mode of rolling your own radio: mismatched antenna impedance, failed range, or lack of certification for the frequency band.
   • Quantifies the tradeoff at scale — Explains that at 100k units the module's per-unit cost premium becomes a large recurring expense that could justify the upfront investment in a custom design.
   • Notes what capability/resources would be required to build in-house — Acknowledges that building your own radio at scale requires RF expertise, characterization equipment, and certification budget/time that a small team may not have.

   Where answers go wrong: Choosing the module without mentioning cost-at-scale as the tradeoff that would flip the decision. · Assuming custom RF design is purely a layout exercise and ignoring certification and tuning risk. · Giving a single answer for both timeframes without acknowledging that volume changes the math.

9. 9Partway through a project you learn that a key ADC on your board is being discontinued in six months. You have a working prototype and a demo in one month. Your three options are: (1) do a last-time buy of enough parts to cover two years of expected production, (2) redesign around a substitute part now, which delays your schedule by three weeks, or (3) do nothing yet and deal with it when supply actually runs out. Walk me through how you'd decide, including what data you'd want and how the one-month demo factors into it.hard

   Answer this one, graded

   Or just show what a strong answer covers

   First I'd note the one-month demo isn't really affected by any of these options since the prototype already has working parts -- so I wouldn't let demo pressure drive a long-term supply chain decision. The real question is what happens to production over the next two years. I'd want to know expected volume, the cost and lead time of qualifying a substitute part, and the carrying cost of holding two years of inventory versus the capital it ties up. Given that, I'd lean toward doing a modest last-time buy immediately -- it's relatively cheap insurance and doesn't touch the current schedule at all -- while starting substitute part evaluation in parallel on a slower timeline, rather than a full three-week redesign done under pressure right now. 'Do nothing' is the riskiest option since it risks a production halt with no fallback once the part actually disappears, and the cost of that halt is almost certainly larger than the cost of the last-time buy or the parallel evaluation work. So my answer isn't strictly one of the three, it's a hybrid that buys down the risk cheaply now while doing the real fix on a schedule that doesn't threaten the demo.

   • Recognizes the demo is decoupled from the decision — Answer notes the one-month demo already has parts in hand and isn't affected by which long-term option is chosen, so it shouldn't be used to justify delay or rushing.
   • Requests concrete decision-relevant data — Answer asks for specifics like expected production volume, unit cost of last-time buy inventory vs storage/capital cost, and lead time to qualify a substitute.
   • Weighs cost and risk of each option against each other — Answer compares the capital tied up in a last-time buy, the schedule cost of an immediate redesign, and the risk of running out of stock under 'do nothing.'
   • Proposes a staged or hybrid mitigation — Answer proposes doing a bridge/last-time buy immediately as low-cost insurance while starting substitute part qualification in parallel, rather than treating the three options as mutually exclusive.

   Where answers go wrong: Letting the one-month demo drive the whole decision, when the demo already has working parts regardless of which option is chosen. · Treating the three options as strictly exclusive instead of considering a combined approach. · Recommending 'do nothing' without acknowledging the risk of a production halt if the part runs out before a substitute is ready.

10. 10You're told an enclosure 'must be rugged enough for field use.' You have budget for exactly one round of drop testing before the mechanical tooling is locked in and further changes become expensive. Walk me through how you'd turn 'rugged' into a testable spec, and then how you'd decide what to actually test given you can't test every possible drop height, angle, and surface.hard

    Assume the product is a small handheld electronic device, tooling lock is irreversible without significant cost, and you have a small budget for prototype units to sacrifice in testing.

    Answer this one, graded

    Or just show what a strong answer covers

    First I'd nail down what 'rugged' actually means for this device: dropped from what height, in whose hands, onto what surface, how many times, and what counts as failure — fully functional, cosmetic scuffing allowed, or must survive but repair is okay. For a handheld device, I'd anchor the height to a realistic worst case, like hand-to-hip or hand-to-floor for someone standing, say roughly a meter, dropped onto a hard surface like concrete or tile, since that's the worst plausible everyday scenario, not a lab-only test. I'd also decide the orientation matters — corner drops concentrate force and are more likely to crack a case or crack solder joints than a flat-face drop. Since I've only got budget for one round and a handful of prototypes, I wouldn't spread them across every angle and height combination. I'd prioritize the drop condition most likely to happen in real use and most likely to reveal a structural problem that would require retooling — probably a corner drop from the realistic height onto a hard surface, repeated a few times, since a design that survives that likely survives gentler cases too. And because tooling lock is expensive to undo, I'd treat this round as my one shot to catch anything that would force a mechanical redesign, so I'd rather over-test the worst-case scenario thoroughly than lightly test many scenarios and miss the one that actually breaks the part.

    • Proposes concrete, measurable spec parameters — Names specific values or ranges for drop height, number of drops, surface, and orientation rather than staying abstract.
    • Justifies the numbers with a real-world basis — Ties chosen parameters to how the device would actually be used or dropped, e.g., pocket height, work-bench height, or a relevant existing standard used as a starting reference point.
    • Explains a prioritization scheme for limited test units — Describes a method for choosing which combination of drop conditions to test first given scarce prototypes, based on likelihood and severity of failure.
    • Addresses irreversibility of tooling lock in the plan — Explicitly reasons that because tooling is expensive to change afterward, the single test round should target the failure mode most likely to force a redesign, not just check a box.

    Where answers go wrong: Leaving 'rugged' undefined and jumping straight to a test plan without specifying numbers. · Proposing to test every possible drop height/angle/surface combination without acknowledging limited prototype budget. · Picking an arbitrary industry standard drop spec without connecting it to how this specific device is actually used. · Ignoring that a failure discovered after tooling lock is much more expensive to fix.