5 ms·

> Don't worry—we'll skip the convoluted academic jargon and proofs. Aaaaand this is why I hate using this as a method for interviewing. I actually care a great

> Don't worry—we'll skip the convoluted academic jargon and proofs. Aaaaand this is why I hate using this as a method for interviewing. I actually care a great deal about people that care about that stuff. I would rather you know all the principles and can reason your way back up, however slowly, than repeat something you've practiced enough for an interview. I understand the author really only wants to help people, but let me tell you as someone who works for one of the "cool unicorns" that the quality of software engineers is really bad, most likely because of this efficient "gaming of the system".

__sr__ 9y ago
People don't have a choice but to game the system. If you can't solve the problem quickly enough on a whiteboard, you are rejected. You are typically not given enough time arrive the solution from a scratch. You either know the solution or you don't. I agree with you, this method for interviewing sucks.
Mutinix 9y ago
It's unfortunate, but all the companies are doing this. Here's what a Google lead said in a tweet: > Hello, my name is Tim. I'm a lead at Google with over 30 years coding experience and I need to look up how to get length of a python string. DHH: > Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles. Max Howell: > Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off. And yet, everyone is asking these questions about print a string in zigzag fashion or something silly like that. Engineers are gaming the system because the system is garbage. None of us are looking forward to waking up and solving HackerRank, LeetCode and CtCI problems till the joy of programming leaves our bodies.
- j2kun 9y ago
  There's a difference between not being able to write bubble sort and realizing that looking it up is a better use of your time. But when it actually comes time to do something you can't copy/paste off the internet, what do you expect a programmer who can't reinvent a half-decent bubble sort to do? The interview is to convince the other person that you can think logically about programs. Bubble sort is a low, low bar, and basic data structures are not much higher.
  - Mutinix 9y ago
    Maybe he's being hyperbolic, maybe not. But that's entirely besides the point. I'm absolutely certain that there are many, many engineers who failed interviews because they couldn't write a zig-zag string and could yet come up with good solutions to problems at a real company. > what do you expect a programmer who can't reinvent a half-decent bubble sort to do But interviews aren't testing for that. The guy who invented Homebrew was judged by a Google engineer to be not good enough. Heck, I bet the engineer interviewing him probably had his/her entire dev machine setup via Homebrew. DHH invented Ruby on Rails, which was used at Twitter for what, 4+ years? And yet if he anonymously gave an interview at Twitter they would probably reject him because he can't find a cycle in a linked list in 30 minutes. > The interview is to convince the other person that you can think logically about programs. It's supposed to be about that. The modern CS interview is, however, absolutely not about that. It's whether or not you've grinded through CtCI enough to be able to answer something taken from a vast pool of useless questions. Tell me, is the Homebrew guy just really not good enough? Do you really think he does not know how to think about programs logically?
    - narak 9y ago
      Good CS fundamentals are important because they are transferable skill to a wide array of problems a startup may face. Just because someone wrote an impressive framework or library doesn't mean given a complex problem outside of their known domain (web framework design or package management tool), they would be have the necessary background to solve it. With strong math and CS knowledge, you can reason through almost any problem.
      - Mutinix 9y ago
        > Good CS fundamentals are important Yes they are. Except, these interviews aren't testing for that. Finding the maximum sum subarray isn't testing for any fundamental. > Just because someone wrote an impressive framework or library doesn't mean given a complex problem outside of their known domain Why are you even hiring them for something that's not their expertise? Seriously, that's literally the whole point of the interview. I don't think Max Howell was trying to get in to the DeepMind team. Calling these just some other web framework or package management tools is doing them an incredible disservice. Twitter used Rails. Airbnb uses Rails. If Airbnb hired DHH, it would be Airbnb's fault if they made him tune hyperparameters of some ML model rather than see how their web performance could be improved. Honestly, at this point I'm convinced I could get HN to talk poorly about John Carmack's programming skills.
