Novo Space — Interview Prep

• Mass and volume envelope. These are non-negotiable constraints that bound every subsequent decision. Before opening CAD I want numbers.
• Thermal architecture. Where does the heat leave? The conduction path from PCB → chassis wall → radiator surface drives the enclosure geometry and material before any structural consideration enters.
• Launcher environment. What are the qual levels, and what's the minimum first-frequency requirement? That tells me immediately how stiff the walls need to be and where I can't afford thin features.
• Interface definition. How does it mount to the spacecraft, and what's the load at that interface? I can't finalize base plate thickness or fastener pattern without known boundary conditions.
• PCB layout understanding. Where are the connectors, where do the heavy components sit, and what's the board retention strategy? The enclosure is a structural support for the board — I need to know what I'm supporting before designing the support.

Simulate where the physics is tractable and boundary conditions are well-defined: static margins under quasi-static loads, modal frequencies (with the plan to correlate afterward), steady-state thermal with known heat sources.

Test where they aren't. Shock: FEA is unreliable past a few hundred Hz for transient shock — the SRS method is empirical by design, so hardware test is the primary verification. Workmanship: no simulation catches a cold solder joint or an under-torqued fastener. Thermal interfaces: contact resistance is highly sensitive to surface condition, clamping torque, and TIM batch variation — I'd rather measure it than calculate it.

The rule of thumb I use: if the model requires an "ideal" or "perfect" assumption for something I know is imperfect in real life, that's a test candidate. If I can't write a credible uncertainty bound on the assumption, test it.

First: don't automatically blame the model. Document the failure mode precisely — where did it fail, how, at what load level relative to the predicted margin?

• Check the test setup: do the fixture boundary conditions match the model?
• Verify mass properties: did the real hardware match the model's mass and CG?
• Look at interfaces and joints — these are where FEM boundary conditions are most idealized. A "fixed" joint in the model may be compliant in reality.
• Check the failure location against the stress map — was it where the model showed the highest stress, or somewhere else entirely?

Then update the model to replicate the failure: adjust joint stiffness, boundary conditions, or material properties until the model predicts what actually happened. Use that correlated model to redesign. And document the category of assumption that was wrong — so you apply more conservatism or add a test there next time.

The more common mismatch in practice is actually at the component level: SAC solder (~23 ppm/°C) against ceramic packages like alumina (~6–7 ppm/°C) or silicon (~2.6 ppm/°C). That's a fatigue problem — calculate the shear strain on the solder joint per cycle and compare to fatigue life data (IPC-SM-785 or Engelmaier's model).

For PCB-to-chassis: FR4 is ~18 ppm/°C in-plane, aluminum ~23 ppm/°C — aluminum actually expands more. Strategies:

• Use a compliant TIM that accommodates differential motion rather than a rigid bond across a large interface area
• Keep PCBs short to minimize absolute differential displacement
• For large boards, use flexible retention (wedge locks or spring clips rather than rigid bolt-through)
• Specify solder joint inspection after TVAC — this is where you find out if your analysis was right

• Start from the mission concept — what launcher family is plausible? Published user guides for Falcon 9, Vega, Ariane, and Rocket Lab give ballpark environments even before a specific ICD exists.
• Use the most demanding plausible environment as an upper bound, add margin per ECSS-E-ST-10-03 or GEVS.
• Check heritage hardware: if the company has flown on a similar launcher, use that correlation as a reference point.
• Engage the launch campaign team early — there's often a preliminary environment or notional ICD even before formal assignment.
• Document the assumption explicitly. When the real ICD arrives, you immediately check whether your bounding assumption held or whether re-analysis is needed. The goal is to not have hardware designed to an under-estimate.

You can't fully validate a space thermal model without vacuum, but you can characterize the conduction paths — which is usually where the uncertainty lives.

• Resistance heater test in air: apply known watts from an embedded heater, measure temperatures at junction, PCB, chassis wall, and ambient. Subtract the convective component analytically (or via a powered-off baseline). What remains is the conduction delta-T, which gives you conductance (W/K).
• TIM stack-up test: bolt test coupons with your TIM at the intended torque, apply power from an embedded heater, measure temperatures across the joint. This directly measures interface thermal resistance — the number most models get wrong.
• Cross-check material properties: compare your model's predictions against published k-values for your materials. If the model and the material database agree, the model isn't obviously wrong.

