6 ms·
> It might not give you a very good insight in to an applicant. I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either.
by dvt 9y ago
> It might not give you a very good insight in to an applicant.
I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it.
> Most people's public code is of roughly equal quality (eg 'not great').
I disagree with this. Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month.
> Building a great team is about hiring great people more that just great developers.
I completely agree. So why do we dehumanize potential hires with standard practices that involve (for example) memorizing algorithms you'll never use? I mean, HackerRank is a testament to how awful our culture is. Is there a DoctorRank or SecurityGuardRank or WaiterRank?
> It's hard to trust someone's public code.
I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
- onion2k 9y agoI'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it. The fact that some companies use bad practises for hiring doesn't change how hard it is to judge someone's code from their Github repo. I agree that whiteboard tests are horrible, but switching to a different bad idea wouldn't help. Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month. You're moving the goal posts from "Has code in public" to "Launched, contributed to, or otherwise involved with a successful open project." That's quite different, and arguably a lot of hiring managers do look at that sort of thing very favourably. I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored. I'll defer to Max's own explanation for that: https://www.quora.com/Whats-the-logic-behind-Google-rejecting-Max-Howell-the-author-of-Homebrew-for-not-being-able-to-invert-a-binary-tree/answer/Max-Howell?share=100e0bb6&srid=x8w https://www.quora.com/Whats-the-logic-behind-Google-rejectin... As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. We can question whether or not Google needed to ask that in the interview, but they clearly thought it was important enough for the role Max was applying for to ask it. So maybe rejecting him for that role was the right decision. We don't really know. We do know that he wasn't applying to Google for the job of "Homebrew Maintainer" so his work on Homebrew, while really impressive, isn't really the whole story in hiring him. Surely you're not suggesting that the author of a successful project should be able to walk in to any developer role regardless of what's needed to do the job?
- collyw 9y ago"As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. " Maybe Google is different but I usually need to do computer cine type stuff about one a year.I have used recursion on maybe 4 different occasions in my carreer, but that's the sort of thing that comes up regularly in coding tests. Why not test for things that are actually being used on the job?
- onion2k 9y agoSome Google engineers work on the sort of problems, and at the sort of scale, where algorithms and the science that drives them actually makes a difference. I don't think it's unreasonable for Google to ask computer science questions in interviews where that's the case.
- FLUX-YOU 9y agoSome do, but instead of allocating you to a correct position for your skills based on your performance in the interview, you just get outright rejected, which means you have to try again and again until you find a position which happens to give an interview which you can pass.
- kod 9y agoSo you've only used json, or html, or (insert recursive data structure here) 4 times in your career? Seriously, recursion is everywhere.
- pennaMan 9y agoAm I flexing my electrical engineering skills when I turn the TV on with a remote control? Parsing a json tree uses recursion under the hood but unless you are writing a new json parsing library each month you won't get the chance to use those recursion skills too often when dealing with json in day to day code.
- Delmania 9y ago
- walrus1066 9y ago'I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it.' I've (thankfully), never had to whiteboard. Think it's a US/SF thing. That these interview techniques are determined so much by culture, fashion, and following what the successful companies do (I.e. Google), in itself shows how useless they are. That said, I acknowledge I can't think of a perfect way to assess software engineers. We have a take home exercise, but ultimately gut feel drives the decision.
- kamaal 9y ago>>I've (thankfully), never had to whiteboard. Think it's a US/SF thing. And that has spread all over the world now, because a lot of companies outside of SV, tend to view these BigWebCo's as something to emulate and imitate from, and are doing these whiteboard interview all the time. In fact the whole point of these Hacker rank kind of sites is to basically provide the web equivalent of a white board. You are asked to submit code(Typically some question based on a exaggerated edge case of some algorithm) and see if it passes all test cases. You are in if it does, out otherwise.
- scarface74 9y agoI've had to do one whiteboard coding exercise in my entire career. I knew two other devs that had interview at this company, so I knew what to expect. I accepted the in person interview on a whim. I already had accepted an offer as the dev lead for another company. The whiteboard interview was to write out algorithm for a merge sort. I thought it was the silliest thing in the world. I had already accepted a position to basically create a development department, and he wants me to write a sort algorithm? Once he described how it worked, I wrote it without much difficulty but that was a turn off and I got an offer that was permanent (as opposed to contract to perm for the offer I accepted), making more money, with a signing bonus. It was such a turn off, I declined the offer for a chance to build a department that would not expose developers to this foolishness and thought that the interview process tells you a lot about the company. A year later. I'm glad I made the choice I did. On the other hand, I've done quite a few pair programming type of interviews where there was a skeleton of a program with a lot of failing unit tests you had to make pass. I enjoy those. Is there a DoctorRank or SecurityGuardRank or WaiterRank?* Doctors have to go to school 8+ years and do a 2-4 year residency before they can practice without supervision. Lawyers have to go to school 7 years and pass an exam. Software Engineers only have to watch a couple of YouTube videos and they can call themselves "programmers". Doctors can't say they are qualified because they have been doing brain surgery since 6th grade in their bedroom.
- zimpenfish 9y ago> The whiteboard interview was to write out algorithm for a merge sort. I thought it was the silliest thing in the world. Last one I had was to implement QuickSort. Had a -huge- argument with the interviewer who insisted there was an off-by-one error and it would never work. Needless to say, he was thoroughly wrong once it was coded up and I didn't get the job. :) > It was such a turn off It's pretty much an automatic "no" for me now too.
- justinhj 9y agoWhen the interviewer gets angry (wrong or right) I take that as a useful filter not to work there
- 9y ago