DEV Community: GinoCorp Industries

Ten failures, three causes: debugging an FDM 3D print

GinoCorp Industries — Thu, 03 Sep 2026 03:38:18 +0000

A failed 3D print doesn't throw. The printer runs to completion, the fan spins down, and as far as the machine is concerned everything went fine. The only artifact you get is the object, and the object is wrong.

That's a hostile debugging position by software standards. No logs, no stack trace, no exit code, and a test cycle measured in hours rather than seconds. It's also why searching a symptom produces such contradictory advice. You'll find five threads recommending five different fixes, most of which are correct some of the time, and none of which tell you what to check first.

There is one property of the system that makes this tractable, and in a narrow way it's better than logs.

The part is a record of its own execution

FDM printing is strictly sequential and strictly bottom-to-top. Layer 40 gets printed after layer 39 and is never revisited. So height on the finished part maps directly onto elapsed time. Where a defect starts on the Z axis tells you when the machine went wrong, and that one observation kills most of the candidate causes before you've touched a single setting.

You're not reading a log. You're holding one.

Which makes "when did this start?" the question to open with.

Triage by when it failed

Three branches. Pick the one that matches what's in front of you.

It failed in the first few layers.

Not sticking at all, or the corners are curling up off the bed → first-layer adhesion, or warping
Sticking fine, but the bottom two or three layers are visibly wider than the rest of the part → elephant's foot
The nozzle is dragging through plastic it already laid down → this is a Z-offset problem, and it's worth ruling out before anything else because it masquerades as half a dozen other failures

It failed partway up, and everything above that point is bad.

Layers splitting cleanly along a layer line → layer separation
Everything above a certain height is offset sideways from everything below → layer shifting
Walls look thin, gappy, or the part feels weaker than it should → under-extrusion
Surfaces look lumpy and the part measures oversized → over-extrusion

The structure is fine, the surface is the problem.

Thin hair-like strands spanning the gaps between separate parts → stringing
Small raised bumps, or one consistent vertical line running up the side → blobs, zits and seams
Extrusion slowed down or stopped entirely → clogged nozzle

The ten failures, with what's actually happening

Warping. Corners or edges lift off the bed as the print cools. Common on ABS and on large flat parts. The cause is uneven cooling: the bottom of the part stays hot against the bed while the top and edges cool and contract faster, and the resulting stress peels the part off the plate. Raise bed temperature toward the top of the material's range, add a brim or a raft, enclose the printer to kill drafts, and cut cooling fan speed for the first several layers.

Stringing. Thin strands of plastic strung between parts of the print. Filament is oozing out of the nozzle during travel moves. Usually retraction is too short or too slow, or the nozzle is running hotter than the material needs. Increase retraction distance and speed in small steps, drop nozzle temperature by 5–10°C, and turn on "combing" or travel avoidance in your slicer if it has it.

Poor first-layer adhesion. The print won't stick, or detaches partway through. Bed isn't level, or isn't at the right height relative to the nozzle, or the surface is dirty or too cool, or the first layer is printing too fast. Re-level, clean the plate with isopropyl alcohol, confirm the bed temperature matches the material, slow the first layer down, and add an adhesion aid like a glue stick if your build surface needs one.

Elephant's foot. The bottom layers bulge outward wider than the rest of the part. The first layers are being squished too flat, either because the nozzle is sitting too close to the bed or because the bed is hot enough to soften the base of the part under its own weight. Raise the Z-offset slightly and turn on your slicer's elephant's-foot compensation. Most modern slicers have one.

Layer separation. Layers split apart cleanly, sometimes days after the print finished. The nozzle wasn't hot enough to fully fuse each new layer to the one below, or the part cooling fans were running too aggressively for the material. Raise nozzle temperature in 5°C steps, reduce part-cooling fan speed, and check for drafts if you're printing ABS or ASA without an enclosure.

