I'm a kick-ass get-things-done full-stack web engineer. I've never had to deal with one of these sorts of problems in my day to day work; and if I did, I'd just find an existing, tested, stable library that already handled them.
A company that needs someone to solve these sorts of problems doesn't want me on their team in the first place, nor would I thrive there. A company that just needs to build damn good web apps is losing out by using these sorts of questions in their interviews.
The best interview challenge I've had (actually, it was a take-home, with discussion in the interview proper) was about designing code for re-use and extension. It was a great indicator of the company's practical and mature approach to engineering, and of what they really wanted this hire to accomplish.
And modest, too. If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team.
So we should learn all the things, ahead of time, just in case we get an interview question at some point in life?
Here's reality: Someone who knows their stuff is able to dive into details of their work in a way that an impostor can't.
My response to the above would be to have the person bring in some of their work and take an hour or two to take a deep dive into it. I want to see code, documentation, examples of trade-offs and a discussion of the reasoning, challenges, what could be made better, what should not be touched and why, project history, etc.
A conversation with someone who knows what they are doing and is very actively involved in their work is very different from a conversation with someone who might be trying to bullshit you or simply doesn't know enough.
I hate puzzles. All I learn from them as an employer is that someone might have devoted a month to memorizing a whole bunch of them for the interview.
I would imagine that at the scale of a company like Google, resorting to puzzles as a first filter might be an inevitable reality. If you have to interview people en masse you almost have no choice. It's like Stanford having to filter through 40,000 applications a year to accept 2,000 students. You have no choice but to go algorithmic on that problem.
I have 4 books in the "The art of computer programming" series on my desk. They've been more or less decoration for several years, until I ran into a problem I couldn't google. Since I read them, I had an idea of where to start, and I used it as inspiration to craft a new solution tweaked from one of these foundational algorithms.
That said, not everyone is strong in algorithm development, and you can be a kick ass programmer without that skill. I'd only ask these questions if I needed someone with that skill on my team.
The background knowledge to understand what you're looking for and looking at is really important in these cases. You mention having and having read TAOCP, that already puts you ahead of >99.99% of the people doing programming out there - 95% of whom couldn't tell you who Knuth is, what he's written, or what Drofnats refers to.
Learning basic data structures & algorithms is an immensely useful thing for a programmer, and completely essential in many cases. The best of these puzzles are based on problems which people have had to solve in the real world. For the companies, there are many benefits to conducting algorithms interviews:
- setting a minimum standard to make sure there is a shared language and knowledge that you can expect any engineer in company to know.
- making sure you are able to do more than trivial optimisation and go beyond the abstractions that libraries / frameworks provide
- giving you a simple problem to solve in 30 minutes to see if you can program at all.
Well, actually they do allow the candidate to vet the company: the message they send is we don't care about you at all until you do a bunch of busywork and if you're very lucky we might allow a human to spend some cycles on reviewing your results.
If as a company that is the kind of message you would want your prospective employees to have that's fine with me but it would be good to remember that interviewing a candidate is a two way street.
Kidding aside, someone has to build those tested, stable libraries that handle those problem (or even untested bleeding-edge if you are breaking new ground).
Due to the circumstances, normalization wasn't an efficient option. I ended up throwing together a barebones tree with a 5-line DFS implementation to traverse it. It handled inserts, updates and deletions (for my use-case) in linear time.
The details aren't so important as the fact that adding a dependency would have been overkill for my needs. This isn't to say that efficient graph implementation libraries should not exist or be used, but I was able to produce this code faster by having that basic CS knowledge.
The rewards just do not add up for this to remain an industry practice.
This is far too broad. There are plenty of jobs in certain companies where a good understanding of the theory and practice encapsulated by these challenges is the bare-minimum requirement for doing well. Companies that leverage coding challenges like these for these positions aren't incompetent (at least, not for that reason). Just because your work doesn't require this depth of understanding of CS doesn't mean there is no such work.
I'm skeptical, however, that the number of such jobs is very large, even in the "usual suspects" companies (Google, Amazon, etc.). Most jobs, even in these places, one can get by with the most rudimentary ability to understand what 'greater than' and 'lesser than' means and a chart describing time/space complexities of various structures and algorithms in a library.
I have no idea why anybody cares about the 15-minute thing. Each person you hire adds thousands of hours to your available labor. So even if I spend 100 hours finding the right candidate, I'm still way ahead. And the better my working environment is, the lower my turnover, in which case I can spend even more.
But you can test a candidate with imaginary non-workloads?
Implementing a syntactically correct tic tac toe program on a whiteboard doesn't fit it. Plus many are comfortable in working behind the screen than to work in front of white board (real world)
So one big question all companies have is how to interview for programming positions by kids fresh out of school or who've had a job for at most a couple of years.
This is less a question of competence and more a reflection of the age structure of the market for programmers. You will be working with people younger and less experienced than you. You will probably be hiring people younger than you -- how will you interview them?
As someone with a couple decades professional experience, I see these challenges as one of many ways for competent companies to attempt to find competent programmers despite a lack of experience by the interviewee.
The last company I interviewed for gave me coding challenges, but that's not all they asked, I got plenty of questions that allowed my experience to shine. If you only got coding challenges as an experienced developer, then yes, that would be a reason to avoid that company.
On the flip side, my willingness to take the coding challenges in my interview allowed me to highlight my practical experience, because I crushed them with little preparation. Other experienced devs who refused the coding challenges or dragged their feet and complained about them lost the opportunity to receive an offer.
Dude, in EE interviews, we just ask them some basic about capacitor and how to use it. We don't ask them to derive the mathematical equations of electrolytic capacitors.
In fact, in most EE interviews, you just use them to solve ONE problem and be done. Nobody questions you know EE stuff once you've solved ONE problem.
In programming interviews, you have to solve MANY problems and interviewers just want to keep finding ways of docking points.
You are from different niche and actually you are being paid less than those guys who knows the stuff you don't
From [0]:
"[S]killed cloud and backend developers, as well as those who work in emerging technologies including Internet of Things, machine learning and augmented/virtual reality can make more money than frontend web and mobile developers whose skills have become more commoditized..."
[0] https://www.linux.com/news/developer-nation/2017/3/visionmob...
A 13 year old making a website for his dog in PHP can fit your definition of full stack web engineer.
The underlying parts of this "full" stack require significant domain knowledge around algorithms, data structures, computer architectures, operating systems, distributed systems, networking and communications, programming languages, etc... and most importantly, critical thinking and engineering rigor beyond trial and error and cargo cult copy-pasting from stackoverflow into your "get-things-done" duct-taped spaghetti code base.
Those underlying parts created by the people that you now call "incompetent" are required to design, implement and maintain the "kick-ass" babyproofed playground you live in and that allows you to put food on your table. Have some respect.
If you are so kick-ass and get-things-done, checkout the source code for Linux, Chromium, v8, node or libuv, Python, Ruby or whatever technology you use and try to get something done there to a level of quality in which it gets accepted and see what happens. You and your kick-ass denomination will be stomped over and brought back to reality.
Something else to consider is that the interview is optimized to select for true positives and reject false positives at different rates. It's been discussed elsewhere that for a company like Google avoiding false positives is much more important than finding good candidates. So it may be the case that some instruments like trivia recitation provide the right signal at the intersection of the optimization curves. The fact that many (even most) qualified candidates score poorly on these instruments doesn't impugn their utility; their primary goal isn't to identify good candidates but to filter out bad ones.
Anyway, it's complicated. Especially when hiring for technical leadership.
To pre-counter an expected objection, if your company makes significant decisions like that in a single 45-minute (or any length, really) meeting you need to change your design process, not your hiring process.
Its not enough to outwit a Burmese Python but you need to do it while a clock is ticking.
We all know the best performance and indicator of skill always comes from coding with an egg timer or stop watch.
Oh and did I mention the Hacker Rank challenge was being asked before even speaking to a human being about the job?
Programming is only a competition sport when it is voluntary, no need to turn access to a job into some kind of Christians versus the lions spectator sport.
If someone were to approach me with that kind of offer I think the response would not be much longer than one line (and I'd try hard to keep it polite).
I prefer that a lot more than scheduling a 1 hour phone interview during my workday, to do the same stupid questions over the phone, with someone who can describe neither the job nor the company.
https://www.mcsweeneys.net/articles/faq-the-snake-fight-port...
Not to mention, even when you have these types of interviews it still doesn't seem to filter out toxic people, such as the harassers of Susan Fowler at Uber.
Of course, it would be easier for workers to be okay with this arrangement if basic needs such as health insurance were decoupled from one's employer. That's another argument for single-payer in CA.
I think it makes perfect sense. A bad developer hire is not just unproductive. They also tend to be a burden on their coworkers and reduce their productivity by asking trivial questions and writing buggy and/or hard to maintain code.
With startups the risk is even greater. Think about it: the odds are already stacked against you. Why would you take even more risk by randomly hiring developers? Sure, you can fire them, but by then it may be too late.
The situation now is not better. People have cargo-culted a strategy that is based entirely on having enough applicants that you can afford to have a stupid false-negative rate. It's also easily gamed, so you have to keep trying to find new puzzles for people to solve.
It certainly would be terrible for morale if implemented thoughtlessly. But if it was done in a way with clear expectations of employee performance, then terminations would not be arbitrary. And the morale hit of being terminated at any time- a situation with legally exists in California atm anyway- would be mitigated by more companies being quicker to hire instead of forcing long arduous interview processes.
So then the situation becomes "If mgmt. is just, then they will keep me on, if they are dumb, then I can get quickly hired across the street anyway."
This sounds like an utterly miserable experience for both new hires and coworkers of the new hire. Do you really want your company's onboarding process look like FNG syndrome?
Also, if you fire someone in California they will likely file for unemployment which means your UI reserve account requirements might go up.
Isn't it far more important to know how to design a modern, maintainable, scalable web application? Know how an when to cache stuff. How to design a API. How to integrate with third party APIs. How to setup logging. How to sanitize data and other common security problems. How to setup test/build/deploy structures. Et cetera, you get the point.
If, while building a web application, i encounter a "big data"/"data processing" problem, i will find a appropriate solution using CS best practices. But hell, i would struggle to implement a simple array sorting algorithm under pressure.
How do you do that without some basic understanding of computer science-y stuff?
How do you define "scalable", how do you measure it? How can you have some intuition about a design before we spend 3 months and many sprints building it first?
How do I know when to cache stuff? Does it matter if I have calls to a remote cache in a tight loop? Should I be using an in-process, out-of-process, or remote cache for a particular piece of data?
Here's one that comes up A LOT with junior and mid-level developers: floating point numbers aren't magically precise things.
There's a balance here, somewhere. I personally would never use the trivia questions in the OP. But the idea that you don't need to know even basic computer science-y type things, seems crazy to me.
I can't see myself hiring a computer programmer who is offended by being expected to have a casual acquaintance with computer science.
> How do you define "scalable", how do you measure it? How can you have some intuition about a design before we spend 3 months and many sprints building it first?
> How do I know when to cache stuff? Does it matter if I have calls to a remote cache in a tight loop? Should I be using an in-process, out-of-process, or remote cache for a particular piece of data?
You're proving the above poster's exact point. You are putting your weight in applied questions that rest upon the developer's specific experience. This method is the opposite of evaluating people for their ability to memorize a half dozen algorithms and data structures.
In my experience interviewing candidates, asking people to implement a caching algorithm is a distraction to both parties. A much better evaluation is their ability to provide box-arrow diagram and talk it through. This is much more effective towards understanding their thought processes and knowledge. It is also much, much closer to the _real_ day to day of a today's engineer: communication, advocacy, and breadth of knowledge. Code is cheap. Business should screen employees for an interest.
CS textbook questions introduce enormous amounts of bias, especially in panel interviews. It is a dangerous trap that companies use to further entrench their team cliquiness and departmental monoculture. It is ripe for Simple Sabotage. Simply put, its lazy.
What do you mean by "understand"? In some ways your question is like asking an engineer how he can choose a particular bolt for use in, say, an elevator, without understanding the basics of how the failure characteristics of the bolt are known. There's some relationship there, but is it really an important one? Sometimes it may be. Other times (most times?) probably not.
> How do you define "scalable", how do you measure it? How can you have some intuition about a design before we spend 3 months and many sprints building it first?
"Scalable" is entirely dependent on the business' needs and plans, and measuring it certainly doesn't require any formal understanding of computer science. This is fairly basic arithmetic. As for the design intuition: computer science-y things are only so useful as far as that goes. Their real utility is in optimization, not designing ahead of time.
> I can't see myself hiring a computer programmer who is offended by being expected to have a casual acquaintance with computer science.
Well, as you yourself noted, questions of this sort aren't for "casual acquaintance" levels of knowledge. These kinds of exercises are basically things an undergrad (or, in some cases, graduate) student thinks are important because they're all he knows.
Incidentally, the fact that interviews focus so much on these kinds of "CS fundamentals" is one reason I chuckle whenever somebody tries to describe these companies' activities as "engineering." Any engineering that goes on in places that put much weight to these kinds of questions, and which isn't interviewing candidates specifically to engage in academic, or close-to-research CS, day-to-day, is usually by accident.
a) You should have just learned it
b) You don't have years of experience with 12 languages
Anything past fresh college grad and they are pretty dumb...
Big company? You almost certainly need to have your CS challenge question toolbox full.
Smaller company? Many follow the big company interview methodology, but some don't, so more likely you can get away with not breaking the spine on your Cracking the Coding Interview.
Funnily enough none of the tests I've had ever talk about relevant things like data normalisation / de-normalisation or anything that will be used in the project.
There are some however here that you really shouldn't be, like remembering specific algorithms - if you're just memorizing 20 different sorting algorithm's exactly implementation, clearly that's not producing much if any value for you.
If someone however was to give you this Algorithm section https://nbviewer.jupyter.org/github/donnemartin/interactive-... and tell you to implement it, that would prove whether you had the skills needed to properly use Google and StackOverflow for anything but a direct copy+paste and could be a very good test for a programmer.
Basic data structures, knowing when to apply them and how to solve fairly straightforward challenges like "does this string contain any duplicate characters" when you have full use of Python's builtin data structures are completely fair interview questions in my opinion.
Just picking 1 or 2 of these questions that seems vaguely related to your work is enough, combined with asking some basic technical stuff like "What's the difference between a class and an object?" can weed out a shocking number of people, showing they don't even have conversationally useful knowledge about a topic.
And those are exactly the people you would not want for a job because they would most likely not have the flexibility to shift away from that ecosystem if there was a need because it would take them forever to get up to speed.
It's much better to know how to use outside references efficiently and to be able to 'swap stacks' in a couple of weeks than it is to be an expert in some language that could very well be obsolete, and that's assuming that there are many jobs left today where deep knowledge of only one ecosystem will get the job done.
The time when you could spend 4 years learning a specific library and language and then make a career out of that is long long gone. What we have today is more akin to enormous libraries sitting on fairly rickety narrow foundations where - if you're lucky - the documentation of that library is relatively good, and the half-life of the whole thing is measured in months, a year at best. Today you work in Python, 3 months from now in Go and a another 6 months after that it will be JavaScript, typescript, clojurescript, coffeescript or <insert your flavor here>.
So, you want to have your problem programmed in Assembler, C, C++, Python, PHP, BASIC (name your dialect), JavaScript, Erlang, Python or I don't care how many other languages that you care to name I'll accept the challenge. But I won't cut off my external memory bank in order to prove that that is something I can do.
(Well, truth be told I probably can do it in a couple of the above but that's mostly because there was a time when the world moved slow enough that you could actually invest a couple of years, but these days it is much better to know how to leverage open source and google than it is to know the gritty little bits of whatever language is in flavor this week.)
Of course, if you are looking for 'javascript programmers' it is fair to ask some questions about javascript. But in my experience it is a lot more efficient to search for programming talent and good debugging and writing skills irrespective of what language they are currently trained in.
Languages are a means to an end, programming is the skill you want, not 'a particular language programmer'.
Not all programmers are good explainers. Someone who speaks English as a second language might have difficulty articulating the differences between two terms despite being able to code circles around you.
One of the best programmers I know explained Object Oriented Programming as "Imagine everything is a thing".
I have a computer science degree, I've been coding for 20 years, and I've held (and kept) a CTO role at two mid-sized startup companies. Currently I'm considering looking for a job at a larger company (where I wouldn't be CTO but I'd be hopefully paid more) and these kind of questions make me think I need to almost go back to school before I can start interviewing.
When did it get to the point where we need to read thick books on programming interviews and spend hundreds of hours on HackerRank practicing algorithms to get a job where we probably won't use any of those day-to-day?
Edit:
For fun the other day I decided to code a linked-list from scratch in C and it took me a half-hour plus... and I have known that data structure for decades. I can't imagine doing a harder problem under the pressure of being an interview.
If after 2 CTO roles you interview for a job and they ask you to write a linked list algorithm, then would you want to work there? I mean you might, but that alone should at least beg the question. If they're not asking you how you'd manage a team of smart but stubborn coders or structure their company's software architecture and services to be more reliable, then they certainly aren't paying much attention to you or what your strengths and experience are. Or they simply don't know how to hire an experienced person, which signals that they don't know what to do with an experienced person once hired.
Also, it would take the vast majority of great coders at least a half hour to code a linked-list from scratch in C and get it right, depending on what you're doing.
So don't worry.
But the number of unfilled positions is also increasing, so we are not closing the gap, right?
So the gap is widening, but the requirements to get a position are also going up. That just makes no sense to continue for a long period of time.
Some examples:
1) Explain how and why you would implement authentication on a HTTP API. What other authentication methods do you know and why would you not use them?
2) Tell us about a scaling-up challenge/problem you had on your last application and how you solved it.
3) What technology stack would you use for a browser-based P2P file sharing application?
4) Name a library you recently discovered. What problem did it solve?
5) What mobile app on your phone right now has a bad user experience in your opinion? How would you make it better?
I've asked HR people why they ask that question, and it was not to have a correct answer but to demonstrate your train of thought.
When I give a coding interview, I will use more development oriented questions but I want to see HOW they get to the answer, not the fact they memorized an algorithm that just so happened to be on the coding test.
That's not to say they can't ask you about data structures, but they shouldn't be asking you to code them up from first principles if it's something the language can do for you.
I find it much more fruitful to have a technical chat with candidates instead of being dogmatic about asking toy questions. It's pretty obvious when someone doesn't know what a linked list is with a 30 second chat. Heck, even drawing a few boxes and arrows on a napkin will suffice.
These sort of challenges are great for learning some of the theory behind computer science and getting you thinking, but they're not a useful part of the interview process imo.
It's one thing to "know" how to balance a binary tree because you've read up on and practiced the most common challenges - it's something else entirely to actually think through and understand a problem, then come up with a solution.
I'd much rather have someone who can describe the edge cases and the complexity of a problem but get the final solution slightly wrong (but hey, the know the edge cases so can write tests for it, right?), than someone who can regurgitate code they've written before without really understanding it.
There are too many things to know in the world in order to be able to know them all as deeply as we wish. For the things that we can get away with knowing the most common aspects of, time might be better spent elsewhere than to learn more about that thing.
I have heard about larger companies / government agencies having these kinds of interviews due to internal procedures, but hopefully most startups have more sane setup.
- Because it is actually a good predictor of job success (does anyone think this is the case for anything but a handful of job roles?)
- To be adding a hurdle to target those who really want the job (downside: it also adds a hurdle to top-notch gainfully employed people who dont have time to study for such exams)
- Another is they just need something to reduce an otherwise overqualified pool of already qualified candidates (fair point, but at the risk of losing out candidates from concern one above.)
- Legal risk mitigation -- add a quantitative measure to show a facade of merit and process.
TBH, I have never been on the hiring side at a small firm, so I don't know. But I have seen several things:
1. People recruiting me to Amazon and practically giving me the exam questions (I declined mostly due to location) Same thing at two other firms (perhaps to get referral bonuses?)
2. An H1B process that is by-the-book correct yet entirely against the spirit of the program.
3. Tons of interviews, screenings, etc at big firms just to justify an already-decided inside candidate. This I witnessed firsthand and makes me really upset because of all the candidate time they waste and the false hope they give to people who were never in the running to being with.
"... you wont be able to discover how to solve a problem if you don't have knowledge about the solution in advance."
Is simply false, whilst research is a skill all of its own it's most definitely possible to go off and learn key techniques when you need too. Relying on serendipity for knowledge to be useful is not very efficient after all.
At best the additional knowledge gained is a helpful side-effect.
When you face a new problem, you just don't know how to find a solution, you based your hypothesis in the knowledge you already have. You can do research, but the more knowledge you have the less research you will do. And that time you save is money the company saves.
Anyway, you decide what to do with your life. If you are happier raising a family that is good. If you are happy learning stuff to apply to better jobs, that is good too. But obviously you cannot have everything because time is finite.
My question is, by studying/doing good amount of Python [currently working on it], going through the entire interview challenges presented here, seeking to gain Master degree in Management Information System [MIS], can I apply for job and be shortlisted which might require CS graduate and maybe graduate with MS in CS?
Let's just say for the sake of the comment, I won't be able to obtain a MS in CS because for numerous reasons.
But this place had 3 of these type of challenges that you had 1hr 30mins to complete all of them. I'm sorry, most of this stuff you will NOT find in any job unless its some specialty. For an backend/angular/react developer you will not find this at all. I feel that companies that do this are out of touch with the correct way to find candidates. But on the second hand I also see why they do this since programming has became so much popular now a days.
[1] https://nbviewer.jupyter.org/github/donnemartin/interactive-...
I personally find "What is your favorite programming language?" or "What systems architecture to you find more compelling?" to be far more valuable. It gives some insight into their commitment to the trade and gives you an opportunity to make it a conversation to dive into their reasoning process and depth of knowledge about a topic. I think it's far easier to weed out the fakers if they can't express why Erlang is interesting to them than for them to tell you how to implement a linked list which is very easy to google and memorize(but won't necessarily prove any skill).
Also, where's the completed response caching layer? Nothing destroys performance (and hikes costs) like having to recompute every page response from raw data.
And that doesn't even touch my annoyance at shoehorning "federated architecture" to mean "sharding with a different algorithm".
Sure if you want to maintain a certain "prestige" you should maybe use them to limit your applicant pool but in the end if your work is nothing but coding front-end JavaScript it doesn’t matter do you know how to traverse B-trees or not. And if a need somehow arises it is very easily googleable and implementable with good enough CS education.
I think what the interviews should be about, and the best that I have been, have involved some basics sure but also one had few “real-life” coding exercises and in another I had a code review about one of my project’s code (which I was surprised by). Nothing tells more about a person than having them to explain what is their passion but if you are only interested in people that can jump through some loops that’s the people you are going get. Maybe in that kind of company that's just how they do things.
I’d argue most people can intuitively tell, maybe not why, when a recruitment process feels “right” compared to one that is forced and does nothing but dehumanize you to a walking Wikipedia and ticket-monkey. But maybe in programmers there is also some that seem to like that idea so I’d say it is more of a skill and culture fit than anything else.
But in any case the whole process should be based on some structure that actually measures something real. I personally don’t like being reduced to few facts about missing knowledge on a spreadsheet which I could learn in a week or so. It hurts my ego and most of all makes not want to work in the said company in the future so when I’d know those things I won’t be reapplying.
Looks like a fun bedtime reading material to me.
I'd say read this kind of stuff on regular days, not one night before interviewing, and peeps would do just fine.
It seems to me, after twenty years of building software, that the need for off-hand knowledge advanced algorithms is rare, and the need for knowledge of design patterns is exceedingly common.
I see a lot of people posting about how they dislike the technical interviewing process. The sentiment seems to be that for a certain class of popular developer role it's entirely unlikely that they will ever need to remember how to implement a heap or red-black tree to be effective at their job... so why use problems like this in an interview?
I think these sorts of questions should be used by teams that want to set the minimum standards on the team. I'm reminded of a rule used at the Recurse Centre: never feign surprise when someone asks a question (I paraphrase). The idea is that if someone asks you a question about something you think is fundamental, like Bash for example, don't immediately feign surprise and say, "You don't know bash?" It's not helpful. Instead take it as an opportunity to teach them something awesome. However this doesn't generally work in a professional setting where you're required to know Bash in order to function at your job.
If on my team we're responsible for the operation and maintenance of several millions of dollars worth of infrastructure that runs our customers' applications then there are certain minimum requirements for operating effectively within this team. I expect you would know Bash at a minimum. I should also expect you to know the network stack of the OS we deploy on, how TCP works, what a hypervisor is, etc. We may write most of our application code in a high-level language that abstracts these details away but that doesn't preclude you from understanding them. It's just a convenient tool. You have to know how to manage complexity and avoid premature pessimization in order to be effective and that means you will be interviewed using technical questions to screen for that minimum level of knowledge.
However I think most companies do tend to use this tool poorly. I've interviewed with startups that build consumer web applications that ask questions about radix sort and k-d trees. That's what I call, overkill. This trap is easy to fall into if your motto is something glib and banal like, "We only hire the best." If you don't quantify what "best" is you're just going to negatively filter out potential candidates and hire on bias. You have to scale the screening process to only test for that minimum competency and choose how much risk you want to take in teaching new hires.
If I'm hiring a more junior developer to our team I expect that we're going to mentor that person and make them a better engineer by working with us. They can ask questions that may be outside of our minimum standard. However if I'm hiring for a team-lead position I'm much more likely to not accept a candidate who cannot fly through our screening process. Working with them is going to be difficult and if it's 3 in the morning and they're causing more problems than fixing because they don't know how the TCP re-transmission protocol works then we're going to have a problem.
The conclusion of all this is: tweak the screening process to set the minimum standards required for effective communication on the team. Don't set the bar unnecessarily high: define what the bar should be and assess the risk of mentoring junior developers. You need a good mix across the spectrum for an effective team.
