[quasse]

Yeah, I've seen some real horror stories about bad interview processes in the past, but this seems more like the guy outing himself as a defensive and impulsive person who immediately shuts down when he doesn't "know" something.

I can't remember Djikstra's algorithm either, but I would happily try and write a 15 line brute force recursive maze solver in an interview.

Of course it's not something I expect anyone does day to day, but it's also the kind of simple problem that I'd expect almost anyone with a CS 102 level of knowledge to be able to reason out by just taking a few minutes with a pencil and paper. As an interviewer, even a brute force solution would demonstrate a good willingness to look at problems using your fundamental skills and reason about something you don't have a ready made solution to.

[Merad]

> I can't remember Djikstra's algorithm either, but I would happily try and write a 15 line brute force recursive maze solver in an interview.

You'd fail the interview. The type of interviewers that ask this style of question are never interested in seeing the the naive brute force approach.

[EduardoBautista]

My experience has been different. Usually the best thing to do is to write the naive approach first and then let the interviewer guide you towards what they think you could improve.

[Rooster61]

This.

Implement -> Evaluate -> Refactor

I'd rather have someone who could caveman the first approach, recognize the inefficiencies, and improve the execution than someone who rattles off a memorized algorithm to a common problem.

If the interviewer is wanting the eloquent solution right out of the gate, then the manager might be hiring for the wrong position.

[chooseaname]

This works best when you've formed a rapport with the interviewer. If you haven't then you've already bombed.

[devxpy]

Have you ever tried to implement the KMP (https://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93P...) pattern matching algorithm yourself?

I tried doing it -- even with the knowledge of how it works, it took me at least a day to get to an acceptable implementation.

[EduardoBautista]

OK, so you are just going to assume that any interview you can't pass is broken?

There have been interviews I have failed and instead of blaming the interviewers I took the time to actually study the problem I was given. This has helped me become a better programmer.

[devxpy]

No, i was just presenting a counter argument. I never had to actually implement KMP outside of uni though.

Interviews that require extra knowledge outside of what the job actually asks for are definitely broken.

[throwawaymath]

That has not been my experience as an interviewee. Implementing the naive solution for small n has been well received in my interviews, and from there (imperfectly) optimizing it is a collaborative experience.

I don't doubt you've experienced differently. But if you have, I think it's likely the interviewer, not the question. Lots of interview questions can be abused, not just basic algorithms and data structures questions.

[zanny]

Its incredibly frustrating to be in a room with someone who will pop whatever random trivia they want at you and watch you struggle against artificial constraints to appease them.

I'm loathing the potential need to ever eventually interview for a tech position because even on trivial things like Error trait impls in Rust I end up opening 3+ pages of documentation to verify I knew what I was doing at least, or often figure out better solutions with methods not on my brains hot path of solving the problem.

Theres nothing pleasant about having your tools taken away from you and then being looked down at when you are like a fish out of water. The OP even talks about it when describing the drain of technical interviews - nobody wants to be judged upon at their worst by strangers. Its humiliating.