At that point you may as well just leave. You’re not going to talk the interviewer out of doing the interview.
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).
> What I don’t understand though is this: why not just do the problem?
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.
We don’t have algorithm problems at our coding interview but they are relatively simple problems. You’d be surprised how a simple problem _does_ filter candidates that can “bluff” their way up to an actual co-sign interview. In my limited experience it can give the interviewer valuable
Info.
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.
if you're gonna take that route, the appropriate response is:
"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.
One hypothesis I've heard is that companies have found that the kinds of questions that get asked in programming interviews can serve as a decent proxy for IQ tests (which are effectively illegal for hiring purposes), if they choose the right questions.
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.
+1 for the thought process. You left out "Damn, I suck at interviewing. I can't believe they want ME to help decide who we hire. I'm still trying to figure out how I snuck in the door."
I answered the question on big o and gave some examples. The guy asked to have me implement something ridiculous, I responded, honestly I wouldn't, I'd use the one in the jdk. He was a little shocked and kind of stuttered onward. I didn't get the job, and I'm fine with that.
I've had several interviews that were pretty practical. They do exist but there's unfortunately no way to know in advance unless the company advertises it.
