That said, some coding in an interview is pretty much a requirement for any sort of programmer job. If you ever start interviewing candidates yourself you will see why - a non-zero percentage of applicants are very poor programmers, even those that claim years of experience.

Leetcode interviewing is lazy interviewing. It's for when you don't want to put an effort in your interviewing process to check if the candidates have the skills you need for the position you are filling.

For example. My interview process nowadays is one web API interaction challenge: Https://challenge.bax-dev.com (in Spanish, so you may have to do a Google translate. Use with curl)

In that untimed challenge the candidate submits their code and email. They arrive to my email and I check the code quality of submissions with my morning coffee.

Then in the ONLY 90 minutes Interview with me, we talk 30 mins about experience in their resume, 30 mins about our company and the position, and we code the "server" side to the web client they created .

We do it pair programming style. The questions I achieve to answer are: would I pair program with thus guy? (Like, is she cool to work with?) And does she know what she is doing?

I've had very good results with this method.

And, from the code exercises I am sure anyone can guess what skills am I looking for.

There was a great circlejerk on reddit in one of the outages where people asked whither Google engineers have inverted enough binary trees to bring their systems online. Basically saying that the skills they hire for are for Algirithm competitions, not for building enterprise software.

And I say this as a CompSci PhD who did his good share of data structure and algorithms during my time in academia.

In the defence of LeetCode-style questions, I do think they work, and very well may I add - with the caveat you have the throughput of candidate to make it work well? Their ability to filter out 'those who can't code' in an efficient manor while sacrificing a small amount where it filters out 'those who can code' greatly out weighs the alternatives. The alternatives needing to fit into a 1 hour timebox, be objective while also favouring the positive cases (I think I got that the right way round).

My two cents would be more around the way in which they are conducted; in my experience I've found conflict with the interviewer more then the process itself - with interviewers in my past lacking.... empathy (may not be the right word) for the person on the other end of the screen/table feeling flustered, nervous or down right stupid that they're struggling to solve a simple fizz-buzz/reverse string problem, leads to a snowball effect and pilling onto that can effect the candidate in quite a spectacular way. Best interviewer I've had asked if I was alright and got me a glass of water, props to that guy!

I dunno - I've just come to terms with having to learn how to play the game, even if I find that part of the game really hard and to some parts unfair. Such is life

I'd rather learn interview algorithms from books. And by getting feedback from trusted peers.

How do you square that with the reality that many software jobs have leetcode as a gate to an offer? I find myself stuck at this juncture. I am comfortable with software practices, but the reality of these sorts of interviews has me basically trying to figure out how to “hack” the coding interview portions. It’s somewhat beneficial, in terms of pushing me to improve my solving skills and data structure/algorithmic understanding, but I obviously can’t help feeling that a lot of the time I’m spending is tail-chasing, as a lot of the problems I encounter seem to be very far removed from the reality of day-to-day web development.

I swear that for 90% of the typical software interview loops, someone with some minimal understanding of computer science that spent 2 month studying the typical Leetcode problems would probably have been fine and do way better than a software engineer coming out with 10 years of experience that didn't take the time to review his leetcode problems.

What do you mean? That's pretty much what leetcode-style problems are during interviews. You get a problem with some theme, like "here is a list of airplane flights in an array composed of tuples, with the first member being origin, and the second being destination. Write code that would create full-blown routes out of those flight entries."

You ask questions, clarify constraints, come up with a few approaches, discuss with the interviewer pros and cons of each, decide to go with one, implement it while walking the interviewer through your thought process. And then you discuss limitations and edge cases, scalability concerns, how you would test it if it was a problem you were solving at an actual workplace, etc.

Leetcode-style interviewing doesn't typically refer to "we just pulled a random problem from leetcode, go ahead and solve it while I am standing over your shoulder, and we will check how correct the solution is afterwards." In fact, interviewers care way more about the thought process and your approach, as opposed to caring about your solution matching theirs. In fact, there were many cases where people ended up not solving the problem and passed the interview anyway, as well as cases where people solved the problem and ended up not passing. Because the process of arriving at the solution and the reasoning you took to get there matters way more when hiring (even if you didn't get there all the way to the correct solution), as opposed to just getting the correct answer. The fastest way to fail a leetcode-style interview is to sit down and write down the correct solution as fast as possible, without explaining your reasoning process or even anything at all.