Under-extrusion. Gaps between lines, thin walls, a part that feels weaker than it should. Not enough plastic is reaching the nozzle tip. That's a partial clog, a worn extruder gear, too low a temperature, or a flow rate set too low. Run a cold pull to clear partial clogs, check that the extruder gear is actually gripping the filament, raise temperature slightly, and calibrate flow rate if your slicer supports it.

Over-extrusion. Rough, lumpy surfaces and parts that measure oversized. Too much plastic per unit of movement. Check that the filament diameter entered in your slicer matches what's on the spool, reduce flow rate or extrusion multiplier in small increments, and re-run a calibration cube to measure the result.

Layer shifting. Everything above a certain layer is offset sideways from everything below it. The print head or bed physically moved off-position: a loose belt, a skipped stepper motor, or the print head colliding with something. Check belt tension, make sure nothing is obstructing the gantry (a stray spaghetti blob from a previous failure is a classic), and reduce print or travel speed if the shifts happen on fast direction changes.

Blobs, zits and visible seams. Small raised bumps, or a consistent vertical line where each layer starts. Pressure builds up in the nozzle and releases right where a layer starts, or the retraction "un-retracts" and dumps a little extra. Enable coasting or reduce restart extra-extrusion, and turn on seam-hiding options like "align to shortest visible point" or randomized seam placement.

Clogged nozzle. Extrusion slows, stutters, or stops mid-print. Debris or degraded filament is partially or fully blocking the nozzle. Perform a cold pull, check for heat creep (a fan or duct problem on the heatsink, where filament softens above the melt zone and jams), and store filament in a dry box if this keeps recurring. Moisture is the most common repeat cause by a wide margin.

Three causes underneath most of those ten

Read that list again and the symptoms collapse:

Geometry. The nozzle or bed is not where the firmware believes it is.
Temperature. Wrong for the material, or wrong for this specific part's geometry.
Airflow. Cooling mismatched to print speed.

Layer shifting and clogs are the exceptions, and they're really a fourth category: the machine has physically drifted out of the state its configuration assumes. Which is the point of the maintenance section further down.

If you're staring at a failure you can't name, guessing at the category is a better first move than guessing at the setting. Three options beat forty.

Change one thing

This is where the slow test cycle changes the strategy.

When each experiment costs you 20 minutes to 6 hours of wall clock, you cannot afford the software habit of changing four things and seeing what happens. If you drop the temperature, increase retraction and slow the print down in one go and the result is clean, you've learned nothing transferable and you're carrying two changes you didn't need.

Two things make this bearable:

Use a cheap reproduction. A 20mm calibration cube, a first-layer test patch, a retraction tower, a temperature tower. These are the minimal repro cases of the domain, and they cost minutes instead of hours. Fix it on the small thing, then print the real one.

Version your profile. Slicer profiles are mutable global state with no history. After six edits you cannot get back to the settings that were working last week, and the reason your printer "used to be fine" is sitting in a dialog you don't remember opening. Export the profile before you start changing it. Naming it something like pla-generic-known-good costs you five seconds and saves an evening.

Starting numbers for four materials

Every filament brand differs. Start in the middle of each range and adjust from there:

Material	Nozzle	Bed	Speed	Cooling fan
PLA	190–210°C	50–60°C	40–60 mm/s	High (80–100%)
PETG	230–250°C	70–80°C	30–50 mm/s	Low–medium (0–50%)
ABS / ASA	230–250°C	90–110°C, enclosed	30–50 mm/s	Low or off
TPU (flexible)	210–230°C	30–60°C	15–30 mm/s	Medium (30–60%)

Retraction splits by extruder type rather than by material: direct drive wants roughly 0.5–2 mm at 25–45 mm/s, Bowden wants 4–7 mm at 40–60 mm/s. Bowden setups need more because there's a length of PTFE tube between the motor and the melt zone absorbing the movement.

