6 ms·

What if you practiced these problems?

muzz 10y ago
GP may be able to do that and get the job, but then he or she would be working with others who've done that, and they may be good rapid puzzle solvers, but not good engineers. That's the problem with that interview approach, it tests only one particular skill (and even that with a high degree of variance).
- dpark 10y ago
  This isn't relevant to the claim that "No amount of work prepares you for this". You can indeed prepare for "puzzle" interviews. Whether this is good interviewing culture is an entirely different question.
  - kamaal 10y ago
    >>You can indeed prepare for "puzzle" interviews. The term 'Preparation' is a misnomer here. That process literally involves living your life on sites like TopCoder, HackerRank etc. You will likely be spending any time you can spare on such sites, to 'prepare'. You can be the most productive person in your current job. That doesn't prepare you for these interviews.
    - dpark 10y ago
      > That process literally involves living your life on sites like TopCoder, HackerRank etc. You will likely be spending any time you can spare on such sites, to 'prepare'. In the same way that keeping up with current events means living your life on sites like CNN, Reuters, NPR? The same way learning a language means staring at DuoLingo all day? Most people don't require 100% time allocation to learn something.
      - pyre 10y ago
        At the same time, you can be amazing at your job without being amazing at toy-problem-brain-teaser questions.
  - muzz 10y ago
    True. I did change the topic and offer my opinion.
  - majormajor 10y ago
    I think there's a big, meaningful difference between "no amount of work prepares you for this" and "no amount of [anything] prepares you for this." With very few exceptions, a job where you're doing useful work, is not going to prepare you for those sorts of data structures/algorithms memorization questions. Libraries exist, you should (generally) be using them, not rewriting them every day. And yet I've been interviewed several times for roles where my actual work has turned out nothing like those interview questions. It's merely a way of trying to check "do they have a good enough memory and grasp of the basic concepts to work things out" as a (lazy, IMO) substitute for trying to see if they have relevant, immediately-useful skills that will complement your team. The less training and onboarding you want to have to burden yourself with, the less you should be asking those questions. Fortunately, on my current team, I had the flexibility to change up our interviewing approach. And then other teams made comments along the lines of "how did you hire such good senior people who grasped our problem space so quickly?!" :)
    - dpark 10y ago
      > I think there's a big, meaningful difference between "no amount of work prepares you for this" and "no amount of [anything] prepares you for this." Something you spend time on to do better in interviews is work as far as I'm concerned. Brushing up on algorithms is work in this context. So is doing programming puzzles if you expect to see those. > It's merely a way of trying to check "do they have a good enough memory and grasp of the basic concepts to work things out" It's generally not about memory. That's a factor but not the intent. Programming puzzles are about finding out if the candidate has a sufficient grasp of technical basics (i.e. if you don't know what a hash table is, or if you don't know Big-O notation, that's a big concern), and yes, whether they can work through a problem. If you can't work through a problem, that's also a big concern. It could mean you just don't interview well, and that's a problem I don't know how to solve. It could also mean that you just aren't able to think through complex issues. Toy problems are not completely representative of real work, but I find it odd when people claim they don't do anything like this in their work at all. I use Big-O to discuss work and give code reviews with some regularity. I work on problems that require juggling some moderately complex state to solve correctly, that require good choice of algorithm and data structure to solve efficiently. That's definitely not most of my work, but it's a part. I try really hard to ask questions that someone with good grasp of fundamentals can solve, though. I stay away from questions that are dependent on a clever trick (find a loop in a linked list with two pointers) or esoteric/trendy knowledge (use circular hashing and a bloom filter!). On the other hand, "brain teaser" puzzles seem mostly to be pointless, but I've not personally been asked one of those in a real interview and I don't know anyone who uses those. > as a (lazy, IMO) substitute for trying to see if they have relevant, immediately-useful skills that will complement your team. I don't generally care if people I'm hiring have immediately-useful skills beyond the fundamentals. I don't care if they're well-versed in our stack or languages or whatever. It's a bonus if they are, but I care far more that we hire smart people who can learn.