Then: validate the model against the benchtop data including convection, freeze the model, and remove convection for the flight prediction. The benchtop correlation error becomes your uncertainty bound on the space-environment result.

Workmanship failure: the design is correct, but manufacturing introduced a defect — cold solder joint, wrong torque, incorrect material, missed process step. A correctly built unit would pass.

Design failure: the design itself is inadequate. Insufficient margin, geometry that concentrates stress, wrong CTE assumption. Every correctly built unit will fail at the same condition.

How to tell them apart:

• Can you find a manufacturing discrepancy in the build records, inspection data, or teardown? If yes — workmanship candidate.
• Did it fail at a location the analysis flagged as high-stress, or somewhere else? Unexpected failure location points toward a model error (design issue) or a process defect.
• If you have multiple units, did all of them fail at the same place and level? Consistent failure = design. Sporadic failure = workmanship.

The consequence matters: workmanship → NCR + rework + retest of that unit. Design → stop the campaign, redesign, and re-qualify from the beginning.

• First, quantify the delta: what loads increased, by how much, and at what frequencies? Get the original qual records — what levels were actually tested, and what margins were demonstrated?
• For each environment increase, check whether the demonstrated margin covers the delta. If the original qual had enough headroom (e.g. was done at +3 dB over flight levels), some increases may be absorbed without re-test.
• Where the delta exceeds the existing margin: run analysis first with the updated loads. If the FEM shows margin is still positive, document the qualification-by-analysis with a similarity argument.
• Where analysis shows the margin is eaten up: targeted re-test at the new levels. Not necessarily a full campaign — you test the environments that changed and the failure modes that are sensitive to them.

The principle: re-qualification is not automatically re-testing everything. Identify what changed, identify where the margins were thinnest, and test those specifically.

Random vibration simulates the broadband acoustic and mechanical environment of launch — the rocket produces noise that excites the structure at all frequencies simultaneously, not one at a time. The test demonstrates that the structure and any mounted equipment can survive this environment. It's also the primary workmanship screen for electronics: cold solder joints, inadequately secured components, and loose fasteners show up here before they show up in flight.

A modal survey measures the actual natural frequencies and mode shapes of the hardware. You do it for three reasons:

• Validate the FEM — are your analytical predictions correct?
• Identify the true resonant frequencies before setting qualification test levels
• Provide a structural health baseline — repeat after environmental tests to detect any change (frequency shift = structural change)

If the modal survey disagrees significantly with the FEM, you update the model before proceeding with the full qualification campaign.

A slow sine sweep at low level is used to:

• Identify resonant frequencies — the structure amplifies the input at its natural frequencies
• Compare those measured modes against analytical (FEM) predictions
• Detect structural changes before and after a more aggressive test (random vib, shock, TVAC) — a frequency shift tells you something changed

At qualification levels, a sine sweep can also be a standalone environment (for launcher-induced lateral sine), but the low-level modal survey sweep is a diagnostic tool, not a qualification test itself.

Sine vibration is a single frequency moving energy through the structure at one frequency at a time — like plucking one guitar string. It finds resonances by sweeping through them one by one.

Random vibration applies energy across all frequencies simultaneously — more like hitting a drum. The structure responds at all its natural frequencies at once, which is what actually happens during launch. The statistical character matters: the amplitude at any instant is unpredictable, described by its RMS level and spectral shape (PSD), not a deterministic amplitude. This is why random vib is more representative of the actual launch acoustic environment than a swept sine.

A trustworthy FEM has four properties:

• It matches the mass of the real hardware within ~2%
• Boundary conditions reflect the actual physical interface — not idealized as rigid if the joint has compliance
• Mesh is converged at critical locations — you can show that refining further doesn't change the answer meaningfully
• It's been correlated against test data — predicted frequencies and strain responses match measurements within accepted tolerances

Beyond the numbers: a model you can't explain is not trustworthy. Every simplification should be documented and its effect on conservatism understood.

The core habit is involving the process early. Before detailing a design I ask: how is this going to be made, held, measured, and assembled?

• Minimize part count — every additional part adds tolerance stack and assembly steps
• Standard features (hole sizes, thread forms) wherever performance allows — reduces tooling and inspection burden
• Avoid features that create machining problems: sharp internal corners, deep narrow pockets, thin walls in tall features
• Design datums that carry through from machining to assembly to inspection
• Tolerances applied only where they're functionally necessary — not uniformly tight

