A while back, I came across a post by Philip Walton, who points out that most front-end interview questions aren’t well suited for their basic task of… well, testing a candidate’s front-end development knowledge. At least, the sorts of things he ran into were mostly “logical puzzles, generic coding challenges, and algorithm design problems”, as opposed to the kinds of questions that might test a candidate’s actual knowledge of front-end coding.
I’m happy at my current job, have been so for five years now, and don’t expect to be on the job market again any time soon. But if I were out there, I’m sure I’d run into more of those puzzles and brain-teasers. Like the one that runs:
You have N coins. They all weigh the same amount, except for one that is counterfeit. It might weigh slightly more, or slightly less, than the other coins. You have a balance, which can compare the weights of any two objects. How can you determine which is the counterfeit coin, using only X weighings?
Some time, I want to respond to that question about determining which of a set of coins is the “wrong” or “deviant” weight with a minimal number of weighings like so:
Me: Why only three weighings? Does it cost us money to use this scale or something?
Interviewer: Well, maybe not money, but it does take some time. So you could think of it as representing a way of minimizing how many CPU cycles the operation takes.
Me: Fair enough. But come on, are CPU cycles really that scarce? This might be a reasonable question to ask an Assembly or even C programmer, or if we were going to be working in an embedded system with limited resources. But seriously: You’re interviewing me for a client-side web development position. Any environment my code runs in has more than enough CPU.
Interviewer: Some people’s phones are kind of underpowered…
Me: No. Look, any environment my code is running in has a full, complete GUI running on it. That thing is using up so many more CPU cycles than a few extra comparisons, it’s not even funny. Sure, I should know about algorithmic complexity, and I should prefer constant-time algorithms, then O(log n) ones, then O(n) ones, before getting into O(n log n) or O(n2) ones. But shaving a few comparisons off one loop? That’s ridiculous. That’s optimizing for the wrong thing, namely, CPU cycles over programmer time and effort and brain-space.
If I ever need to know that particular algorithm, I can look it up. Which is why I’ve never bothered to learn it. But seriously, if I ever need to know that algorithm? Then we are doing something completely wrong, and probably at an architectural level.
This will probably not get me the job. That’s completely okay. That job is broken, because its interview process is broken — it’s selecting for the wrong thing(s). Which means everyone else at that job has already been selected on the wrong criteria.
I can’t fix that. The best I can do is keep my distance.
But if you’re using questions like that as part of your hiring process… think again. What are you selecting for? What do your coders actually need to know, and what are things that they will never, in a million years, need to use on the job?
And which of those things are your interview questions testing?
(By the way, if you want some decent front-end developer interview questions, you can find a bunch at https://github.com/h5bp/Front-end-Developer-Interview-Questions.)