5 ms·
I'm actually in the middle of a bunch of interviews right now. The most ridiculous interview process I encountered so far was one that was supposed to be 7 (!!)
by lewisl9029 10y ago
I'm actually in the middle of a bunch of interviews right now. The most ridiculous interview process I encountered so far was one that was supposed to be 7 (!!) steps long (that usually takes 3-4 weeks by their own estimates), beginning with a 45 minute HackerRank challenge, then a technical project that was said to take 2-5 hours on average (but the time given was a whole week, so I have my doubts about that estimate), followed by up to 4 Skype calls, and finally an onsite.
The HackerRank challenge consisted of two relatively trivial multiple choice problems, a simple FizzBuzz-level coding problem, and a programming puzzle. And I do mean programming puzzle. I consider it a puzzle in the sense that it had very little to do with any classical CS domain I'm aware of (although that may just be an artifact of my own ignorance, but to someone unaware of that domain like myself, it as might as well just be a puzzle) and certainly wasn't anything one would ever encounter in front-end development (I was applying as a front-end engineer). I later found the problem online and here's a thread discussing it for those interested (the company I interviewed with wasn't Google though): http://stackoverflow.com/questions/28967020/check-if-there-exists-a-circle http://stackoverflow.com/questions/28967020/check-if-there-e...
I finished the 2 MC questions and first coding problem within the first 5 minutes, but I wasn't able to finish the programming puzzle in the time remaining (For what it's worth, I was on the right track with my approach, but it took me a lot of trial and error to arrive at that approach, so I didn't have enough time left to finish the implementation). I got my rejection email two days later.
I really question the wisdom of using a programming puzzle like this as a filter in the first step of your interview process (or really, in any step of the interview process for that matter). You're effectively discarding candidates solely based on their inability to solve an esoteric programming puzzle under some arbitrary time constraint.
Although at the end of the day, I'm not that disappointed in this early rejection. If this programming puzzle was a sign of things to come in the next 6 steps of their interview process, I think I may have dodged a bullet. That could have been so many hours of my life that I'd never get back. Good riddance I say.
- penguinduck 10y agoYou dismiss this as "esoteric", but that's the whole point, the purpose of a puzzle like this is for you to be unable to map it to something you've done previously or to something you learned in school, and instead to force you to invent an algorithm on your own. It is the opposite of what the author of the article complains about - "academic", "targeted at cs grads" - it goes against that. It is an attempt to test problem-solving ability by removing knowledge from the equation. Knowledge can then be tested separately. Fresh CS grads are not going to do better on this problem than a guy who graduated 10 years ago. In fact, this is the kind of problem given to children (who can't be expected to have CS knowledge, and you don't want to give a big advantage to those who happen to have some) in programming competitions. I would put the difficulty at either easy problem for high schoolers or difficult problem for elementary schoolers (this doesn't mean it's super-easy, these problems have to be relatively hard or the smartest kids would all solve everything). I am not sure why so many developers dismiss the value of this and are in fact often actively hostile to any suggestion that it might be ONE of the indicators of programming ability. I do agree that the time constraint was probably too strict and favors people who've solved stuff like this before, mainly due to them knowing they should try to solve this with a pen and paper or in their head, then just code the solution once they've found it. Trial and error through code is a huge waste of time and this was probably your problem.
- lewisl9029 10y ago> I am not sure why so many developers dismiss the value of this and are in fact often actively hostile to any suggestion that it might be ONE of the indicators of programming ability. No disagreement there. I certainly wasn't trying to dismiss the ability to come up with novel solutions to problems never encountered as an indicator for programming ability and general intelligence completely. However, I certainly don't believe it's a good enough indicator to use as the sole basis for simply rejecting otherwise perfectly capable candidates before you've even talked to them. I'm also of the opinion that interviews should strive to assess how well candidates can perform on the specific position you're hiring for (that is the main purpose of interviews, is it not?). In my own case (I was applying for a front-end engineer), and in the case of most other engineering positions, I don't believe puzzle solving is a very useful indicator for that purpose, because an overwhelming majority of engineering tasks involve applying the scientific method and engineering knowledge to solve variations of well-known engineering problems in their specific fields. EDIT: Another point that I forgot to mention: If you are in fact interested in a candidate's ability to solve novel problems they've never encountered, at least do a better job of ensuring the problem you give them is actually novel. I found the StackOverflow thread for the problem they gave me in about 30 seconds of Googling. By not ensuring the problem novel enough that searching for it won't do you any good, you're going to be disproportionately passing dishonest candidates who would simply cheat to get through this part of your process. Certainly that can't be the result you're looking for.
- penguinduck 10y agoRegarding the first, I think they basically do this to test how "programming smart" someone is. Like my boss tells me when I interview, "determine potential". However, I agree that this shouldn't disqualify someone for a more technical kind of job. For me it is more of a "if he is really smart we should hire him despite the fact he is perhaps unqualified, he will easily learn" thing. The disqualifying questions are easier than this one. Regarding the second, I agree completely. This problem is good because it doesn't give an advantage to rote memorization of basic CS from college (unlike asking about red-black trees etc), but when stolen from the internet and reused becomes bad because it gives an advantage to something worse - googling questions and memorizing answers. I assume (or hope) Google switches up the problems they use all the time and hopefully doesn't use automated testing (because I care how someone thinks, not just whether they produce the solution in X minutes), but since you interviewed at a different company perhaps it is a cargo cult effect: Google has some of the smartest programmers and they asked this, so obviously we should also ask the same thing! Cargo culting is extremely common in IT in less-established companies, my workplace is not immune to it either. Pick things a super-successful company does that require almost zero investment, effort or true change, and copy those. It is ridiculous. Of course, the things these companies really do right, they are too much effort, let's just copy them in superficial ways and hope for the best!