Don't read too much into it. As an entry level applicant you're only getting a small fraction of anyone's attention and will need to apply Hanlon's razor to interpret most of your interactions.

(I'm sure they are some toxic interviewers and dysfunctional companies where that's not the case, but you don't want to work there anyway so it doesn't matter.)

A lot of good things flow from there.

First, you should feel a little more relaxed. This generally helps think more clearly, talk more naturally, avoid panicking, etc.

Second, you should shift your mindset to view your relationship with the interviewer as based on cooperation, not antagonism. This generally helps act more friendly and less defensive.

Third, if you were at home cooperating with a friend to solve a difficult problem, would you stay silent, or would you run your ideas off each other? Probably the latter. The same applies here. Unlike your friend, the interviewer is limited in how much information they can give. But again unlike your friend, the interviewer already knows exactly how to solve the problem! So leverage that. Ask them whether your proposed solution makes sense. Ask them whether the time and space complexities of your proposed solution are good enough or if you should keep digging. By the time you start implementing the solution in code, you should be fairly confident that you're going in the right direction. (Sometimes the interviewer won't give much away. Don't panic, it happens—in that case just go for it and hope for the best.)

I was super lucky to work with a gem of a recruiter at one of the FANGs who spontaneously pushed for 6 after my feedback from 5 came back positive. The other FANG was more reactive and didn't invite me back until I told them of the competing offer. So perhaps try pushing for it yourself if your recruiter is not as proactive and you feel you have a shot. Worst case they'll say no. (Or they'll say yes and you'll bomb the next round. That's not supposed to reflect negatively on your first round, although it would likely have affected me psychologically and made me less confident during the comp negotiation.)

I ended up joining a company without levels, so I'm afraid I don't have any more useful information for you than what I gleaned as a candidate.

I'm kind of convinced there is something else happening where the person writes down technical performance instead of, "didn't like his shoes" or whatever.

They keep pinging me every six months to re-interview too. They don't like to share why they declined though - so I don't get why they ask for me to reinterview like something magical will change without feedback.

Leetcode questions are not enough for 'seniors', even as a interviewer, it brings the same good problem solvers, but not enough applying this into practise such as open-source projects / contributions, which is faster to review than these Leetcode questions.

> It’s nice to glamourize it a bit but you guys make it sound downright mythical.

Perhaps not in 2012-2014 but in 2019 it is the reality of many candidates getting a FAANMG level role that have to face a competition of thousands of applications every week.

I wish it were easier than this, but when I look at the following real world open-source projects:

* FB creating the Hermes JS Engine.

* Netflix submitting patches to the Linux Kernel.

* Googlers working on Fuchsia OS.

* Apple hiring dynamic linker engineers for dyld3.

* Amazon writing the firecracker virtual machine.

* Microsoft hiring engineers for Typescript and Chromium.

I think that justifies utilising the data structures and algorithms resources listed above. And now if one told me that they have some contributions to at least one of them, I'd tell them to send a link to the code-review / patch and I'd just bring them onsite and ask more questions about it.

I'd suggest always working on paper or whiteboard - never use a computer. (You have to emulate the environment) Set a timer for every problem. (1 hour max - aim for 45 minutes on medium/hard when starting out; lower it as you familiarize yourself with a subject) Start throwing data structures and algorithms at the problem (pattern matching them, basically). Solve it or don't. Learn something to take away from it. If you don't solve it, learn how to solve it, and where you were lacking. If you did solve it, be sure to check other solutions because sometimes yours is crap. Practice that thing you were lacking. (Needed to know BFS? Implement BFS from scratch 10 times using spaced repetition) If you're planning on 8 hour study sessions then focus on one type of problem at a time. (BFS, DFS, graph problems, tree problems, binary search, dynamic programming, etc.) Only do those kinds of problems in that session. Set it up like you would for a math class. You do one chapter in that session/day/week/whatever and proceed to do a few chapters (say a BFS chapter, a DFS chapter, and a binary search chapter)... Once you've done a few, give yourself a midterm covering the topics you learned. So give yourself like 2 DFS, 2 BFS, and 2 binary search problems and see if you can solve them in a timed environment. If you rocked the midterm then proceed on to do more chapters and more midterms. If you didn't then relearn those subjects before moving on. Finally, when you feel like you've learned everything then give yourself a final exam to see if you remember everything and can still do it right.

Basically - treat it like a math class. It's not just memorization (you need to memorize the strategies, that's for sure - you need to be really fast at implementing BFS, DFS, binary search, etc. That should be wrote memorization but with a deep understanding).