- smnscu 9y ago
  Ah, the perennial apologetics of weaponized mediocrity. If you can't write a simple recursive algorithm that swaps two values (Max Howell), two nested for loops (DHH), or show me that you used Python at least once (uhh length? yes, there is this builtin, I forgot its name...), why would I want to hire you over someone who has seen a computer before? And to avoid being called hypocritical, here's off the top of my head how the answers would look like (I don't use Python very often either): 1. len(thingie) 2. def bubsort(arr): if not arr: return None for i in range(len(arr)): for j in range(i+1, len(arr)): if arr[i] > arr[j]: arr[i], arr[j] = arr[j], arr[i] return arr 3. def revtree(node): if not node: return None node.left, node.right = revtree(node.right), revtree(node.left) return node edit: works well for something coded on the toilet: https://gist.github.com/andreis/69a242330617b2a62753ce604e276c0d https://gist.github.com/andreis/69a242330617b2a62753ce604e27...
  - Mutinix 9y ago
    > why would I want to hire you over someone who has seen a computer before? Because, you know, they invented Ruby on Rails and Homebrew? Incredible, really. You were so adamant on being hostile that you managed to put yourself over Max Howell and DHH in a couple of sentences. These people have made valuable contributions to the tech industry as it stands today. This is a fact and not an opinion. They invented Homebrew and Ruby on Rails. Good job, you solved the problems and are more likely to be hired by Google than Max Howell. Except he created the most popular package manager in OSX history and companies still can't see that.
    - cakedoggie 9y ago
      Not everybody can say that though.
    - dozzie 9y ago
      > Except he created the most popular package manager in OSX history and companies still can't see that. First, Homebrew is just a rehash of package managers that were available on unices for more than a decade. Then, from what I hear, Homebrew was (still is?) badly designed and implemented for quite a long time, which is not an evidence of author's high skills (as a programmer, anyway).
0xADEADBEE 9y ago
...and we've come full circle. The industry demonstrably brought this upon itself by cargo-culting Google's interview process; combine an environment where people are expected to know how to invert a BST for a Django or Rails job with a group of people who are naturally inclined to optimise and shortcut and this is exactly what you can expect to happen. From a personal perspective, if I were to decide to switch jobs, I'd break out Cracking the Coding Interview rather than reading papers detailing how best to implement a Splay Tree because it's simply a better use of my time for the task at hand. I'll cheerfully read the latter on my own time, but not in preparation for an interview. I don't see this culture changing anytime soon. 1) it's difficult to make an industry-wide shift and 2) more crucially, no-one has found a better way of doing it. It'll be interesting to watch though.
- BurningFrog 9y ago
  > no-one has found a better way of doing it Some people definitely do hiring in different ways. Time will tell if they're actually better.
- seanmcdirmid 9y ago
  Hey, Microsoft was doing this long before google even existed.
  - thaumasiotes 9y ago
    I thought the traditional Microsoft interview was more along the lines of "how many golf balls fit in an airplane?"?
    - stevenwoo 9y ago
      I interviewed at Microsoft in 1990 for a software test position and no one asked me a puzzle question so it had already gone out of style by then at least for my interviewers. They asked me a couple of questions that I recently recognized on the leetcode interview questions list in the easy section.
    - 9y ago