- itchyouch 10y ago
  I wonder. I've done a bunch of interviews and will tailor basic questions based on the resume. If they claim to understand networking, I'll ask them a basic "what is ping?" then progress to something like "what does arp do?" Then maybe a tricky, "whats the difference between a timeout and route unavailable error when pinging a host" And hit other topics. I wonder if this is too quizzy? If it's about Bash, then basic questions about variables, exit statuses and such are asked. Surprisingly, so many people's resume accomplishments don't line up with what I'd imagine would be the type of knowledge they should/would carry based on the accomplishment. If the candidate is out of college, then I am a bit more forgiving since I wouldn't expect them to know the intricacies of certain software stacks, but for someone working with something for 2-3 years can't really explain what they put on their resume, it's a big red flag and plays a very large part in disqualifying the person based on their technical merit alone even without getting to the "does this person play well with others" aspect of interviewing.
  - coredog64 10y ago
    I'm glad to know I'm not the only one that does this. I'd say my results echo yours. I had one candidate with a resume that bragged about years of shell scripting experience. When I asked the trivial question of "What is your favorite shell?" he gave a panicked-deer-in-the-headlights look and muttered something about Ubuntu.
    - itchyouch 10y ago
      Phew. Glad to know that I'm not the only one dealing with bullshitters on resumes. I noticed that the recruiting firm that got me my current job is that the candidates that they send aren't that great. I only met this firm because a friend passed the gig on to me. They just send anyone and hope that someone sticks. But once they find someone that sticks and is doing well, they keep on coming back once the headhunting contract limits are off.
  - vonmoltke 10y ago
    Your approach is pretty much standard practice in the engineering world. People in this industry like to claim that answers to those kind of questions can be faked, but you can't fake depth. At some point, if you know what you are doing[1], you will make them look like an idiot if they have been lying. [1] If you don't know what you are doing, you have no business giving an interview. That's another big problem this industry has.
kamaal 10y ago
You can't exactly practice these problems. There is generally some trick involved somewhere which the interviewer expects you to demonstrate. Some tricky way of traversing a tree, or expecting you to know the complexity of every sorting algorithm that exists out there. There is so much of material out there, you'd pretty much be on top of it all the time to 'not forget' stuff with the passage of time.

muzz 10y ago

GP may be able to do that and get the job, but then he or she would be working with others who've done that, and they may be good rapid puzzle solvers, but not good engineers. That's the problem with that interview approach, it tests only one particular skill (and even that with a high degree of variance).

dpark 10y ago
This isn't relevant to the claim that "No amount of work prepares you for this". You can indeed prepare for "puzzle" interviews. Whether this is good interviewing culture is an entirely different question.
- kamaal 10y ago
  >>You can indeed prepare for "puzzle" interviews. The term 'Preparation' is a misnomer here. That process literally involves living your life on sites like TopCoder, HackerRank etc. You will likely be spending any time you can spare on such sites, to 'prepare'. You can be the most productive person in your current job. That doesn't prepare you for these interviews.
  - dpark 10y ago
    > That process literally involves living your life on sites like TopCoder, HackerRank etc. You will likely be spending any time you can spare on such sites, to 'prepare'. In the same way that keeping up with current events means living your life on sites like CNN, Reuters, NPR? The same way learning a language means staring at DuoLingo all day? Most people don't require 100% time allocation to learn something.
    - pyre 10y ago
      At the same time, you can be amazing at your job without being amazing at toy-problem-brain-teaser questions.
- muzz 10y ago
  True. I did change the topic and offer my opinion.
