You are on a 20–30 minute recruiter (HR) phone screen for a Software Engineering Intern position at Optiver, a high-frequency trading firm. The call skips the usual "tell me about yourself" opener: after a few logistics questions (your graduation month/year and whether you will need visa sponsorship), the recruiter moves straight into a project deep dive. Everything that follows is driven by one project you choose to talk about — the recruiter's follow-up questions are unscripted and based entirely on what you say. Work through the deep dive below as you would on the live call. ### Constraints & Assumptions - The interviewer is a recruiter, not an engineer: they are listening for clarity, ownership, and reflection, not implementation detail. Keep explanations high level and jargon-free. - The whole conversation fits in roughly 20–30 minutes, including logistics and your questions at the end — budget about 2–3 minutes for the initial project overview. - Follow-ups are reactive: whatever you mention (a technology, a teammate, a setback) is fair game for the next question, so only bring up things you can discuss confidently. - Assume you are a current student interviewing for a summer internship; class projects, internships, research, and substantial personal projects are all acceptable material. - The logistics questions (graduation timing, sponsorship) are screened honestly and factually; they are not part of the evaluated deep dive. ### Clarifying Questions to Ask - "Would you like a quick high-level summary first, or should I go into the details of my role right away?" - "Is it okay if I use a team project, as long as I focus on my own contribution?" - "How technical would you like me to get — should I keep it at the level of what the project did and why, or go deeper into how it worked?" - "Roughly how much time do we have for this part, so I can pace myself?" ### Part 1 "Give me an example of a project you've worked on — keep it high level. Start with what you did, and I'll ask questions from there." ```hint Choosing the project Pick the project where **you** made real decisions and hit real obstacles — not your most impressive-sounding one. The follow-ups all probe *your* role, so a project where you were peripheral collapses under the second question. ``` ```hint Structure of the overview Give a 60–90 second arc: the problem and who it was for, your specific role, what you built (one plain-language sentence per major piece), and the outcome. Deliberately leave one or two interesting threads (a hard bug, a design choice) dangling for the recruiter to pull on. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 2 "What were the most difficult parts of this project, and how did you solve them?" ```hint What counts as a good difficulty The strongest answers name a difficulty that was *genuinely uncertain at the time* — an ambiguous requirement, a performance wall, an integration that kept breaking — not routine work that just took long. Describe why it was hard *for you then*, not why it sounds hard. ``` ```hint Show the solving process Walk the recruiter through **how you attacked it**: what you tried first, how you narrowed the cause, who or what you consulted, and what finally worked. The reasoning process is the answer; the fix itself is one sentence. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 3 "If you went back and did this project again, what decisions would you make differently?" ```hint Real regret, not humble-brag Name an actual decision you would reverse — a library choice, skipping tests, wrong scope, building before validating — and tie it to a consequence you personally felt later. "I'd start earlier" or "I'd work even harder" signals no reflection at all. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 4 "What questions do you have for us?" ```hint Ask about the internship, not the brochure Ask things the recruiter can genuinely answer and that show you've thought about *doing the job*: how intern projects are scoped, what mentorship looks like, how interns get feedback, what distinguishes interns who get return offers. Avoid questions a search engine answers (what the company does) and topics premature for an HR screen (compensation, perks). ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - "You mentioned your teammate handled that component — so what exactly was *your* contribution there?" (a standard drill-down on Part 1 if ownership is vague) - "How did you know your fix in Part 2 actually worked? What would have happened if you hadn't caught it?" - "Was there a disagreement on the team about any of these decisions? How was it resolved?" - "Of the things you said you'd do differently, have you actually done any of them differently on a project since?"