Interviews

Total_lifetime_interview_counter: 4 leetcode style(poor comms, rough ideas only/lack implementation clarity) 2-3 open ended coding implementation design(poor trade off discussion, lack of problem expertise, lack of proper comms/being on same page, etc) 2 system architecture/infra design(insta-giga failed) 2 product thinking(ambiguous/can’t pinpoint what’s wrong) lowlight reels across dozens of interviews + takeaway: from product thinking, to systems design, to speed math puzzles, to trad. “canonical” go towards optimal soln, to open ended implementation— I compile my understandings of where I seem to fall short over the terms and why: speed math puzzle games:------------------------------------------------------------------------------------------ scrims and drills!! —anything more than 10 seconds w/ no intuition pop up, actually just go home, time to hit the pencil and papers. love when I watch vod reviews of IMO china kid answering faster than I read the question, oh I understand it now.. I think I understand it now… SIG, Akuna, Optiver, Arrowst, etc. trading questions remind me that, not everybody can be Lebron. some ppl will warm the bench. my favourite intro call was a trading desk in dubai, where the signal was so bad, audio straight from a fish tank and recruiter didn’t know what real traders do either. Just give up. maybe shoot again(no I think I won’t)--- but you rlly need sharp mental math. while you’re sleeping, oh yeah bang expected value. Oh yeah— ill just model the distribution and summon the EV up my asshole and to the left. Just another day, yeah. Here's an Optiver-like question, like start in the middle coord of the grid, outwards is 5 in either x,y direction, it's a total 10x10 grid and ur in the middle. You coin flip HH go north, HT, east, TT, south, TH west. What's expected num. Steps until you reach any border. And this kind of mental EV intuition within under sub15-30 seconds is desired. Ans: like roughly 29 I think, but without internet access— who is insta–writing out the multi-eq EV recurrence relationship, unrolling it in their head, and spit out the answer like…. Like sure, some of the EV problems are even highschool, but the questions can just get super creative and if you’re not fast as fuck w/out paper, and you’re unable to do computation all stored in your head simultaneously, its honestly so over for you. “canonical”/optimal exists:-------------------------------------------------------------------------------------- honestly just studying and seeing more code adjacent patterns will resolve this since, well bcuz it literally exists. If a lot of swe are capable of this, it's not medalist or olympic level(those soln don’t canonically exist)— its def doable/in scope just need to grind out if ur mentally average. Some questions I failed and why: Some (lets say no-name)SF company on __ safety/compliance, this position pays an absolutely unreasonable amount for an intern, basically like pushing FT numbers—yeah, so I don’t even deserve to pass this interview…. The question was about computing the total number of end-game scenarios within tic-tac-toe. Okay, don’t judge… but I'm very unfamiliar with dp tbf… Like—perhaps it wasn’t extremely difficult of a question–but the thing is—something that was already fatal was not clarifying enough what it exactly “means” by end-game-scenario. My interpretation for what the board “counts, or doesn’t count as end-game scenario” may or may not be what they meant, or including draws, or ties, stalemates, or other cases. They make questions ambiguous on purpose(no words on screen, just verbal/vague problems).... so you are actually forced to clarify until everyone in the interview is on the same page of what the direction should even be… I jumped into trying to explain how might the dp with memoization would happen, but I’m pretty sure it's already super big-red-flag to even discuss optimization(interview looked at me like im a giga-donkey-fish), without first walking through some simple ideas, cases, how to first construct the base-case, then further extend some more cases on how you would model the recursive problem. Like maybe the only thing I got correct here was knowing to model it as a 2D array and then something, something→ recursion. But my foundations with DFS here, and the ability to actually articular / basically role-play as the professor and “teach-me-like-im-five”...was lacking→and especially trying to solve anything without making sure the interview is actively engaged, on the same page, following your approach like an attentive student, etc. The fact the interviewer was not really fully engaged with me was also a red-flag. There's probably a million other red-flags in this interview, and perhaps all of my interviews for that matter— just a few I can think of. The Program also never ran, I couldn’t implement it in time, and I lacked the ability to demonstrate “art of problem solving” and just trying to type some boilerplate bullshit dp/dfs/recursive shit. product thinking/design discussion:----------------------------------------------------------------------------- Doable, but lots of practice needed and brush up on public speaking. extremely open ended—feels like a research case study presentation squeezed into being on the spot— but technical facing, and tbh rather ambiguous. The question will be some open-ended “okay this happened and we don’t know why, metrics, strategy, cases, estimation, constraints, product design, etc. go now clarify, analyze, and give me professional ted-talk about what's going on for 20 minutes” type business mechanical hooliganism. Okay like…off topic but…Tech consulting sometimes cannot actually be a real field—please go bash your head against a monitor reasoning about the kernel before discussing fake shareholder value and imaginary valuations—like some of these case studies you read into are unironically mapping a bijection between crayons and the underlying truth ...they r so “blue-pilled” pretenders…half of the articles on the internet written about the impact of ai in the “business world” is written by some absolute singled-celled-mouth-breathing-organism; one-full standard deviation leftwards on the aptitude-distribution— who cannot reason about the reality, the truth, or how things actually work….Everything they have ever seen in their life is a blackbox system… It’s like a dinosaur trying to observe a fucking cell-phone. Can someone please teach me where the first principles in case studies come from. Surely we’re not just buzzword key-spamming pretending like they’re fundamental truths about the universe. Surely the entire world is not just chasing fairytale dust equity illiquid numbers…oh wait it fucking is…. The corporate world makes me so sick to my stomach. The product design from a system-design level makes a lot more sense. Because you first need to know the architecture then reason and connect it to the business needs. I have yet to do that kind of interview format(I also cannot do infra-sys-design yet), but this should be how TPM interviews get conducted. Hopefully I get good at sys-design and eventually transition out from swe to tpm late-game in my career. I am not jane street. Nor am I Alan Turning– and neither is the reader. I wish I had feedback or could mock with Senior PMs who can genuinely roast my explanation. Perhaps my analysis sounds reasonable strictly in my pov, but is some garbage data to the interviewer. Or perhaps PM will die as an industry sooner or later and I won’t be prepping for case-study→ it will all converge to product-lead-system-design anyways…. Questions that are product-focuses are about knowing how metrics guide and shape the problem space. The interviewer will try to model your past experiences and grill you on the decision you made and why. If you can internalize / rationalize about case study like metrics and variables etc. But, In hindsight, I have no idea if I was supposed to approach the problem-space from a business lens or from a technical perspective. Because the technical product interview/what is desired elsewhere, is also completely different. The technical product is more like system-design, but then from the perspective of what the product is supposed to do, and what requirements would you outline from the user/client facing side. I think actually in my swe-sys-design interview, I ended up confusing with it the approach of product sys-design interviews— actually fucking fish. So fish. I’m Rookie asf. Software-sided sys-design is literally the pieces involved and configurations and trade-offs for the literal moving infrastructure, not the high-level idea of how you would design it. Although the interviewer did end up saying my problem-solving from the product side was reasonable, the question wanted to be solved from the infra-level, not high level, so we insta-failed. Immediately failed—didn’t even clarify from what lens/perspective to solve the problem from, and assumed an approach, instead of confirming with the interviewer from what level of abstraction should we even talk about the problem…. For example, the interviewer basically ended up telling me the answer we were looking for had to do something with the load balancer and modelling the db..etc. Like def need more intuition for solving infra-level problems, but also I could barely understand the english being spoken under the accent—obviously very competent, but I can barely understand the audio transmitted. It also feels quite open-ended. Like there could be many things in a infra system-design interview, and if you are not on the same page with the interviewer about what there is to talk about, you could just be going into the wrong direction–say some good stuff—but the interview claims it is all irrelevant garbage and not “the type of answer/conversation topics” we were looking for. Finally: swe_style_system_design:------------------------------------------------------------------------------ very important overall. require breath and depth. don’t talk abt irrelevant shit within given scope, ensure interviewer is on the same page for the scope—>allow convo to naturally steer/smooth-mature into topics, instead of verbal keyword diarrhea. mapping out whole architecture end-to-end and knowing the tradeoffs is actually not deterministic or trivial.. it’s like an unsexy roleplay where you are socrates, and the interviewer is the student wishing to inquire about well what shall we do? feels like engineering british parliament debate over a to do list, except you are both the proposition and opposition at the table. open-ended/implementation heavy: ensure schema is approved by interviewer, reason about decisions verbally, try to map why this question is even being asked, or make predictions of natural follow ups. i recall being asked 3 consecutive why? abt my decision, I then froze like i was having a stroke—mumbling abt sum fake, oh yeah i think throwing uh sorted priority at this scenario would do something, not sure tho… At least I can say I’m grateful to be learning thru literal trial and error tho, now we know chat what to brush-up on. Rank Up to Silver! After dozens of games finally played this term, We finally hit silver in c++ interviews Silver players are theoretically capable of: Solving basic mini-design/algo problems through the language, reasoning about preliminary pros and cons w/ diff tradeoffs/strategies, have some intuition/in-game awareness of memory management, scale/abstraction, low-lvl ownership, etc…can model/map some degree of ambiguity through design infrastructure/system design, and can sort-of process and talk at same time. Next steps for the coming years…hitting Gold! Maturity and some trust with ownership of infrastructure. Intuition of correctness and level of scale in real systems…Understanding of system consequences: operational, scale, memory, etc. Ability to shape the problem space itself→ how designs/plans evolve over/under new constraints→ strong interpretations of vague requirements→ability to argue thru functional and non-functional requirements, etc. Platinum/senior rank: Judgement caller/expertise coaching. Can fully call the shots and can plan/design/map strategies for in-game architecture under tight timeline constraints… When/where to run what IGL strategies in real-world and why...Ability to articulate strong arguments about strategies. Game-sense about what actually matters or what doesn’t matter in real-world systems at scale. Clear structure and frameworking about real problems. . . Global Elite: Linus Torvalds, Donald Knuth, Alan Turning, Edsger Dijkstra, Judea Pearl, and many more.