In a space context: add cleanroom assembly constraints — consider torque tool access, connector float for alignment tolerance, and part handling without contamination.

The key differences that matter in practice:

• Stiffness-to-weight: CFRP is significantly better — allows lighter structures for the same stiffness, which is why it's used for satellite panels and booms
• Failure mode: metals yield and deform visibly before fracture. Composites fail abruptly — delamination or fiber fracture with little warning, which changes the inspection and margin philosophy
• Anisotropy: composites are directional — properties depend on fiber orientation. Metals behave the same in all directions. This means layup design is a critical engineering decision, not just a manufacturing detail
• CTE: CFRP can be tailored to near-zero CTE — valuable for dimensional stability of optical benches or reflectors in orbit where aluminum would distort with temperature
• Repairability: a damaged metal bracket can often be reworked. A delaminated composite panel generally cannot — especially not in space

• All requirements are allocated and understood — no TBDs on design drivers
• Analysis is complete with positive margins: stress, modal, thermal, fatigue — with documented conservatisms on each
• Drawings are at a level where manufacturing could quote and build from them
• Risk register has no show-stoppers — open items have owners, workarounds, or a clear path to closure
• Test plan is approved — we know how we're going to verify every requirement before committing to hardware

The practical test I apply: could I hand this design to someone who had no prior context, and would they be able to build it and verify it without asking me fundamental questions? If not, it's not CDR-ready.

First step: separate the technical question from the schedule pressure. The two conversations should not happen in the same room at the same time.

Document the anomaly completely before any disposition: what failed, where, at what condition, what does the data show. Three disposition paths:

• Accept as-is: requires documented analysis showing the unit is still within design life margins. If I can't write rationale that a reasonable engineer would sign, we can't accept.
• Rework: fix the root cause. Requires understanding whether it's workmanship or design — a workmanship fix doesn't require re-qual, a design change might.
• Retest: if the root cause is understood and the fix is validated, retest at the appropriate level.

My job is to make the technical risk visible and give options with trade-offs — not to make the risk disappear to protect the schedule. At AST, I put an anomaly disposition rationale in writing specifically because program pressure was pushing toward "accept." The written rationale forced a real decision.

• Lead with the consequence, not the mechanism: "If this fails, the unit stops working" rather than "the solder joint fatigue life is marginal under thermal cycling"
• Quantify it in terms they can act on: probability, severity, cost to mitigate now vs. cost of failure later
• Give three things: what I recommend, what the alternative is, and what happens if we do nothing
• One page or less — if I need more than a page to communicate a risk, I haven't understood it well enough yet
• No jargon, or define it once inline if unavoidable

The goal is not to explain the physics. The goal is to get the right decision made by the right person with the right information.

At Satellogic, we had several ECRs (Engineering Change Requests) post-CDR — mostly driven by component availability or supplier changes during production.

The process: raise an ECR with the delta documented — what changed, what drove the change, and what the impact is on mass, thermal margins, and structural margins. Route it through the relevant stakeholders: structural analysis signs off if geometry changed, thermal if materials changed, manufacturing if processes changed.

Update the drawings under revision control and close the ECR with all signatures. The flight unit's serial number traces to the approved drawing revision, which traces to the ECR closure.

The discipline that matters: even under time pressure, every change goes through the process. One undocumented change in a flight unit means you can't root-cause an anomaly if something goes wrong later.

• The analysis answers the specific question it was set up to answer — margin against a defined load case, not a vague "is it strong enough"
• All loads are sourced: traced to a load document, ICD, or test-derived input
• All boundary conditions are justified — not just applied
• Material properties are traceable to a specification or a test data source
• The result includes a margin of safety with the applicable factor of safety per the relevant standard (ECSS, GEVS, or program-specific)
• Assumptions are documented with their effect on conservatism — is each assumption conservative or non-conservative, and by how much?
• There's been an independent check: a second reviewer, or at minimum a hand calculation that gives the same order of magnitude
• The model is under configuration control — the version is linked to the drawing revision it was based on