One rule of thumb worth having memorised: keep layer height under about 75% of your nozzle diameter. On a standard 0.4 mm nozzle that puts a practical ceiling around 0.3 mm for reliable layer bonding. Above that, the extruded line can't press properly into the one below it, and layer separation gets much more likely.

Most "mystery" failures are maintenance debt

A printer is a machine that slowly leaves the state its configuration assumes. Belts stretch. Nozzles wear their orifice wider. Rails collect dust. Frame screws back themselves out under vibration. Build surfaces accumulate finger oil.

None of that surfaces as an error. It surfaces as a profile that worked in March and doesn't in June. The settings didn't change. The machine did.

So "it used to work" is usually a maintenance question:

Every print — bed clean of dust, oil and fingerprints; filament path clear and the spool feeding freely
Weekly — check belt tension (a correctly tensioned belt should twang like a guitar string, not flop); wipe down linear rails or rods; look at the nozzle tip for debris buildup
Monthly — re-level the bed properly rather than spot-checking it; lubricate rods and rails per your printer's manual; check frame screws and fasteners for looseness
Quarterly, or every ~3 kg of filament — cold-pull the nozzle even if it isn't clogged; check PTFE tubing on Bowden setups for wear or gaps at the fittings; replace the nozzle if quality has been slowly degrading

Nozzle wear catches people out, because it's gradual and there's no day it breaks. Quality erodes until you're tuning settings to compensate for a worn orifice, which never quite works.

The checklist that prevents most of this

Before anything you actually care about:

Bed is clean and level
Correct filament profile loaded for the material actually on the spool
Filament is dry (no popping or hissing while extruding)
Nozzle and bed temperatures match the material
Z-offset confirmed on a test strip if the printer was recently moved or relevelled
Enough filament on the spool for the slicer's estimate
No obvious slicer warnings on the model (floating islands, non-manifold geometry)
You'll be around to look at it when the first layer finishes

That last item matters more than it sounds. A good first layer predicts a good print more reliably than any single setting in this post. Watch the first layer go down, then walk away.

One honest caveat

Treat the tables above as starting ranges. Filament brands vary enough that two spools of PLA can want a 15°C difference, and a printer with a worn nozzle or a soft PTFE tube will disagree with all of it. The method survives that; the numbers don't.

And know when to stop optimising. If the part is a bracket nobody will look at, spending an hour tuning retraction to avoid a 40-minute reprint is a bad trade. Add a brim, print it again, and go do something else.

Disclosure, in the open: I make reference guides, and the failure list and settings ranges above came out of one of mine. It's a 9-page PDF with the diagnostic flowchart, the ten failures, the material table and the maintenance schedule laid out for printing and keeping next to the machine, $7 here. Everything I'd actually reach for is in this post. The PDF is the version you can tape to a wall.

Scope, not effort: how engineer promotions actually get decided

GinoCorp Industries — Thu, 03 Sep 2026 03:38:14 +0000

Most engineers who stall at a level have the skill. What they don't have is anyone willing to explain the machine they're inside.

The explanation you get from your manager is partial by design. They know their part of the process and not the committee's, so what comes back is "keep doing what you're doing, you're close." Which is true, and useless, and then you're close again next cycle.

So here is the machine, reconstructed from what the four big companies publish, what their engineers write up afterward, and what levelling aggregators have pieced together. None of it is your company's internal doc. Check the specifics with your own manager.

The ladders don't line up

Stage	Google	Meta	Amazon	Microsoft	Apple	Typical YOE
Entry	L3	E3	L4 (SDE I)	59–60	ICT2	0–2
Mid	L4	E4	L5 (SDE II)	61–62	ICT3	2–5
Senior	L5	E5	L6 (SDE III)	63–64	ICT4	5–8+
Staff	L6	E6	L7 (Principal)	65–66	ICT5	8–12+
Senior staff	L7	E7	L8	67	ICT6	12+
Principal / Distinguished	L8–L9	E8–E9	L10	68–69	Distinguished	rare

