## How to Prepare All Five Answers A trading-firm SWE behavioral round is short and high-signal. Across the five questions the panel is screening for four things at once: - **Genuine, job-specific motivation** — can you explain why *software engineering at a market maker* (low-latency, correctness-critical, real-time) excites you, beyond "I want a hard, prestigious internship"? - **Self-awareness and coachability** — the environment is intense and feedback is blunt; they want someone who seeks feedback, owns mistakes, and improves fast. - **Evidence over adjectives** — every claim is backed by a concrete project, internship, class, or competition with a real outcome. - **Fit for the floor** — calm under pressure, direct communication, intellectual honesty, and the ability to say "I don't know" without bluffing. A reliable template for almost every answer below is **claim → concrete example → outcome → link back to the role.** Keep most answers to **60–90 seconds**: lead with the headline, then prove it. STAR (Situation/Task/Action/Result) or CARL (Context/Action/Result/Learning) are good skeletons for the example portion. > **Honesty note:** The examples below are placeholders (shown as `___`). Fill them with *your own* real projects. Never fabricate finance experience or metrics — interviewers at trading firms probe specifics hard, and a fabricated number is a fast rejection. If you have no finance background, say so and pivot to curiosity plus demonstrated learning speed. --- ### 1) "Why software engineering?" Avoid the generic "I love coding." Tie your motivation to the *kind* of engineering this job demands: building reliable systems, reasoning about performance, and getting fast, measurable feedback. **Structure — what draws you → a proof point → why it fits here:** - **What draws you:** "I like turning ambiguous problems into systems that are correct *and* fast, and I get energy from the tight loop of measuring, changing one thing, then measuring again." - **Proof point (one real project):** "In `___` I `___`. For example, I profiled a hot path, found `___` was the bottleneck, and restructured it so `___`. That cut runtime/latency from `___` to `___`." (Use a real before/after; if you don't have a latency number, describe the qualitative improvement honestly.) - **Why it fits:** "Software is where I can see a clear line from a design decision to a measurable result — exactly the work I want to do more of." **Pitfalls:** "I enjoy coding" with no impact; listing technologies as a personality ("I'm a Python person"); claimed passion with zero evidence. --- ### 2) "Why this firm (an Optiver-like market maker)?" This is the highest-stakes question because it's the easiest to fake badly. A strong answer connects **what you're good at** to **what makes engineering at a market maker distinctive**, and shows you've actually thought about *how the firm makes money.* Use the swap test: if the answer would fit any FAANG application unchanged, it's too generic. **What's genuinely distinctive about SWE at a market maker** (use two or three, don't list all): - **Engineering quality is the edge, not a cost center.** Latency, throughput, reliability, and correctness directly determine execution quality and P&L. A microsecond — or a single off-by-one in pricing — has real consequences. Few places couple code quality this tightly to outcomes. - **Brutally fast feedback.** Markets give a verdict every day; you ship, measure, and iterate continuously rather than guessing. - **Deep, low-level technical problems.** Networking and TCP/IP, kernel-bypass and NIC behavior, CPU caches and memory layout, concurrency and lock-free data structures, deterministic latency, and serious observability — systems engineering at the limit. - **Small teams, high ownership.** Engineers own systems end to end and are trusted early, internships included. **Template:** - "I want to work somewhere engineering quality *is* the product. At a market maker, the gap between a fast, correct system and one that's slightly off shows up directly in execution — which is rare and motivating." - "I'm specifically drawn to the low-latency systems problems, such as `___` (for example networking, profiling, or concurrency), and I've already started down that path: `___`." - "I also like that markets give an honest, fast scorecard. I'd rather get a real result every day than wait quarters to know whether a decision was right." **On Optiver specifically (if interviewing there):** it's a market-making firm that provides liquidity across multiple asset classes and trading venues, headquartered in Amsterdam with offices internationally, and known for treating technology as core to the business with close collaboration between traders and engineers. Any one of those is an accurate anchor for *why this firm* rather than recited marketing. Pick the one that genuinely connects to you, state it in a sentence, and move on — depth on one true thing beats a wall of buzzwords. Don't claim figures or internal details you can't verify. **Pitfalls:** talking only about compensation; "great culture" with no definition; claiming finance expertise you don't have; an answer that would fit any tech company equally well. --- ### 3) "What are your interests — technical and/or markets?" Aim for **one technical interest plus one markets/domain interest**, each with a sign of genuine engagement (something you built, read, or experimented with). Stay humble on the domain side if you're new to it. **Technical (pick what's real for you):** performance engineering and profiling, networking / TCP/IP, distributed and real-time systems, concurrency and lock-free programming, C++ or Rust, Linux internals, observability and debugging tooling. **Markets / domain (keep it honest):** order books and market-microstructure basics, auctions and price formation, the difference between a market maker and a directional trader, why latency matters for liquidity provision. It's fine to say you're early in learning this. **Template:** - "Technically I'm into `___`. Recently I `___` — for instance I built `___` / dug into `___` to understand `___`." - "On the markets side I'm genuinely curious but still early. I've been reading about `___` and built a tiny `___` (e.g. a toy order-book matcher or a latency micro-benchmark) to make the concepts concrete rather than abstract." **Why a small self-driven artifact helps:** building a toy order book, a market-data parser, or a latency benchmark — even a rough one — is strong evidence of curiosity that converts vague interest into a credible signal. Mention it only if you actually did it. **Pitfall:** overclaiming domain expertise. "I follow markets closely" invites follow-ups that expose shallow knowledge. Curiosity plus one concrete thing you tried is safer and more credible than confident overstatement. --- ### 4) "What's your biggest weakness?" Pick a **real** weakness that is (a) not a core disqualifier for the job, (b) something you've actively worked to improve, and (c) demonstrated with a specific example and a concrete fix. The point isn't the weakness — it's showing self-awareness and a working improvement loop. **Avoid two failure modes:** - The humblebrag ("I'm a perfectionist," "I work too hard") — read as evasive. - A genuine disqualifier for trading SWE: "I'm careless with details," "I get rattled under pressure," "I don't like fast-changing requirements." Those map directly onto things this job requires. **Structure — weakness → concrete impact → what you changed → evidence it worked:** - **Weakness:** "I used to over-invest in polishing a component before the overall thing worked end to end." - **Impact:** "On `___`, that meant I had a beautifully tuned module but slipped the deadline because the full pipeline wasn't connected yet." - **Fix:** "I changed my approach: get a correct baseline working end to end first, *then* profile to find where optimization actually pays off, and timebox that work. I now hold myself to a 'make it work, then make it fast' rule." - **Evidence:** "On the next project I had a working baseline in `___` days, then measured and improved the real hotspot (`___`), and hit the deadline." **Other defensible weaknesses** (choose one that's true, each paired with a concrete fix): asking for help later than you should → learning to flag blockers earlier; being quiet in group discussions → deliberately practicing speaking up; spending too long reading code before asking the one clarifying question that would have saved an hour. --- ### 5) "How would people you've worked with describe you?" Pick **three traits**, ideally ones that matter on a trading floor, and back **each** with one line of evidence. Traits without evidence are just adjectives. **Trait menu (choose three you can prove):** - **Reliable / high ownership:** closes loops, communicates status early, doesn't drop things. - **Calm and methodical under pressure:** good at debugging incidents and isolating root cause instead of flailing. - **Direct and intellectually honest:** asks the clarifying question, says "I don't know" when true, surfaces problems early instead of hiding them. - **Collaborative:** writes clear docs/tests, gives useful code-review feedback, makes teammates faster. **Template:** - "They'd probably say I'm reliable, methodical when things break, and direct." - "For reliable: on `___` I `___` and kept the team updated when `___` slipped, so there were no surprises." - "For methodical: when `___` broke, I reproduced it, bisected it, and found the root cause was `___`, instead of guessing." - "For direct: in `___` I flagged early that `___` wasn't going to work, which let us change course before it cost time." **Pro move:** if you've genuinely received this feedback, attribute it ("My team lead's review specifically called out that I…"). Real, attributed feedback is more credible than self-assessment — but only use it if it's true. **Pitfall:** listing aspirational traits you can't back up, or traits ("creative," "visionary") that don't match what the job rewards (rigor, ownership, honesty). --- ### Delivery Checklist (applies to all five) - **60–90 seconds each.** Lead with the headline, then the example. Don't ramble. - **One concrete example per answer**, drawn from a real project, internship, class, or competition. Specifics beat polish. - **Quantify honestly** when you can (latency, percentage, time saved); stay qualitative when you don't have a real number rather than inventing one. - **It's fine to say "I don't know."** Intellectual honesty is a strength here; bluffing is a red flag. If asked something you haven't considered, reason aloud about how you'd find out. - **Stay consistent across rounds.** This process runs two behavioral rounds bracketing the technical/system-design rounds. The same interests and self-description should appear in both; contradictions stand out. - **Close forward-looking:** "That's why I'm excited about building low-latency, correct systems in an environment where engineering quality directly drives the result." --- ### Addressing the Follow-up Questions - **"Tell me about a time you received tough/blunt feedback."** Use CARL: state the context, the blunt feedback verbatim, the *specific* change you made, and the measurable improvement. The signal is coachability — do not get defensive in the retelling, and end on what you do differently now. - **"Describe a bug/incident you debugged under time pressure."** Show a methodical loop: reproduce → narrow scope (bisect, binary-search the input, add logging/asserts) → form and test a hypothesis → root cause → fix → guard against regression. Emphasize staying calm and isolating cause rather than guessing — exactly the on-floor trait they screen for. - **"What would you build or measure first to learn where latency goes?"** Establish a baseline measurement before optimizing: profile end to end, instrument the hot path with timers/`perf`/flame graphs, and find the actual bottleneck instead of guessing. Mention measuring *tail* latency (p99/p99.9), not just the mean, since deterministic worst-case latency is what matters for a market maker. Change one thing, re-measure. - **"If you didn't get this internship, what would you do to be a stronger candidate next cycle?"** Give a concrete, humble plan: a specific systems skill to deepen (e.g. a low-latency side project, a networking or concurrency deep-dive), more deliberate practice on the question type you found hardest in this loop, and reapplying with stronger evidence. This signals growth mindset and genuine interest beyond a single attempt.