Towers of Hanoi seems eminently studyable: the kind of interview question where if you’ve memorized the standard answer, or just the trick (“solve Towers of Hanoi with recursion reducing the size of the stack of discs”), you’ll ace the question, but if you have to figure it out from scratch, it may take you an arbitrarily long time, even if you’re super smart. Worse, it’s a problem which never comes up in practice, unless the temple in Kashi Vishwanath actually existed at some point.
For these reasons I think it’s probably a bad interview question.
Was ‘towers’ actually an interview question? Or was it just something the OP went deeper into after mentioning recursion in simple interview questions?
That’s what I thought of it, too.
I feel this way about dynamic programming questions in general. Know the trick and/or study the ten or so archetypical questions, breeze through the interview. But there’s little chance you’ll derive the optimized solution from first principles. In either case the signal the interviewer get from the interview is pretty much worthless.
I want to point out that Towers of Hanoi is not normally solved via dynamic programming.
i have been giving plenty of interview and participating in hiring drives in the last two months (graduating soon, looking for jobs) and i noticed most companies have first rounds of some kind of competitive programming and sometimes tests at www.hackerrank.com but are they actually useful skills for a potential employee?
The results of these tests favor people who have been practicing all the common problems in competitive programming and not writing productive code. When i have a difficult problem to solve, i think about it for a while, find different
solutions and implement the best one (based on elegance, simplicity and performance).
Do recruiters want people who write usable code or who can write a solution under 20 minutes?