Google's L5 is a senior engineer. Amazon's L5 is a mid-level SDE II. Recruiters map between them and the map is approximate, so the year ranges are typical rather than required.

Two things here matter more than the numbers.

The gap between adjacent levels is not constant. Entry to mid is mostly about becoming reliable. Mid to senior is about becoming independent. Then senior to staff, which is where the ladder stops behaving like a ladder: it's a change of job, and the things that earned you the last promotion only partly transfer.

And every company has a level it considers a perfectly good place to spend a career. Google's L5, Meta's E5, Amazon's SDE II or III depending on who you ask, Microsoft's 63 or 64. Below that level there is an expectation you keep climbing, and at some companies a clock. Above it, promotion is optional and much harder, and nobody will chase you about it.

What actually happens in the room

The four processes differ enough that optimizing for the wrong one wastes a year.

Google runs the most formal version. Your case is a packet: a self-assessment written against the level you're targeting, evidence (design docs, launches, metrics), and peer reviews from engineers you've worked with. A committee of senior engineers who have never worked with you reads packets in a batch and decides. Your manager nominates and advocates but doesn't sit on the committee for their own reports. Two consequences: peer feedback outweighs self-review, because committee members treat self-evaluations as unreliable; and the committee needs artefacts it can read, so a launch nobody wrote a design doc for is a weak exhibit.

Meta decides inside the Performance Summary Cycle, twice a year. Self-review, peer reviews, a manager assessment calibrated against other managers. There's no separate application; promotion is one of the outcomes that cycle can produce. The practical consequence is that your evidence has to be legible every six months. A brilliant two-year project with nothing to show at the twelve-month mark is a liability in this system. Break work into visible halves.

Amazon promotes on a written narrative, the promo doc, structured around the Leadership Principles and reviewed by bar raisers: senior engineers from outside your team, explicitly there to stop promotions that would lower the bar. Two things people learn the hard way: recency counts against you, because rejected cases routinely cite "the project is too new, we haven't seen the results yet"; and visibility is treated as part of the work rather than a bonus on top of it.

Microsoft uses Connect, a periodic written record of priorities and impact, with promotions decided by managers in calibration. Its impact model scores three things separately: your own accomplishments, how you built on others' work, and how you contributed to others' success. That model exists specifically to break a culture of competing fiefdoms, and it means an engineer who ships a great feature alone can score below one who ships a slightly smaller feature and unblocks two other teams.

All four are measuring the same thing

Strip the vocabulary away and every ladder is asking how much of the world gets better because you're in it, and how reliably. Tasks, then problems and a team, then sustained impact on an organization. The word "sustained" is doing real work in that sentence.

Once you have that, a lot of confusing feedback becomes readable:

"You need more scope" means the problems you solve are chosen for you and bounded by your team.
"We need to see it sustained" means you did one next-level thing and the committee wants to know it wasn't a fluke or a favour from your manager.
"You're doing great work, but…" almost always means the work is invisible outside your team, or it's the same size of work you were doing last year, done better.

That last one is the trap. The most common way strong engineers stall is by doing more of whatever got them to their current level. If you were promoted to mid-level for shipping features quickly and cleanly, shipping features even more quickly and cleanly does not get you to senior. Senior is a different shape of contribution: choosing which features, owning the outcome when they meet reality, making the people around you faster. What has to change is the shape of the work. More of it just earns you the same review again.

The other half of it is that promotion is a lagging indicator. Google's "two quarters at the next level," Amazon's "consistently exceeded," Meta's "sustained" are the same requirement in different words. The committee is not betting on your potential. It is confirming a fact.

Which inverts how most people plan. The question is not "what do I need to do to get promoted." It's "what does a person at the next level do all day, and how soon can I start doing it." Once you can answer that, the promotion is paperwork.

Six ways good engineers stall

Almost every stalled promotion is one or two of these. Be honest about which one is yours before you do anything else.

