It's not just testing fundamentals, it's testing who spent the most time on interview prep. Companies increase the difficulty level as more people do prep. That's become a cycle that favors those who have the most spare time. Senior engineers often have houses, kids and aging parents to take care of.

That doesn’t excuse hem forgetting what a priority queue is and when it’s appropriate to use one. The good senior engineers I know have a strong grasp of the fundamentals

You're hiring the candidate who happened to use one somewhat recently. The same candidate has completely forgotten other concepts and would have looked like a fool if questioned.

Requiring to implement a priority queue is harsh and no one should do this at the interviews.

Asking "what is a priority queue" is a totally fair question (if your job may reasonably require it), because knowledge that such things exist is a big part of being a senior person. You don't have to be able to know the class name, or exact notation, but you should be able to know what to Google for.

A person who does now know what a priority queue is will happily write O(n^2) algorithm which repeatedly calls max() and completely kill your app performance. There would be no opportunity to Google anything, because only senior people get business requirements, not names of algorithms they need to use.

That’s why people do more than 1 interview. My example was just an example, I probably should have qualified it.

If your company refuses to hire anyone where this statement is false, that doesn’t tell you much.

So you're saying LeetCode is only for screening seniors? What about entry level?

Where did I say that? Senior should have both fundamental coding and also more broad system design interviews.

> what other scalable solution do we have other than LeetCode type of questions?

This question is based on a flawed assumption that interviews need to be "scalable".

If you're interviewing more than 3 or 4 candidates for a senior position, you're probably doing almost everything wrong, starting with your method of finding candidates. (Job postings are almost universally terrible. Why is everyone so bad at it? I don't want to hear excuses like "HR". If hiring engineers is crucial for the company, then you need to fight HR.) You may need to interview only 1 or 2.

Don't "screen" a bunch of people. That's a giant waste of everyone's time, both employers and candidates. Start at the top of your list, and only interview your top candidates. Spend the time to research those few individuals — even before you interview them — instead of spreading out your time relatively equally on a large number of candidates.

This will just interview people with the best resumes and will be biased.

Yes, that's the point. If you're hiring a senior engineer, you want to be biased toward the people with the best resumes. Insanely, the current system is actually biased against them and in favor of freshly minted comp sci graduates.

You'll probably be biased in worse ways too. That was my point.

This is a strange point. The empirical results from audition-style interviews have been in for many years, and the results are indisputable. Software engineering is extremely lacking in diversity. So maybe try something else for a change? Not sure how it could possibly be worse than what has already been demonstrated over and over again to be absolutely awful.

My suggestion isn't particularly novel. It's often how hiring works in other industries that aren't as insane as tech. Software engineers have their own special snowflake hiring process that they hold onto almost like a cult. They rhetorically ask "What's the alternative?" without actually empirically looking at the rest of the world outside of software engineering. The fact that "FizzBuzz" and "LeetCode" are words everyone recognizes just shows how much of a cargo cult software engineering has become.

You give a very simple question, generous time frame (like a 40 minute slot for a 5-minute question), and prepare set of discussions / more complex scenarios. Also don't require compileable code -- getting all the syntax errors out is boring and stressful. Do the thing on the piece of paper, whiteboard, or online editor without compilation functionality. Tell them you don't care about exact function names or typos.

If the interviewee does not work well under pressure, they'll have 30 minutes to do the question. Hopefully they'll worry less during the interview, and perform better.

If the interviewee breezes through your question, you give them next, more complex variation ("and now you cannot assume X anymore"). Make sure you have a few of those.

Basically, don't be a computer. Your goal, as an interviewer, is to get the candidate to show off their skills. Putting extra pressure does not help with it.

(and yes, this is pretty scalable. we are still having a single meeting for each candidate)

A lot of down votes, but I have yet to see a response to the valid question of "what other scalable solution do we".

Don't attack the person. Attack the argument.

LeetCode is not fundamentals.

Leetcode requires you to know all the common algorithms and data structures. Every software engineer should know these

LOL. The data structures I can see, but what algorithms are considered standard will vary from domain to domain. A good engineer can look these up. I dare you to find an engineer that knows ALL of the LeetCode perfectly on the first try.

I don’t get the “LOL” from you but ok. Anyway, the fundamentals are in textbooks for a reason, they aren’t domain specific. To answer your other question, I could definitely solve most leetcode and so could my colleagues. Maybe not perfectly optimally first try for all but who cares about that.

"Maybe not perfectly optimally first try for all but who cares about that."

That's the purpose of LeetCode. If you're saying you can't solve all of them, what happens when you get one of the ones you don't know?

Then you keep interviewing until you get the ones you know. There's luck involved with everything. Luck in the sense of the right time at the right place.

This is a very unserious reply. You have a bad habit of misconstruing my words into a straw man

Perhaps you're not using the correct words.

Sorry. Yeah, I probably misread wha you wrote or read some other comment. Anyway, to answer your earlier question, good interviews are a conversation and allow you to demonstrate your knowledge and problem solving abilities. It’s ok to start with a suboptimal solution to a problem and iterate. If you already know the perfect solution to one problem then a good interview will move on to another problem so it’s not that useful.

This is a very unserious reply.