Side note: I'm to point now if I get pointless algorithm pop quiz questions in an interview I'll politely ask to move on.
What I don’t understand though is this: why not just do the problem? People ask these kinds of questions to see how you solve problems and what it’s like to work with you. They ask the same question to every candidate so they can calibrate. They ask questions to known problems so they can see how you will handle unknown problems (ie the job).
How else do you expect them to interview you?
Because none of the work I'm interested in deals with CS trivia at that level, and it generally is a strong indicator that the company is engaged in one or more terrible practices like, e.g., incorrectly thinking Google's hiring process is generalizable or that CS trivia is the same as engineering. Or else it is looking for someone who doesn't know or care to think about the bigger picture and solve bigger problems than what they can pick out of a textbook (i.e. they're looking for a technician, not an engineer).
I'm not a fresh graduate looking for my first job in which I'll spend my day throwing code at an editor to implement someone else's designs because I lack the experience and wisdom to participate in the design process, nor am I ignorant and arrogant enough to believe a little understanding of DS&A is sufficient to cover all or even most of the important problems in engineering a product.
> They ask questions to known problems so they can see how you will handle unknown problems
That doesn't make any seunse. These kinds of problems test memorization and little else.
> How else do you expect them to interview you?
By asking intelligent questions having to do with problem solving and not running through the college level CS equivalent of basic arithmetic.
Also, at my company this serves as a jumping off point for other questions. Scaling, concurrency, networking etc. All great for seeing breadth of knowledge and problem solving/talking through a solution type skills which I think are relevant in day to day work.
"Will this be relevant to my daily responsibilities and, if so, in what exact context?"
or
"How many times per week is this algorithm re-implemented by your engineers to solve real problems?"
it may in fact be relevant, and then you better know it. but for 99.5% of dev positions, it's just a BS test. knowing the Big-O, cpu/mem trade-offs and applicable datasets for common algorithms is usually important but being able to re-implement them rarely is. the most important thing is knowing what the algos are and where they need to be utilized (binary search, bloom filters, nested sets, etc...). the most i do is give high-level descriptions of the algos' steps, if i know them.
it's valuable to have the interviewers describe early on what a typical day entails at the position you're applying for and what type of assignments are typical. you'll have much more leverage to have these types of conversations.
of course, this attitude ain't gonna fly for low-level coders working on kernels, compilers, graphics, etc.
So even if these questions aren't related to the day-to-day work programmers do at the company, it could give them a legal way to filter for intelligence.
I say that it could because I think they'd have to select the questions fairly carefully to ensure they're achieving the intended result, and then compare the success of the candidates hired via those questions vs. the success of those hired via work samples or different types of interview questions.
Probable thought process of interviewer:
* What a prick
* LOL we have 200 resumes on file for this position
* Dammit I'm going to have to interview more people
* When can I go back to being an actual engineer, the job I was hired for