Same-shape work. You're doing more of what got you here.
Invisible impact. The work is real, but there's no design doc, no metrics, and nobody outside the team can describe it.
No sponsor. Your manager likes you, but nobody with power is spending their credibility on you.
Glue without credit. You hold the team together and get thanked, not promoted.
Not enough time on the evidence. The next-level work started three months ago and the results haven't landed.
Wrong team or wrong manager. There is no next-level work available where you sit, or your manager can't or won't make the case.

Number four deserves its own note, because it's the one nobody warns you about. Tanya Reilly's talk "Being Glue" describes the work that keeps a team functioning and that no ladder is written in terms of: onboarding people, updating the roadmap, coordinating across teams, noticing the dropped task and picking it up. Reilly cites research finding that women volunteer for this non-promotable work substantially more often than men and are asked to do it more often, but the trap catches anyone conscientious. Her line is the one to memorize: if you only do glue, you will only get better at glue.

So: name it to your manager, with hours attached, because most managers genuinely don't know. Get it written into the case under some legible label, "technical program leadership" or "team enablement" or whatever your ladder will accept. And if promotion stays blocked anyway, shift deliberately to quantifiable technical work for a while. That feels unfair. It's also the move that works.

Two habits that fix most of it

Most of the invisibility failure mode is solved by one ten-minute habit: a written update to your manager every Friday.

Shipped / decided:  One to three things that are done. With a number where possible.
In progress:        What's moving, and whether it's on track. Yes/no. If no, why and what you're doing.
Blocked / need:     What you need, as a request with a deadline. "Need a decision on X by
                    Thursday or we slip a week."
Helped:             Who you unblocked, reviewed for, or taught. This is the line most people
                    skip and the one that builds a senior case.
Next week:          The one outcome.

Keep every one of them. They are the raw material for your promotion packet, and they mean the person who has to advocate for you already has the information before they need to ask for it.

The second habit is how you write anything up. Committees believe numbers and distrust adjectives, so every project entry goes in a fixed shape: scope, then what you specifically did, then what changed and what happened afterward.

Weak: "Led the migration of the billing service to the new platform."

Strong: "Owned the migration of the billing service (12M requests/day, 4 dependent teams) to the shared platform: wrote the design doc, negotiated the API contract with Payments, ran the dual-write cutover with zero customer-visible errors. Result: p99 latency down 61%, two on-call pages per week eliminated, and the pattern was adopted by two other teams the following quarter."

The "what happened afterward" clause is the one people leave out, and it's exactly what Amazon means by "too recent." If you can't fill it in yet, the project isn't ready to be an exhibit. Plan so that it will be.

Where to find numbers when you think you don't have any: dashboards (latency, error rates, throughput, cost), ticket systems (pages, incidents, time to resolve), adoption (teams using the thing, engineers unblocked), time saved with the arithmetic shown, and failing all that, before-and-after descriptions from the people affected, quoted.

The conversation, and when to have it

Most engineers have the promotion conversation too late, too vaguely, or not at all. The right time is nine to twelve months before you expect the promotion, and the right shape is a request for a plan rather than a request for a title.

Open it something like: "My goal is to be operating at [level] and to be put up for it in roughly [timeframe]. Here's a self-assessment against the ladder and where I think the gaps are. I'd like your honest read, and then I'd like us to agree on what 'ready' looks like — which projects, what evidence, what you'd need to see."

Then ask three questions and write down the answers.

"What would you need to see to put me up for this?" Push for specifics. "More scope" is not an answer. "Own the X project end to end and get it adopted by Y team" is.
"What is the biggest gap you see?" Listen. Don't argue in the moment. This is the most valuable sentence you'll hear all year.
"Is there next-level work available on this team in the next year?" If the honest answer is no, that is a different problem and no amount of effort fixes it.

Follow up in writing the same day: "thanks for the conversation, here's what I heard we agreed." A manager who has agreed in writing to a plan finds it awkward not to follow through. Then put it on the agenda monthly.