> But yet, these interviews quiz me on things that I can easily Google that I may not know off the top of my head. It’s absurd.

I don't work at Google so I'm lucky to have freedom in the way I interview engineers and usually I try to squeeze out the quiz aspect as much as possible.

If a candidate doesn't know the algorithm for a given problem and can't quickly come up with one, I usually proceed to give a detailed explanation for it. In the end the task is reduced to "write between 6 and 10 lines of code that do X in your favorite language" and yet a majority (80-90%) of inbound candidates for software engineering fail at it (for non-inbound sources a picture can be very different of course).

Contrary to a common view, I believe that this approach actually imitates my daily interactions with a developer quite well and the correlation between interview performance and job performance is very strong in my experience.

And interestingly I've seen many people who shine in oral interviews (tell me about your experience) and then fail to produce any code at all, both during the interview and at work. So even if I wanted a good alternative approach to engineers I haven't seen it so far.

1. Rely on referrals from people I trust. If somebody I've worked closely with and respect highly says that Person X is awesome, then just hire Person X. This obviously has massive problems with creating an insular culture and only works for people with a sufficient professional network, but it is incredibly high signal.

2. Have a long conversation with the candidate. Discuss their prior experience and war stories. This can be gamed, but I suspect is harder to game than leetcode.

Both of these options have a big problem as they scale, which is that interviews do not transfer. You need the hiring manager to do this interviewing. Making every hiring manager at a 100,000 person company do their own sourcing and interviewing is going to be a mess. Megacorps want to allow anybody to interview and then once somebody passes those interviews, they'd be able to join any team. I have mixed feelings about this approach.

So the best option IMO is two 2-3 hour pairing sessions. Refactor some code, develop a feature, and diagnose a bug. Have the person comment on the architecture of the code or system they used and describe large scale changes they'd make to improve it or prevent it from arriving at this state.

This requires more pre-work since you need to create an entirely working fake system and environment. And since there is a huge incentive to practice for these things, people would definitely sell knowledge about the fake system. It is also higher variance when there are new interviewers, since they represent a larger portion of the total interview panel.

I remember when a former colleague wanted my input on his interview question which was basically, "Write the algorithm for product recommendations." (eg, like Netflix's movie recommender.) Despite repeated warnings, he went ahead with that question only to come back and admit, "Yeah, that wasn't at all good." Imagine what the poor guy or gal on the other side of the table had to go through.

I don't know what the right answer is to interviewing, but my take is that I would prefer to work with someone who I can get along with, have real human conversations, and become good collaborators -- even if they're not ace coders. That measurement seems glaringly missing from too many interviews.

I'm fairly confident that if you've studied hard enough to solve these problems easier the studying just paid off by making you a better developer.

A far better approach is to talk through the design of a system - conceptual or previously worked on and ask questions about it. Strike up a conversation with the person. I find it extremely easy to tell if a person knows what they're talking about and enjoys the subject _on subjects I am familiar with_, which is quite common in the situation where I am interviewing someone to join my team.

If you were capable of studying Leetcode so hard that you mastered the interview process at one of the most selective software companies in the world in only a few months, it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.

Arguably, this is one of the benefits of Leetcode-style interviews. They focus on core software engineering aptitude, while not arbitrarily excluding people because they didn't use the right VCS at their last job.

It often goes unmentioned that these interviews test the wrong skills for software development and even instill bad practices. To wit, those artificially handicapped online IDEs force you to memorize language APIs which any real IDE would handle for you -- forget that the JS lowercase string call is "toLowerCase"? Too bad. Also, since time is of the essence, and no debugging tools are provided, you better be using an interpreted language (read: JS and Python -- and really only the former unless you can import the correct libraries) and littering your code with print statements.

Other companies opt for the ostensibly fairer "take home CRUD app assignment" but this too is a facade to lend credence to a preselected candidate pool. No matter how well you complete the assignment with all enterprise grade best practices, you'll still playing the lottery (and this time with a five hour time sink).

Bottom line is don't interpret a lack of success in this draconian system to a personal defect. Ideally, seek employers who assess candidates fairly and qualitatively.