I'm one of the people who ask those algorithm/white board questions. I've read a lot criticism on this topic, here're my reasons to stil keep asking these questions:
1) Working on algorithm problem requires very little in common between interviewer and interviewee. I'm C++/C#, I won't be able to give Ruby dev a real world task and evaluate it properly. Algo/data structure problems are universal and looks similar in any language.
In my practice I completely failed to make any conclusions by talking about previous experience. It was not clear to me what person actually did vs what was already on the project, may as well just fixed couple UI bugs on the complex project. This part might be might personal failure as interviewer, but it was it is, and I've seen enough developers with years of experience who barely code. So unfortunately having great resume doesn't prove anything.
2) Everyone knows that big tech companies ask these questions. Knowing that you didn't take to prepare, says one of two things to me: you don't find it interesting topic/usefull or you don't have enough grit to go thru that.
When I prepared for the interview I went thru two algo books, it took some time but it was easy for me, I did enjoy the learning part, yes it's not something I use every day. But learning things is a trait of good developer, knowing fundamentals if part of that. Some folks found it useless, but since it's known fact that's being asked on interiewes, motivated developer would spend time and learn it. Over the years at work, we have to learn things that are not interesting and that I'd rather choose not to know at all, same as algorithms to some people. If you can't make yourself learn algorithms to pass interview, likely you wont learn things for the work too.
Your first point suggests these questions have some value for you in identifying people's skills. Fair enough.
Your second argument admits that this is basically a hazing ritual. Of course you will have to learn some things you don't intrinsically care about in the course of your work. The difference is, that isn't part of a process that we intentionally designed to be that way. Admitting that your hiring process requires useless knowledge that people just have to learn to get through the process means you admit your process doesn't measure what matters and is just a hazing ritual. You're putting up hoops just to see who will jump through them.
You can't make conclusion just from second argument alone. It's not hazing ritual because my first point. But I also think knowing them is useful, but I see a lot of people arguing it not needed at all. So what I tried to say in second, that regardless of what one thinks on usefulness of Algo knowledge,there's no excuse to ignore algorithm and expect to pass interviews.
If you think it's not necessary for the job but it's necessary for the interview, then at least we can agree the interview process isn't so great.
Of course, knowing how to play the system is part of getting a job, but we can still point out that the system is broken. After all, these are systems we set up ourselves.
As a fellow engineer who also performs technical interviews, I cannot accept your first point.
Solving trivial problems does not give you any useful information about how a person solves nontrivial problems. This is especially true if you are not specifying the language the candidate needs to use.
What if I solved fizzbuzz in Haskell? It certainly would not look like a c# implementation, and you wouldn't be able to judge anything about it other than maybe it might produce a correct answer- is it idiomatic? Is it performant? Will it even compile? Technical interviews (especially when you consider candidates outside of your current language / stack) are about assessing capability and trajectory - willingness to learn and adapt. Rote memorization of objective problems that can be found online tell you nothing about how they will solve problems on the job.
As for point two, memorizing solutions to problems with objective answers isn't a terribly valuable skill; presuming that it should be a requirement without announcing it in the job requirements is certainly analogous to hazing. Unless you want a team with little to no creativity, you are selecting for candidates that do not demonstrate what you actually need- and the success of your team is in spite of your hiring process, not enabled by it.
I am sorry if this came across as either personal or exceptionally harsh, but I am pained by the amount of incredibly intelligent people who are willing to accept that suboptimal things ought to be, simply because they are.
One of the biggest contributing factors for a team's - and company's- culture is its hiring practice, and it deserves far more attention than what our industry gives it.
Yeah I'm not arguing it's suboptimal, but I don't see better suggestion. What are you doing instead?
"Assessing the capabiliyt and trajectory, willing to learn and adapt" - that's the intent of the algo/data sturcture related questions. The questions are not about knowledge of specific algo, but assess way of thinking and write some code. Typically solution include recursion, nested loops, pointers/references, some not-trivial composition, etc. I'm never expecting candidate to know the specfici algorithm righ away.
I'll address your second paragraph before returning to your first question- I think my answer will be a little more cohesive that way.
The fundamental problem with whiteboard / live coding technical interviews is that you're selecting for candidates whose strengths aren't necessarily useful on the job.
They:
- have memorized answers to solved problems
- work well under immediate pressure
- demonstrate knowledge of basic programming techniques
They do not:
- demonstrate collaboration
- demonstrate researching and gathering requirements (i.e. no access to the internet)
- demonstrate planning or reasoning about business requirements
In short, yes, they're solving problems, but they're not solving the same kinds of problems that you'll need them to solve on the job, nor are they solving them in the same way they'll be solving them on the job.
These interviews select based on superficial qualities, and practically ignore the qualities of top candidates (teamwork skills, interpreting technical requirements from business requirements etc.)
I had typed out a lengthy explanation of the process I'm currently using, but I realized I don't want to go too deeply into the weeds. In short, design a small challenge application for candidates to build, with the expectation that it'd take no more than a handful of hours, and let them turn it in on their own time (say, within a week). If they "pass", bring them in for a second, technical interview, which is a conversation based on what they submitted (i.e. how could they do X better, how would they add new feature Y, etc.)
The benefit of that kind of process are numerous:
1- The time commitment of candidates is the same as a long whiteboard interview (or set of them), and they don't need to commit to all of the time at once (takes less time away from their current engagements)
2- The time commitment of employees is reduced to ~2-3 hours (one to evaluate, one to interview)
3- candidates are building a small application, meaning there's not an objective answer to be found on stack overflow to memorize
4- candidates have time to ask questions and demonstrate skills they are passionate about, but might not have been specifically requested- say, testing, user experience, flexible architecture to support future features, that sort of thing
5- The second interview becomes a relaxed conversation, where a broader selection of engineers perform well, as opposed to the more biased high-pressure scenarios that aren't typical of our day-to-day
To do this well, of course, you ought to review the challenge and process each year, and have (preferably junior) employees test it to ensure that it will be respectful of candidate's time commitments and the value of the information the challenge will provide an evaluator. Given that you want to keep it limited to a few hours, you'll need to balance features that you think will be interesting with features that actually yield interesting information about the candidate for a second interview- anything that can be learned by simply asking a question doesn't actually need to be included.
Finally, to return to the original topic of this thread, you potentially eliminate certain cultural biases that are irrelevant; not only is the candidate demonstrating capabilities more reflective of the job itself, but they are doing so before ever meeting in person.
1) If you're trying to hire a Ruby developer to write Ruby applications and that's not what you're screening in interviews, you're not proving anything relevant to the candidate's ability to do the real world job. Between not having anyone to interview and an algorithm interview, I get where you're coming from. But if there is any other choice, you shouldn't be giving the technical interview to someone whose practical skills you can't assess.
2) There are a billion things to learn as a technology professional. The time you spend practicing specifically to be able to whiteboard algorithms for interviews is time you're not spending doing something else. Something that will be more beneficial to you and to your business on a day to day basis than learning how to interview well. So choosing to do those other things instead doesn't show that you're not engaged.
Yes if you need specificly Ruby dev, you ask Ruby (though only if you need it now right away, may as well hire contractor for a few months in this case). Imho smart developer can pick up Ruby fast (or other stack fast) and that's the benefit of algorithm related question - you don't have to pass on candidate that don't have experience in your stack.
1) Working on algorithm problem requires very little in common between interviewer and interviewee. I'm C++/C#, I won't be able to give Ruby dev a real world task and evaluate it properly. Algo/data structure problems are universal and looks similar in any language. In my practice I completely failed to make any conclusions by talking about previous experience. It was not clear to me what person actually did vs what was already on the project, may as well just fixed couple UI bugs on the complex project. This part might be might personal failure as interviewer, but it was it is, and I've seen enough developers with years of experience who barely code. So unfortunately having great resume doesn't prove anything.
2) Everyone knows that big tech companies ask these questions. Knowing that you didn't take to prepare, says one of two things to me: you don't find it interesting topic/usefull or you don't have enough grit to go thru that. When I prepared for the interview I went thru two algo books, it took some time but it was easy for me, I did enjoy the learning part, yes it's not something I use every day. But learning things is a trait of good developer, knowing fundamentals if part of that. Some folks found it useless, but since it's known fact that's being asked on interiewes, motivated developer would spend time and learn it. Over the years at work, we have to learn things that are not interesting and that I'd rather choose not to know at all, same as algorithms to some people. If you can't make yourself learn algorithms to pass interview, likely you wont learn things for the work too.