When the answer is no

Most engineers get told "not yet" at least once, and what you do in the following month matters more than the no itself.

Get the feedback in writing and specific. "Needs more scope" has to be translated into "needs to own a project like X." If your manager can't do that translation, ask them to get it from the calibration.

Then sort the reason, because there are only three. The work wasn't there, which a better project fixes. The evidence wasn't there, which documentation and better-chosen reviewers fix. Or the sponsor wasn't there, which is fixable slowly, and sometimes only by changing teams.

Set a date: "if I do X and Y, will you put me up next cycle?" In writing.

And whatever you decide, don't go quiet. A denied promotion followed by six months of head-down work and no conversation is the most common way a fixable "not yet" turns into a permanent no.

One honest caveat

Staff is a different profession. The clearest signal of that is how the time gets spent: survey-based descriptions of staff-plus roles put coding at roughly a fifth of the week. The rest is writing, reviewing, aligning, deciding, and teaching.

Charity Majors' argument that management is a change of profession rather than a promotion applies to the staff track too. So if you'd rather spend your week inside a codebase than inside other people's decisions, that's worth finding out before you spend a year building a case rather than after. The ladder above senior really is optional at every company in the table above.

The useful test is one week, honestly reviewed: how did you feel at the end of a week where you wrote almost no code and three other people made progress they wouldn't have made without you? If that felt like a good week, the rest of this is worth doing. If it felt like a wasted one, get very good at senior and let someone else have the packet.

Disclosure, since it should be out in the open: I make career toolkits for engineers, and the frameworks above are pulled from one of them, a $12 PDF on how promotion works at the big four. Flagging where this came from because it's mine and it would be odd not to. Everything useful in this post is in the post.

Nine categories: how engineering manager interviews actually get scored

GinoCorp Industries — Thu, 03 Sep 2026 03:28:04 +0000

Most EM interview prep fails the same way. You pick three strong stories, polish them until they're tight, run them past a friend, and walk in confident. Then somebody asks how you'd handle a high performer who's difficult to work with, and none of your three stories touch it.

That isn't a depth problem. It's a coverage problem, and it's the thing that makes the EM loop different from every IC loop you've done.

An IC loop samples from a narrow surface. Systems, code, a couple of behavioural questions that mostly serve as tiebreakers. You can prepare for it by going deep on a small number of technical narratives.

An EM loop samples from a wide one. Nine areas, roughly, and you can be excellent at seven of them and still lose the loop on the two you never thought about.

The nine areas

Team building and hiring
Performance management and difficult conversations
Conflict and difficult relationships
Delivery, prioritization and ambiguity
Cross-functional partnership
Growth, coaching and career development
Technical judgment and architecture
Values, culture and self-awareness
Vision and scaling

Look at that list and be honest about which two are thin for you. For most people coming from a senior IC role it's 2 and 3, because those are the parts of the job you've watched from the outside rather than done.

What the questions are actually checking

Underneath the surface wording, almost every behavioural question in an EM loop is checking one of four things.

Did you run a real process, or improvise? "I had a conversation with them" is an improvisation. "I named the specific pattern with dates, we agreed a 30-day plan, I checked in weekly" is a process.

Can you name a specific tradeoff you made, and why? Not that tradeoffs existed. Which one you picked, what it cost, and what you got.

Do you own outcomes without deflecting or over-apologizing? Both failure modes read badly. Blaming the org is worse, but flagellating yourself for four minutes over a bad hire is not much better.

Do you know which decisions were yours? This is where most candidates lose, and it's subtle. The story is real, the outcome is good, and the candidate narrates it as something the team did. If an interviewer can't find you inside your own story, they can't score you.

That last one has a practical use. When a question catches you off guard, don't stall. Answer the underlying one.

Build an inventory, not a script

The fix for a coverage problem is coverage.