GuiA 9y ago
Do you care a great deal about that stuff because the job you're recruiting for legitimately needs it, or are you hiring people to crank out Rails/Django/React.js/etc. to add a few more textfields on a webpage? Because many people who are in the latter camp think they are in the former, and that's what got us to where we are. There's nothing wrong with the latter, btw. Just that if your job is 90% copy pasting from the React docs and 10% coming up with a clever solution based on academic papers, then it's a much better use of your time to hire people who seem like they can get shit done and train & mentor them, rather than trying to hire the ultimate programmer who will ace your amazing question in exactly the time allotted, saying exactly what the interviewer wants to hear. (the people who read academic papers over breakfast would much rather be at a job where the 90/10 split is the other way around, and will jump ship in the blink of an eye if they've been misled about the job)
taeric 9y ago
To be fair, I am incredibly interested in the jargon and proofs. What I am not, is proficient in doing them on a whiteboard. Therefore, I do not expect someone else to be. More, many of the interesting proofs that folks know took a long time to develop. Sure, you could probably throw some up on the board and speak to it. No, you are not likely to be able to derive one. And, I highly doubt that without practice would you be able to even get it on the board correctly. Which brings up a major point. Discuss more in code reviews. Don't polish them trying to make them perfect. Make them part of your conversation with your peers where you are. I personally even feel recommend to throw up straw men sometimes. It can be odd throwing up a review for the team to see an idea on code you don't intend to push, but it can also be a good conversation. And someone else may be able to take that idea and make it awesome. Which is ultimately what I want from a coding interview. If you have to handwave over parts, fine. Just be up front about it and hide it behind a function call. I may ask you to drill in on that function, but the key is to get valid code. Not necessarily complete code. (Obviously, YMMV.)
deleted 9y ago
[deleted]
rdtsc 9y ago
I interviewed at some of these companies that liked the puzzles and so on. Then got to a company that actually seemed interested in stuff I've done before and asked enough details to know that I knew the stuff. I learned about what they did and seemed interested and got the job. Puzzles and tricks are like that are a crutch, because people don't know how to talk and find out about what the other person knows. Usually what happens if a company becomes successful is they codify whatever they did to get there in stone and that becomes "the golden process" by which everything must be one. If they hired people who knew how invert a binary tree or some stuff like that, they assume they become successful because of it. I would usually think they became successful in spite of it. At the end of the day there are people who will sit and drill interview questions for months and years and maybe that's what companies want, people who are desperate enough to do that work. Maybe that's what the tests really test for ...
- pertymcpert 9y ago
  > I would usually think they became successful in spite of it. What...
  - rdtsc 9y ago
    That...

__sr__ 9y ago

People don't have a choice but to game the system. If you can't solve the problem quickly enough on a whiteboard, you are rejected. You are typically not given enough time arrive the solution from a scratch. You either know the solution or you don't. I agree with you, this method for interviewing sucks.

Mutinix 9y ago

It's unfortunate, but all the companies are doing this. Here's what a Google lead said in a tweet: > Hello, my name is Tim. I'm a lead at Google with over 30 years coding experience and I need to look up how to get length of a python string. DHH: > Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles. Max Howell: > Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off. And yet, everyone is asking these questions about print a string in zigzag fashion or something silly like that. Engineers are gaming the system because the system is garbage. None of us are looking forward to waking up and solving HackerRank, LeetCode and CtCI problems till the joy of programming leaves our bodies.

j2kun 9y ago
There's a difference between not being able to write bubble sort and realizing that looking it up is a better use of your time. But when it actually comes time to do something you can't copy/paste off the internet, what do you expect a programmer who can't reinvent a half-decent bubble sort to do? The interview is to convince the other person that you can think logically about programs. Bubble sort is a low, low bar, and basic data structures are not much higher.
- Mutinix 9y ago
  Maybe he's being hyperbolic, maybe not. But that's entirely besides the point. I'm absolutely certain that there are many, many engineers who failed interviews because they couldn't write a zig-zag string and could yet come up with good solutions to problems at a real company. > what do you expect a programmer who can't reinvent a half-decent bubble sort to do But interviews aren't testing for that. The guy who invented Homebrew was judged by a Google engineer to be not good enough. Heck, I bet the engineer interviewing him probably had his/her entire dev machine setup via Homebrew. DHH invented Ruby on Rails, which was used at Twitter for what, 4+ years? And yet if he anonymously gave an interview at Twitter they would probably reject him because he can't find a cycle in a linked list in 30 minutes. > The interview is to convince the other person that you can think logically about programs. It's supposed to be about that. The modern CS interview is, however, absolutely not about that. It's whether or not you've grinded through CtCI enough to be able to answer something taken from a vast pool of useless questions. Tell me, is the Homebrew guy just really not good enough? Do you really think he does not know how to think about programs logically?
  - narak 9y ago
    Good CS fundamentals are important because they are transferable skill to a wide array of problems a startup may face. Just because someone wrote an impressive framework or library doesn't mean given a complex problem outside of their known domain (web framework design or package management tool), they would be have the necessary background to solve it. With strong math and CS knowledge, you can reason through almost any problem.
    - Mutinix 9y ago
      > Good CS fundamentals are important Yes they are. Except, these interviews aren't testing for that. Finding the maximum sum subarray isn't testing for any fundamental. > Just because someone wrote an impressive framework or library doesn't mean given a complex problem outside of their known domain Why are you even hiring them for something that's not their expertise? Seriously, that's literally the whole point of the interview. I don't think Max Howell was trying to get in to the DeepMind team. Calling these just some other web framework or package management tools is doing them an incredible disservice. Twitter used Rails. Airbnb uses Rails. If Airbnb hired DHH, it would be Airbnb's fault if they made him tune hyperparameters of some ML model rather than see how their web performance could be improved. Honestly, at this point I'm convinced I could get HN to talk poorly about John Carmack's programming skills.
smnscu 9y ago
Ah, the perennial apologetics of weaponized mediocrity. If you can't write a simple recursive algorithm that swaps two values (Max Howell), two nested for loops (DHH), or show me that you used Python at least once (uhh length? yes, there is this builtin, I forgot its name...), why would I want to hire you over someone who has seen a computer before? And to avoid being called hypocritical, here's off the top of my head how the answers would look like (I don't use Python very often either): 1. len(thingie) 2. def bubsort(arr): if not arr: return None for i in range(len(arr)): for j in range(i+1, len(arr)): if arr[i] > arr[j]: arr[i], arr[j] = arr[j], arr[i] return arr 3. def revtree(node): if not node: return None node.left, node.right = revtree(node.right), revtree(node.left) return node edit: works well for something coded on the toilet: https://gist.github.com/andreis/69a242330617b2a62753ce604e276c0d https://gist.github.com/andreis/69a242330617b2a62753ce604e27...
- Mutinix 9y ago
  > why would I want to hire you over someone who has seen a computer before? Because, you know, they invented Ruby on Rails and Homebrew? Incredible, really. You were so adamant on being hostile that you managed to put yourself over Max Howell and DHH in a couple of sentences. These people have made valuable contributions to the tech industry as it stands today. This is a fact and not an opinion. They invented Homebrew and Ruby on Rails. Good job, you solved the problems and are more likely to be hired by Google than Max Howell. Except he created the most popular package manager in OSX history and companies still can't see that.
  - cakedoggie 9y ago
    Not everybody can say that though.
  - dozzie 9y ago
    > Except he created the most popular package manager in OSX history and companies still can't see that. First, Homebrew is just a rehash of package managers that were available on unices for more than a decade. Then, from what I hear, Homebrew was (still is?) badly designed and implemented for quite a long time, which is not an evidence of author's high skills (as a programmer, anyway).

0xADEADBEE 9y ago

...and we've come full circle. The industry demonstrably brought this upon itself by cargo-culting Google's interview process; combine an environment where people are expected to know how to invert a BST for a Django or Rails job with a group of people who are naturally inclined to optimise and shortcut and this is exactly what you can expect to happen. From a personal perspective, if I were to decide to switch jobs, I'd break out Cracking the Coding Interview rather than reading papers detailing how best to implement a Splay Tree because it's simply a better use of my time for the task at hand. I'll cheerfully read the latter on my own time, but not in preparation for an interview. I don't see this culture changing anytime soon. 1) it's difficult to make an industry-wide shift and 2) more crucially, no-one has found a better way of doing it. It'll be interesting to watch though.

BurningFrog 9y ago
> no-one has found a better way of doing it Some people definitely do hiring in different ways. Time will tell if they're actually better.
seanmcdirmid 9y ago
Hey, Microsoft was doing this long before google even existed.
- thaumasiotes 9y ago
  I thought the traditional Microsoft interview was more along the lines of "how many golf balls fit in an airplane?"?
  - stevenwoo 9y ago
    I interviewed at Microsoft in 1990 for a software test position and no one asked me a puzzle question so it had already gone out of style by then at least for my interviewers. They asked me a couple of questions that I recently recognized on the leetcode interview questions list in the easy section.
  - 9y ago

GuiA 9y ago

Do you care a great deal about that stuff because the job you're recruiting for legitimately needs it, or are you hiring people to crank out Rails/Django/React.js/etc. to add a few more textfields on a webpage? Because many people who are in the latter camp think they are in the former, and that's what got us to where we are. There's nothing wrong with the latter, btw. Just that if your job is 90% copy pasting from the React docs and 10% coming up with a clever solution based on academic papers, then it's a much better use of your time to hire people who seem like they can get shit done and train & mentor them, rather than trying to hire the ultimate programmer who will ace your amazing question in exactly the time allotted, saying exactly what the interviewer wants to hear. (the people who read academic papers over breakfast would much rather be at a job where the 90/10 split is the other way around, and will jump ship in the blink of an eye if they've been misled about the job)

taeric 9y ago

To be fair, I am incredibly interested in the jargon and proofs. What I am not, is proficient in doing them on a whiteboard. Therefore, I do not expect someone else to be. More, many of the interesting proofs that folks know took a long time to develop. Sure, you could probably throw some up on the board and speak to it. No, you are not likely to be able to derive one. And, I highly doubt that without practice would you be able to even get it on the board correctly. Which brings up a major point. Discuss more in code reviews. Don't polish them trying to make them perfect. Make them part of your conversation with your peers where you are. I personally even feel recommend to throw up straw men sometimes. It can be odd throwing up a review for the team to see an idea on code you don't intend to push, but it can also be a good conversation. And someone else may be able to take that idea and make it awesome. Which is ultimately what I want from a coding interview. If you have to handwave over parts, fine. Just be up front about it and hide it behind a function call. I may ask you to drill in on that function, but the key is to get valid code. Not necessarily complete code. (Obviously, YMMV.)

deleted 9y ago

[deleted]

rdtsc 9y ago

I interviewed at some of these companies that liked the puzzles and so on. Then got to a company that actually seemed interested in stuff I've done before and asked enough details to know that I knew the stuff. I learned about what they did and seemed interested and got the job. Puzzles and tricks are like that are a crutch, because people don't know how to talk and find out about what the other person knows. Usually what happens if a company becomes successful is they codify whatever they did to get there in stone and that becomes "the golden process" by which everything must be one. If they hired people who knew how invert a binary tree or some stuff like that, they assume they become successful because of it. I would usually think they became successful in spite of it. At the end of the day there are people who will sit and drill interview questions for months and years and maybe that's what companies want, people who are desperate enough to do that work. Maybe that's what the tests really test for ...

pertymcpert 9y ago
> I would usually think they became successful in spite of it. What...
- rdtsc 9y ago
  That...