• Built-in self-review discipline: walk away from the model for a day, then come back to it as if I'm the checker. Fresh eyes catch what tired eyes miss.
• Independent validation: if FEA says X, a hand calculation should agree to the same order of magnitude. If they don't, I find out why before trusting either.
• Cross-discipline review: an electrical engineer can check whether my thermal model makes physical sense. A test engineer can flag whether my test assumptions are realistic. I use the team even when they're not the structural expert.
• Document assumptions as you go: writing down the "why" forces you to test whether the assumption is defensible. If I can't write it down, I don't have it.
• Know when to get outside help: a one-day review by a consultant who's done this before is cheaper than a failed test campaign.

At Satellogic there were periods where I was effectively the only person running structural on a product. The habit that mattered most was writing the assumption before making the decision — not after.

• Map each task to its downstream consequence: what blocks what? The test campaign has a hard start date — what does it specifically need from me to proceed?
• Clear the test campaign blockers first. Not the most interesting task, not the oldest — the one that stops progress if I don't do it.
• For the remaining design tasks: separate critical-path items (someone is waiting on my output to proceed) from float items. Critical path before end of day; float waits.
• Communicate proactively: if something won't be done on time, I tell the people waiting — with a realistic estimate — before they find out by missing it.

Silence creates worse problems than a late-but-honest estimate.

Yes, at AST SpaceMobile. We had a test campaign planned with a compressed schedule that didn't include adequate review time between thermal and vibration testing.

My concern: we'd be adding vibration loads to hardware whose post-thermal functional data hadn't been reviewed. If something failed after both tests, we wouldn't be able to isolate whether it was thermal- or vibration-induced — and that changes the entire disposition path.

I put the risk in writing: here's what we lose technically by compressing the gap, here's what it costs to fix it if we can't isolate the root cause. The program pushed back initially. We negotiated to two extra days — not the full week I wanted, but enough to do a targeted review of the post-thermal functional data before proceeding.

The campaign went clean. But the point wasn't that I was right — it was that the decision got made with the risk explicitly on the table.

At Satellogic, some enclosures went from design start to first article in under six weeks.

What we skipped: formal PDR with external reviewers — we did an internal design review instead. Faster, but less external challenge of the assumptions.

What we kept: FEM before releasing drawings, full dimensional inspection on the first article, written test procedure even for a quick functional.

The corner that came back: we reused a TIM from a previous design without doing a new interface conductance test — the new PCB had a different surface finish. The first thermal test showed a hotter-than-predicted junction temperature. We caught it on the engineering unit, not the flight unit. But it was avoidable — and it came from assuming a heritage result applied to a changed condition.

Right corners to cut: documentation formatting, review gate formality on genuinely unchanged heritage. Wrong corners to cut: interface characterization, margin check on any changed geometry or material.

Keep minimum viable documentation current in real time: the drawing and the test procedure stay accurate. Everything else can be a note that gets formalized later.

During a test campaign at Satellogic, I kept a running log — a simple text file updated at end of each test day: every deviation, measurement, and decision made on the floor. That became the basis for the test report. It wasn't a separate documentation effort — it was the test report in draft form from day one.

The failure mode I've seen more than once: saving all documentation for after the campaign. By then, you've forgotten why a decision was made, and the pressure to ship means the "why" never gets written. Write the "why" at the moment you make the decision. That's when you have the information and the context.

• Mass budget from the component list, not from a commercial reference. Rad-hard components can be 2–3× heavier than commercial equivalents for the same function — a commercial-sized enclosure may not close the mass budget.
• The enclosure geometry is driven by the board, not optimized independently. Non-standard form factors mean the PCB layout won't follow any standard — connector positions and mounting patterns need to be resolved with the electrical team before the enclosure envelope is frozen.
• Heavier components shift the CG and change the dynamic response of the board. The FEM needs actual component mass and position, not a uniform board density assumption. This matters for wedge lock selection and the board's fundamental frequency under random vib.
• This makes early involvement in the electrical design phase important. Component placement affects mechanical performance — a heavy rad-hard device near the board center vs. at a corner has very different structural implications.

Start with a power dissipation map: which components, how many watts each, and where on the board. This determines whether you have a distributed load or a hot-spot problem — the solutions are different.