Before you rehearse anything, write down eight to twelve real situations from the last two years. A hire that didn't work out. A project you cut scope on. A person you grew. An incident you ran and wrote up. A disagreement with your own manager that you lost.

Then go category by category and mark which of your situations covers it. Most of those 60-odd possible questions are answered by re-cutting one of your situations for a different angle, so the list fills up faster than you'd think.

The empty cells are the entire point of the exercise. Those are the questions that will catch you, and now you know which ones they are before you're in the room instead of after.

Then say each story out loud. Once. Not written, not memorized. The specific failure mode in an interview is rambling for four minutes on a question you know well, and you will not catch that by reading. You catch it by hearing yourself.

The shape of an answer

Ninety seconds, plus a hook.

Situation and stakes, briefly
What you specifically did
What happened, with a timeline or a number if you have one
One line on what you'd do differently

That last line is doing more work than the other three. It's the clearest thing separating a senior answer from a junior one, because it's evidence you've thought about the decision since rather than just filed the outcome away as a win.

An underperformer answer that ends "and by day 30 they were back to normal pace" is fine. One that ends "the thing I'd do differently: I let six weeks run before the direct conversation because I didn't want to look like I was jumping to conclusions, and I've since moved to checking in on delivery patterns closer to the two-to-three week mark" is a different candidate.

One more thing on wording: specificity beats sentiment, every time. Name the actual mechanism. A documented plan, a defined timeline, specific check-ins. Every candidate says they believe in giving people a fair chance, so saying it tells the interviewer nothing about you.

The case study round is testing something else

Some loops include a scenario round, sometimes as a discussion, sometimes as a role-play with the interviewer playing a team member. That round scores real-time judgment rather than a rehearsed story, which is why prepping for it feels impossible and mostly isn't.

The most common way to lose points here is jumping straight to a plan. It feels decisive. It reads as someone who doesn't ask questions before committing, which is a genuinely bad trait in a manager.

A structure that works on any prompt in this round:

Clarify. Ask two or three questions before proposing anything.
State your framework or priority order explicitly, out loud.
Walk through concrete first steps.
Name what you'd watch or check in on afterward.

Take "you inherit a team with high attrition and low morale, what are your first 30 days?" A weak answer announces changes. A strong one starts with 1:1 listening, not a survey and not a deck, works out whether the root cause is the work, the leadership, comp, or something structural, and picks one small visible fix in the first couple of weeks to buy trust before attempting anything bigger.

People who run these loops say much the same thing: candidates who clarify before answering score higher than candidates who answer instantly, even when the two eventually land in the same place.

The round nobody preps for

If the loop has an executive or skip-level stage, it's usually evaluating one thing. Would I trust this person to represent engineering in a room I'm not in?

Practical prep: be able to explain your team's work and its business impact, with no jargon, in under two minutes. If you tend to over-explain technical detail when you're nervous, this is the round to rehearse trimming, and it's a different muscle from everything else in the loop.

Reference checks are worth a mention too, because at EM level they tend to go past "would you rehire." Expect questions about how you handled a specific hard conversation and how your reports would describe your style. Tell each reference what the role actually emphasizes so their answer is specific rather than generic. Ask permission first, obviously.

One honest caveat

Management is not a promotion. It's a different job, with a different skill set and a different definition of a good day, and at most large companies the compensation bands run parallel rather than upward. Charity Majors' argument about the engineer/manager pendulum is worth reading in full before you commit to this track.

The test I'd offer: picture a day where you wrote no code, and three people on your team made progress they wouldn't have made without you. Was that a good day or a wasted one?

If it was wasted, stay on the IC track and go after tech lead or architect instead. A lot of the prep above still applies. The difference is you'd be answering the same questions about influence without authority rather than about headcount.

Disclosure so it's out in the open: I make career toolkits for engineers, and I pulled the categories and the answer structure above out of one of them. The full list of 62 EM interview questions, organized the way I've described, is a free PDF here. No email required. Everything useful in this post is in the post; the PDF is just the checklist version.