It's about how well you ask questions, how well you listen to instructions, how well you work with others and interpret the specs and information you're given. Then it's about how well you adapt to changing or incomplete requirements, and how well you can explain yourself and your thought process.
Like so many tests in life it's not about the "answer", it's about the process you used to get there.
This is not the case 100% of the time, but it is often enough that if you’re interviewing in SF, particularly at startups, you will see it at least every few interviews. It’s ridiculous.
That's the great thing about an on-site interview, the evaluation goes both way.
When someone asks me to do then on a whiteboard in an interview setting they might as well dismiss me immediately.
Agreed.
But asking an algorithmic problem is usually not what you're going to solve on the whiteboard for the vast majority of jobs.
In most jobs, it's usually some variant of:
- We have some new feature, what's a good way to design it - We're trying to add this feature to this existing thing, what's the lowest impact way of modifying the existing code. - We've got an existing feature that has some problem (bug, complexity, performance), Is there a way to solve that, and perhaps the same entire class of problems across the application by implementing a known design pattern.
There's not a huge amount of novel thinking other than how to specifically glue existing libraries, design patterns and so forth, together with business specific logic.
Most whiteboard coding questions tend to be of the "Design an algorithm to solve an anagram" or "Implement a sort function" which don't relate to the job at all, and tell you nothing about the candidate's ability to do any of the things they're going to do day to day.
In a normal environment, when given a tough problem to solve, a whiteboard is like a scratch pad for ideas.
Out of that amalgamation of insights, comes the final solution.
When given a whiteboard, the interviewer ought to assess the thought process the interviewee is going through. Even if the outcome is wrong, if the thought process in acceptable, the solution will present itself eventually.
As an interviewer, I would also ask to list out the many ways one can solve a problem.
To me this is utmost important because in the real world, choosing one of the many ways to solve a problem is an important skill. The theoretically correct solution is not always the practical / implementable / cost-effective solution.
I do mind having to recall arbitrary algorithms on the spot.
Even then, you can avoid asking trickier algorithms as an interviewer.
But as soon as you have to write in an actual language it just becomes too painful.
Which is what most interviewers expect.
There is just no way for me to stay on point for all of four or five hours of successive grilling. It's a lot more exhausting than thinking about anything on my own