- majormajor 10y ago
  I think there's a big, meaningful difference between "no amount of work prepares you for this" and "no amount of [anything] prepares you for this." With very few exceptions, a job where you're doing useful work, is not going to prepare you for those sorts of data structures/algorithms memorization questions. Libraries exist, you should (generally) be using them, not rewriting them every day. And yet I've been interviewed several times for roles where my actual work has turned out nothing like those interview questions. It's merely a way of trying to check "do they have a good enough memory and grasp of the basic concepts to work things out" as a (lazy, IMO) substitute for trying to see if they have relevant, immediately-useful skills that will complement your team. The less training and onboarding you want to have to burden yourself with, the less you should be asking those questions. Fortunately, on my current team, I had the flexibility to change up our interviewing approach. And then other teams made comments along the lines of "how did you hire such good senior people who grasped our problem space so quickly?!" :)
  - dpark 10y ago
    > I think there's a big, meaningful difference between "no amount of work prepares you for this" and "no amount of [anything] prepares you for this." Something you spend time on to do better in interviews is work as far as I'm concerned. Brushing up on algorithms is work in this context. So is doing programming puzzles if you expect to see those. > It's merely a way of trying to check "do they have a good enough memory and grasp of the basic concepts to work things out" It's generally not about memory. That's a factor but not the intent. Programming puzzles are about finding out if the candidate has a sufficient grasp of technical basics (i.e. if you don't know what a hash table is, or if you don't know Big-O notation, that's a big concern), and yes, whether they can work through a problem. If you can't work through a problem, that's also a big concern. It could mean you just don't interview well, and that's a problem I don't know how to solve. It could also mean that you just aren't able to think through complex issues. Toy problems are not completely representative of real work, but I find it odd when people claim they don't do anything like this in their work at all. I use Big-O to discuss work and give code reviews with some regularity. I work on problems that require juggling some moderately complex state to solve correctly, that require good choice of algorithm and data structure to solve efficiently. That's definitely not most of my work, but it's a part. I try really hard to ask questions that someone with good grasp of fundamentals can solve, though. I stay away from questions that are dependent on a clever trick (find a loop in a linked list with two pointers) or esoteric/trendy knowledge (use circular hashing and a bloom filter!). On the other hand, "brain teaser" puzzles seem mostly to be pointless, but I've not personally been asked one of those in a real interview and I don't know anyone who uses those. > as a (lazy, IMO) substitute for trying to see if they have relevant, immediately-useful skills that will complement your team. I don't generally care if people I'm hiring have immediately-useful skills beyond the fundamentals. I don't care if they're well-versed in our stack or languages or whatever. It's a bonus if they are, but I care far more that we hire smart people who can learn.
itchyouch 10y ago
I wonder. I've done a bunch of interviews and will tailor basic questions based on the resume. If they claim to understand networking, I'll ask them a basic "what is ping?" then progress to something like "what does arp do?" Then maybe a tricky, "whats the difference between a timeout and route unavailable error when pinging a host" And hit other topics. I wonder if this is too quizzy? If it's about Bash, then basic questions about variables, exit statuses and such are asked. Surprisingly, so many people's resume accomplishments don't line up with what I'd imagine would be the type of knowledge they should/would carry based on the accomplishment. If the candidate is out of college, then I am a bit more forgiving since I wouldn't expect them to know the intricacies of certain software stacks, but for someone working with something for 2-3 years can't really explain what they put on their resume, it's a big red flag and plays a very large part in disqualifying the person based on their technical merit alone even without getting to the "does this person play well with others" aspect of interviewing.
- coredog64 10y ago
  I'm glad to know I'm not the only one that does this. I'd say my results echo yours. I had one candidate with a resume that bragged about years of shell scripting experience. When I asked the trivial question of "What is your favorite shell?" he gave a panicked-deer-in-the-headlights look and muttered something about Ubuntu.
  - itchyouch 10y ago
    Phew. Glad to know that I'm not the only one dealing with bullshitters on resumes. I noticed that the recruiting firm that got me my current job is that the candidates that they send aren't that great. I only met this firm because a friend passed the gig on to me. They just send anyone and hope that someone sticks. But once they find someone that sticks and is doing well, they keep on coming back once the headhunting contract limits are off.
- vonmoltke 10y ago
  Your approach is pretty much standard practice in the engineering world. People in this industry like to claim that answers to those kind of questions can be faked, but you can't fake depth. At some point, if you know what you are doing[1], you will make them look like an idiot if they have been lying. [1] If you don't know what you are doing, you have no business giving an interview. That's another big problem this industry has.

kamaal 10y ago

You can't exactly practice these problems. There is generally some trick involved somewhere which the interviewer expects you to demonstrate. Some tricky way of traversing a tree, or expecting you to know the complexity of every sorting algorithm that exists out there. There is so much of material out there, you'd pretty much be on top of it all the time to 'not forget' stuff with the passage of time.