Tech Interview Handbook

I do. I used to reject recruiter's advances the moment they described the interview process as a leetcode-hazing ritual (my words, not theirs), but as I've become even more grumpy/depressed over the poor state of things I might take it step further and start wasting their time (interviewing and then running the interviewers in circles for a while).

Disclaimer: Not who you are replying to.

For myself at least: absolutely yes. That's actually some of the first stuff they taught us. Would I want to be interviewed on whether I can implement a linked list from the top of my head in an arbitrary language and 100% correctly in a high stress interview situation? Absolutely not. (and a linked list in the end is something really really easy if you ask me)

Does that in any way relate to what I'm doing right now? A little! This will differ depending on who exactly you work for and in what role. It certainly helps to have learned this stuff. I can honestly say that it was fun seeing how regular expressions actually work, how you implement a parser for it etc. But then you learn as well (right there in university) that you better use a parser generator after just having defined the grammar instead of writing it yourself. How many jobs are out there that require you to write a grammar for something? To create a new language? Very very few. There's a market for "boring business software X" software developers.

Is it the most important thing I consider when hiring? Absolutely not. We also don't pay FAANG salaries where I work. Do I want capable software developers? Smart guys for sure. People that are curious, willing and able to learn, writing maintainable code. Guys that if I tell them that there's a hidden n^3 algorithm in what they just wrote and it _does_ matter for the (relatively small but large enough) volumes of data this will run on can look up/ask for what that means.

EDIT: interesting down votes. I hope someone will reply to explain. I certainly don't see why we can't have a civil discussion especially given that we seem to agree on it having been good to get a solid university education. FWIW I have a Master's in Computer Science. From a country that values non university education (Germany - where you can do vocational training to become a programmer. Just like you can become a master carpenter through that system).

to prime your biases for when you watch them endure your company's contrived tests

Forget the Hunger Games, here is the dystopian shit right now:

For a medium level leetcode problem here is the time split (for which 20 min are given typically):

1. 4 min => Read/interpret/parse the problem statement

2. 5 min => Formulate the solution.

3. 8 min => Actual code

4. 3 min => Edge cases/review

---------------------

Notes:

* #2 You should think of various algos, DS and lock on to a particular one. If you cannot improve upon the time complexity, you need to make a split decision to either 1) continue to think more or 2) choose the next best and move to #3

* All you can do is steal one min from other phases but at the cost of less time in that phase.

* Think aloud in #2, #3 & #4

* At times even less time is available in case follow-up questions are to be accounted for.

* Code structure & consistency is important. You will be penalized if you write big monoliths.

* Additional conditions when GTFO is triggered: ["Solved the problem in 23 min instead of 20", "Did not think about that 1 scenario even though you took care of most of the important ones", "Solved the DP problem in top-down instead of bottom-up.. loser"]

----------------------

Optimizations:

* #3 should be reduced as much as possible. Choose a lang, know its standard lib by heart. This gives more time for #2

* Think of edge cases while writing code in #3

* At #2 one, you should be able to describe a solution (in your mind) detailed enough to convert into a code e.g Do DFS. Keep a max_val variable. Update max_val on values from left & right sub-tree.

* Develop intuition of doing some #2 work while in #1

-------------------------

What actually happens (or should happen) when someone practices leetcode a lot?

1. Reduce #1 time.

2. #2 => Quick recall of high level patterns already encountered

3. Able to generate multiple solutions.

4. #3 => Translate that pattern as fast as possible. E.g. There is a standard template for BFS, DFS, two pointers, etc

--------------------------

So the entire prep can be divided into two parts:

1. How soon you can zero-in a solution and convert into an outline?

2. How fast you can vomit that into a code?

Once you are comfortable in writing any code fast, you do not have to code every problem in leetcode. I see a problem and only solve it in mind and then check whether the approach was ok or not. I know I can code it fast

Edit: So for me if I have solved 200-300 LC problems, what it really means is I have actually coded in like 40-50 and remaining are just mind puzzles. If I do daily 5 mind solves, I can easily cover 200 in 40 days. I finish this daily routine in 30-45 min. (Hey .. I said this is dystopian)

------------------------

High level view:

* Practice incrementally and not in 2-3 months sprint. Think of it as daily exercise.

* This is just the way it is. May be I will do my part to change the system from inside when I am in an influential position. If you are able to find companies which do not do this shit, really good for you.

* Know that as senior dev, the margin for error is even less. So more important to practice incrementally.

--------------------------

I do not approve of this. Its bad. I am just a guy dealing with the "system".

> Goldman Sachs is easier to get into as a software engineer than any FAANG

That wasn't the case 15 years ago, as the post you're responding to stated.

The world has changed.