The one I love is when they ask questions that are completely unrelated to what the position is for. e.g. I applied to a startup company that sold used cars online for a senior web dev position. Their junior dev asked me about a maze solving algorithm.
I knew the VP of engineering through one of my contacts and sent him an email asking him how a maze solving algorithm relates to web development. To his credit the VP apologized and set up another interview albeit with an even more junior developer who asked about finding loops in a linked list.
sigh
Thankfully I didn't take the job because the company shut down recently.
This happens a lot in data science too. Interviewers will ask the most esoteric and difficult questions they can come up with, and then half the time, if you get the job, you discover you're doing nothing but linear or logistic regression.
I agree with this mostly, but I've also heard that algorithms questions can be a good proxy for actual software engineering skills. I've never validated this claim but I'm curious if anyone has any research on either side of the argument.
> but I've also heard that algorithms questions can be a good proxy for actual software engineering skills.
In my world (Line of Business/SME) they aren't, I used to know the exact properties of a doubly linked list and all that stuff but I haven't had to think about it for 18 years.
The question I've had the most success with at predicting if someone will be a good dev (in my domain) is some variant of :-
> "I run an electrical testing company, I want a system to manage my engineers, ask me the questions you'd ask a client"
If the response is "How many engineers, how many sites, how quickly are you expanding, do you need this to be available on foo/bar etc" then they are showing the skills they need, it's not about them having good answers but knowing how to ask good questions.
Others I like are "Tell me about the worst bug you ever wrote and how you figured out the fault" and here is some code, what would you do to improve the quality, looking for things like refactoring large methods, consistent comment style, fixing indentation.
That gives me a hugely more useful insight into whether someone will be a good developer over "Explain to me in detail the thing you might have been lucky enough to have boned up on two days ago or might not and will never have to use".
The dirty secret is that (for most of the programmers in my domain) you don't need to be some algorithm wizard who can tell you the O(n) time of the Spasky-Fischer Recursive Tree Search, you need to be able to write clear, concise code that shows intent and is going to maintainable in a year.
This is anecdotal but in my experience a better signal is whether the candidate codes with best practices in mind. Give a moderate complexity design problem and watch for use of best practices/design patterns (good commenting, SRP, DRY, DI, IOC, etc). That tells me the code that person will write can be understood and maintained by someone else. After all the person who wrote the code is not necessarily the person who's going to maintain and enhance it for the lifetime of the application.
I knew the VP of engineering through one of my contacts and sent him an email asking him how a maze solving algorithm relates to web development. To his credit the VP apologized and set up another interview albeit with an even more junior developer who asked about finding loops in a linked list.
sigh
Thankfully I didn't take the job because the company shut down recently.