1. Recruiter screening: Went over standard things such as the company's background, salary expectations, and the process. 2. Meeting with engineering manager: Casual conversation going over my background, what the team/company does, tech stack, etc. 3. System design interview: Standard 45/15 minute split of the interview then Q&A. 4. Coding interview (Leetcode style): Again, standard 45/15 minute split. The company itself looks like it has a great engineering culture. All the meetings/interviews up until the coding interview were positive but that one alone made the experience negative overall. First was the actual coding environment. 2 minutes before the interview start time, the interviewer sent a link to a shared coding space for a platform I've never used before (some Leetcode/Hackerrank clone), This wasn't shared in the emails leading up the interview and it ate up some 5 minutes just figuring out where things are in the UI. For the actual interview: It's standard and can be considered the "norm" to have the candidate "lead" the interview since it's a way to see their thought process and problem solving skills. The interviewer's job is to give small nudges/hints where applicable and be ready to converse about a statement or question the candidate has. This was not the case with this interviewer. Starting the actual problem, I read the problem several times, asked clarifying questions, and laid out my thought process for the general algorithm which involved recursion (this comes up later). They disregarded it and just told me to implement the base case. I would understand them telling me to rethink my approach at a certain part if I misunderstood a part of the problem and my approach had a flaw, or was going in the wrong direction but them doing neither isn't how an interviewer should be conducting an interview. I implemented the base case and verified it was working with simple tests and print statements. Which also ate up ~5 minutes since the UI for this coding platform had some buttons overlapping with each other so when I clicked 'run', it was actually pressing another button to preserve the previous output. This was not clear from the UI and caused me to spend more time debugging something that was already working. They signed off on it verbally and I moved on with the problem. I reiterated my original approach to them. They visibly looked confused but told me to proceed. This spiked my anxiety. It strongly suggested to me that I've been thinking about the problem incorrectly the whole time even though I laid it out for them at the beginning. Nevertheless, I continued on. With about 20 minutes left in the interview, I get the recursive stack calls working but have small bugs/edge cases to account for. This is when the interviewer chimes in and says "this is why beginners shouldn't use recursion". The comment caught me off guard. They then go into how they're an industry veteran and after "years and years" of experience, it clicked for them but that I should take a step back and relearn the fundamentals. A part of me wants to believe the comment was made in good faith and is meant to serve as advice from a "veteran" in the industry to an early-mid career engineer like me. But it was insulting, rude, and absolutely unnecessary. It distracted me the rest of the interview and I couldn't collect my thoughts properly. I ended up not finishing the problem all the way. Got about 2/3 of it done. In the short post-mortem after, they stated I should've taken a wholly different approach since, once again reiterating how much of a beginner I am, I shouldn't have used recursion. The interviewer then laid out, verbally, the pseudocode of what they were expecting/wanting me to do which involved backtracking. All of their previous gestures, facial expressions, and short responses made sense to me afterwards. They conducted the interview with the expectation that I solve the problem the way they themself would've. For some context, I looked into this problem after the interview and saw that the problem can be solved 1 of 3 ways: recursively, iteratively, or by using backtracking. To me, the recursive solution is what made the most sense to me and I hadn't even thought about the other two. I understand that there are solutions that are more intuitive to others. It's the interviewer's job to remove their own biases and help guide the candidate. Some feedback/suggestions for Flex if they look at this review: 1. A "rockstar" engineer does not make a "rockstar" interviewer. Candidates are extremely anxious and nervous going into and throughout the interview. Interviewers should be aware of this and make a conscious effort to ease a candidate's nerves. 2. If an interview is going to use a specific platform, explicitly mention it to the candidates ahead of time via the interview scheduling confirmation so they can get familiar with it ahead of time, not 2 minutes before the interview start time.