• Conduction path to the chassis wall becomes a design parameter. You may need a thicker PCB, a heat-spreader layer, or direct thermal contact from component to chassis rather than routing all heat through the PCB substrate.
• Wedge lock conductance needs to be specified and verified. Clamping force, interface material, and measured conductance — not assumed. A wedge lock that's adequate for 5W/board may not be for 20W/board.
• The chassis wall at the board interface may need to be thicker or have machined contact features to maintain flatness and maximize conduction area.
• Check the component thermal resistance specification. Some older rad-hard packages have poorly characterized θja — if the datasheet doesn't have it, you need test data or conservative assumptions and wide temperature margins.
• If the power is high enough that conduction alone can't hold junction temperatures, consider cold plates or direct chassis contact pads — but this needs to be a system-level decision, not a local thermal patch.

At CNEA, some deployment mechanisms didn't have direct precedent in the combined shock + vibration + thermal vacuum environment we were designing for.

The approach: decompose the problem into elements where you do have heritage or data. The hinge material properties are known. The fastener pull-out strength is characterized. The spring mechanism can be tested at unit level. You don't have heritage for the assembly, but you can build confidence from the bottom up.

• Define a verification matrix early: for each requirement, specify whether verification is by analysis, test, or similarity — and document the delta between any similarity reference and the new case
• Establish confidence incrementally: coupon tests → unit-level → system-level. Each level is go/no-go before committing to the next
• Accept that some uncertainty remains, but document it, bound it, and make a conscious decision to accept it vs. test it away

Undocumented uncertainty is the dangerous kind — not because it's larger, but because nobody knows to account for it.

At Satellogic, I released a drawing with a thread and insert call-out that didn't match — M3 thread, but the insert was specified for a grip length that didn't match the actual wall thickness. It passed the internal drawing review and went to manufacturing.

We caught it at first article inspection when the insert stood proud of the surface. The fix was a week of rework and a drawing revision. No flight impact, but a week of delay on the first article acceptance.

What I changed: fastener and insert call-outs now get a specific check against the hardware catalog before any drawing release — not from memory, from the spec sheet. I also added that check to the review checklist I use, so the next engineer working on it has the same prompt.

The broader lesson: the things you know cold are the ones most likely to slip past review — because neither you nor the reviewer is looking carefully at something "obvious."

First principle: don't start from conflict. Electrical engineers are optimizing for their constraints — signal integrity, EMI, component availability. My job is to make the mechanical constraints legible in terms they care about.

"If this component is placed here, the thermal resistance to the chassis is 3× higher, and it will run 20°C hotter — is that acceptable for junction life?" is more actionable than "this placement is thermally suboptimal."

• Get involved at the schematic stage, not after the layout is frozen. Influencing component placement costs nothing at schematic; reworking the enclosure after layout is expensive.
• Give them constraints in their coordinate system: here's a thermal zone map of the chassis wall with conductance values per zone. They can optimize placement within that constraint without needing to understand the thermal model.
• Document the mechanical constraints in a format that goes into their design review — not a separate memo they have to chase.

At Satellogic, building that one-page layout guide for the electrical team reduced the back-and-forth on thermal placement from weeks to days.

The environment is unforgiving and non-negotiable — you can't go back and fix it. That forces a level of rigor in the design and analysis process that I find genuinely satisfying, because the rigor has real consequences rather than being administrative.

The integration challenge is also real: every subsystem has hard constraints, and they all conflict — mass, power, thermal, structural, EMC. Finding designs that close all the budgets simultaneously is a genuine puzzle, not an optimization problem with a known solution.

For Novo Space specifically: the intersection of harsh launch and radiation environments with the need for high-reliability compute is a problem that isn't solved. Radiation-hardened design constraints propagate into the mechanical architecture in non-obvious ways — heavier components, higher power dissipation, non-standard geometries — and that interaction between electronics and mechanical engineering is interesting to me. It's not a problem you can separate cleanly by discipline.

I want to own the complete mechanical architecture of a product — from requirements through test to on-orbit. Not just running the structural analysis or the thermal model, but making the trade-off decisions: how much mass margin do you hold back, when does thermal win over structural stiffness, what's the right qualification strategy for this specific risk profile.

Technically, I want to build depth in rad-hard hardware specifically. Right now I understand the mechanical consequences of radiation-tolerant design — heavier components, higher power densities. In three years I want to understand it the other way: starting from the electronics constraints and shaping the mechanical architecture proactively, before the conflicts exist rather than after.

I also want to get more useful at the system level. I've been strong at subsystem — I want to be the person who sees how a mechanical decision affects RF performance or integration schedule, not just the person who closes the mechanical requirements.