You can get every question right and still be wrong. 2024-03-19 I had an onsite interview with Jane Street (proprietary trading firm) in Hong Kong for a Software Engineering internship last week. A unique experience for my first ever interview. It was a long flight back, so allow me to share some reflections and review key mistakes. The most important step in problem solving is to always be skeptical of your own assumptions. The second most important step is to continuously re-evaluate those assumptions under the presence of new information. I made flawed assumptions about the important skills of being a Software Engineer, and how these skills are measured by proxy through the interviewing process. Following the conventional advice, I practiced coding interview questions until I was comfortable solving Leetcode Medium and Hard. For every question I solved, I would explain my thought process in detail out loud, go through examples and analyse the time complexity of my approach. I focused on improving the readability and idiomaticity of my code, and made sure to commentate every line as I was writing it. I did mock interviews with my friends and seniors, practicing time management and collaboratively working with the interviewer. I chased up previous internship applicants, both successful and unsuccessful, and asked them to share their experiences and learnings. Despite assurances that low-level knowledge was unnecessary, I studied cache efficient algorithms and memory hierarchy latencies, SIMD vectorization, kernel preemption, virtual memory mapping, branch prediction, memory allocation strategies, multithreading and NUMA, performance measurement and micro-optimization techniques, kernel-passthrough networking approaches, interrupt handling and DMA between the Memory Controller Hub and IO Controller Hub, page tables and the TLB cache, IO access patterns, GPU warp scheduling as well as latency hiding and memory tiers, and so on and so forth. Just in case. My thoughts became tunnelvisioned on efficient algorithm design, finding solutions quickly, communicating my thought process clearly, readable and maintainable code, finding examples and asking clarifying questions to be on the same page as the interviewer as quickly as possible. All of those things are of course important, and are valuable proxy measures for the interviewer to evaluate your skills, but you should never confuse the map for the territory. -** In the process, I missed something important, explaining the range of possible "correct" solutions and "incorrect solutions", contrasting why you believe some solutions are more correct within the problem constraints than others and comparing the tradeoffs between various solutions (ie. efficiency, readability, maintainability, flexibility) - shows a deep understanding of the problem space and solution space and demonstrates communication skills -** it gets at something fundamental - the crux of effective communication is not to project your own idea and thought process onto others, it is to build connection points for other people to link and contribute their own thought processes and ideas into so that the output of the collaborative process reflects the sum of the team members abilities, not the abilities of its loudest or strongest member. You build these connection points by aligning everyone to a common understanding of the design space which spans the entire range of possible solutions (both good and bad), and facilitating a discussion comparing the associated design tradeoffs and constraints. It provides an easy way for a team member to jump into the discussion no matter which solution type came to their mind first, and creates a multiplier effect on productivity. ** every technical interview is also a behavioural interview: ideally, you should relate your technical judgement and tradeoffs to your past experiences VVVVVV stuff abt learning from your own mistakes, others mistakes, misconceptions - the difference between knowledge and experience learning from others: behavioural - situational vs behavioural: relating based on your own experiences, not placing yourself into a hypothetical situation - thinking about how to approach future system design or behavioural questions - leadership vs management: direction setting vs structuring - how organisational risk aversion influences promotions and hiring - rejecting hyperbolic discounting - mistaking large impact for value creation: demonstrate wins over average replacement not how important your role was - man in the hole story structure - communicating imperfect success and tradeoffs involved in your success is more important than pretending everything you ever did is perfect.