5 ms·

> Where, in any of my day-to-day job duties, am I going to need to find the kth permutation of a set of numbers? People who don't know algorithms and data stru

by _greim_ 11y ago

> Where, in any of my day-to-day job duties, am I going to need to find the kth permutation of a set of numbers? People who don't know algorithms and data structures tend not to see them where they exist, so it becomes a subjectively self-fulfilling prophecy. You may not need to clone a graph in your day to day work, but seeing graphs where graphs exist can lead you to better solutions in a way that might seem "magical" to others. Even if it isn't too significant, that small edge can make a difference sometimes. Employers rightly want that.

bmj 11y ago
I don't know what your experience is, but given what other folks have shared here, it seems that those with 10+ years of experience in the industry, doing mostly "API programming," have said "I don't use this sort of knowledge day-to-day." I have nearly fifteen years in the industry. I am also entirely self-taught, and have never done any in-depth study on algorithms and data structures. There have been a few times that my lack of knowledge was limiting (and most of those times involved complex queries), but those times are few and far between. But, you are correct: "a small edge can make a difference sometimes." To some employers that matters. To others? Maybe not so much. Maybe they are happy with a few folks that can deal with the algorithm issues, while the rest of team cranks out APIs and fixes bugs and supports old products.
foobaz1982731 11y ago
Posting this under a throwaway so that people at my existing job do not recognize the account. Completely agree, and you might even learn something during the interview, especially if you were previously the "API" programmer group. I'm entirely self-taught, so I will readily admit that my algorithms and data-structures knowledge is not where I feel it should be. I did an interview somewhat recently where we talked about a problem that required the use of a data-structure that I had literally read about in preparation for said interview two days earlier, but did not really understand a solid use case for it. As we discussed the problem that was presented, I ended up arriving at the correct solution and everything was happy, but that's not the cool part. The cool part was that as a result of that conversation, all of the sudden the use for that data-structure "clicked", and an entire class of problems suddenly became obvious in how to optimally solve. I will actually be using that exact solution in a side project that's in the planning phase I haven't done the on-site interview yet, but regardless of whether or not I get an offer (or even accept the offer if one is made), I know that I'm going to walk away from this interview a better engineer for having learned about these algorithms and data-structures just to interview. Looking back at that phone interview, I wonder just how many other problems I've encountered and solved that would've been better served if I knew more about algorithms and data structures.
- fizzbuzz148 11y ago
  The vast majority of my CS schooling was theoretical or algorithmic, so I initially felt like I was at a disadvantage for not knowing the frameworks that everyone else used constantly. After discussing design decisions with people though, I often feel that they think everything will be very difficult and keep hemming and hawing over concerns about how long things will take to implement. I've had to write down pseudo-code for them showing how everything can be done in a single loop and dictionary lookup or something like that to get them to actually agree to their half of the design. I think the biggest benefit of a strong theoretical background is just knowing beforehand how easy so many problems actually are.
ubernostrum 11y ago
Employers rightly want that. No they don't. Employers heard that Google asks questions like these, and Google is worth eleventy skrillion dollars, so if we ask the questions Google asks we'll be worth eleventy skrillion dollars too! In much the same way, last decade everybody knew Microsoft asked riddles, and Microsoft was worth more money than anyone could imagine, so obviously asking riddles is the way to end up worth more money than anyone can imagine. It's basically this comic, but implemented in tech interviews instead of in schooling: http://smbc-comics.com/index.php?id=3978 http://smbc-comics.com/index.php?id=3978 Meanwhile the only reason these things seem to "work" for Google et al. is that they get so many applicants they can afford to turn down huge numbers of perfectly intelligent, perfectly-qualified people who might not do so well on an algorithms pop quiz. And at the same time they've made the process easy to game: you can literally get books of Google-style interview questions, study them, and then pass tech interviews without the underlying knowledge/experience the questions are allegedly selecting for. I just wonder which company will be the next big breakout hit and what irrelevant thing they'll do in interviews that everyone will hurry to nod their heads and sagely agree with as a great indicator of the kinds of things "employers want".
- pkaye 11y ago
  I'd like to hear how you interview candidates and what has been your success? The process could certainly be improved since we have very little time to really know the candidates.
  - a-saleh 11y ago
    From what I have heard of my friends at work actually doing interviews, they mostly focus on finding out how much does their candidate lie on their cv :) I.e: "So you want to join our product security team and say that you know xml. How would you go about finding an exploit in an app that you can get to parse an xml file?" And I have heard several stories from several people doing interviews, where the candidate failed this sort of question particularly badly :) So simple questions in vein of "I see you tell us you know x, that might help you solve problem y we deal in our team often, how would you do it?"
  - 11y ago
dclowd9901 11y ago
Fucking bullshit. I will freely admit my algo knowledge isn't where it needs to be. But I know an algorithm's need where I see one, and consistently. The problems always contain a very specific problem space: 1) sorting 2) Large tables of information 3) categorizing In nearly every case, the appropriate, well researched, proofed, Ph.D approved answer is a quick google away. If you're asking algorithm questions in your interviews, all you're looking for is someone's ability to conjure from memory an appropriate approach. Congratulations, you hired a flash card. You know who I want to hire? Someone who shows creativity and drive through their experience (usually surfaces as having their hands in a lot of disciplines both CS and non), and someone who learns quickly. If they can implement an algorithm (not needing to conjure it on the spot), that's all I need. By the way, no self respecting algo researcher/analyst sits down for 45 minutes to come to a correct and efficient solution to an algorithm problem. Enjoy your grad students. I'll take a maker any day.
- thedufer 11y ago
  > all you're looking for is someone's ability to conjure from memory an appropriate approach So, it's worth mentioning that there are two types of algorithm questions. You seem to be complaining about the "show me merge sort" style, where the interviewer picks a commonly-taught well-known algorithm. I have, in practice, seen this style exactly once (maybe I'm missing a broader trend, though) and it thus comes off as a strawman. The other type involves solving problems that most interviewees, by shear numbers, can't possibly have seen before. Here, you're testing for on-the-spot thinking, not memorization. This is what I actually see when I interview. Because in practice, how many people need to implement merge sort? 99% of them should call `List.sort` and be done. But the algorithm for traversing this strange dual-tree structure or whatever probably isn't in the standard library, and I do need someone who can do that.
  - jacalata 11y ago
    > most interviewees, by shear numbers, can't possibly have seen before. yea, and in a huge coincidence, you're not going to hire most interviewees...
  - 11y ago

by _greim_ 11y ago

bmj 11y ago

I don't know what your experience is, but given what other folks have shared here, it seems that those with 10+ years of experience in the industry, doing mostly "API programming," have said "I don't use this sort of knowledge day-to-day." I have nearly fifteen years in the industry. I am also entirely self-taught, and have never done any in-depth study on algorithms and data structures. There have been a few times that my lack of knowledge was limiting (and most of those times involved complex queries), but those times are few and far between. But, you are correct: "a small edge can make a difference sometimes." To some employers that matters. To others? Maybe not so much. Maybe they are happy with a few folks that can deal with the algorithm issues, while the rest of team cranks out APIs and fixes bugs and supports old products.

foobaz1982731 11y ago

Posting this under a throwaway so that people at my existing job do not recognize the account. Completely agree, and you might even learn something during the interview, especially if you were previously the "API" programmer group. I'm entirely self-taught, so I will readily admit that my algorithms and data-structures knowledge is not where I feel it should be. I did an interview somewhat recently where we talked about a problem that required the use of a data-structure that I had literally read about in preparation for said interview two days earlier, but did not really understand a solid use case for it. As we discussed the problem that was presented, I ended up arriving at the correct solution and everything was happy, but that's not the cool part. The cool part was that as a result of that conversation, all of the sudden the use for that data-structure "clicked", and an entire class of problems suddenly became obvious in how to optimally solve. I will actually be using that exact solution in a side project that's in the planning phase I haven't done the on-site interview yet, but regardless of whether or not I get an offer (or even accept the offer if one is made), I know that I'm going to walk away from this interview a better engineer for having learned about these algorithms and data-structures just to interview. Looking back at that phone interview, I wonder just how many other problems I've encountered and solved that would've been better served if I knew more about algorithms and data structures.

fizzbuzz148 11y ago
The vast majority of my CS schooling was theoretical or algorithmic, so I initially felt like I was at a disadvantage for not knowing the frameworks that everyone else used constantly. After discussing design decisions with people though, I often feel that they think everything will be very difficult and keep hemming and hawing over concerns about how long things will take to implement. I've had to write down pseudo-code for them showing how everything can be done in a single loop and dictionary lookup or something like that to get them to actually agree to their half of the design. I think the biggest benefit of a strong theoretical background is just knowing beforehand how easy so many problems actually are.

ubernostrum 11y ago

Employers rightly want that. No they don't. Employers heard that Google asks questions like these, and Google is worth eleventy skrillion dollars, so if we ask the questions Google asks we'll be worth eleventy skrillion dollars too! In much the same way, last decade everybody knew Microsoft asked riddles, and Microsoft was worth more money than anyone could imagine, so obviously asking riddles is the way to end up worth more money than anyone can imagine. It's basically this comic, but implemented in tech interviews instead of in schooling: http://smbc-comics.com/index.php?id=3978 http://smbc-comics.com/index.php?id=3978 Meanwhile the only reason these things seem to "work" for Google et al. is that they get so many applicants they can afford to turn down huge numbers of perfectly intelligent, perfectly-qualified people who might not do so well on an algorithms pop quiz. And at the same time they've made the process easy to game: you can literally get books of Google-style interview questions, study them, and then pass tech interviews without the underlying knowledge/experience the questions are allegedly selecting for. I just wonder which company will be the next big breakout hit and what irrelevant thing they'll do in interviews that everyone will hurry to nod their heads and sagely agree with as a great indicator of the kinds of things "employers want".

pkaye 11y ago
I'd like to hear how you interview candidates and what has been your success? The process could certainly be improved since we have very little time to really know the candidates.
- a-saleh 11y ago
  From what I have heard of my friends at work actually doing interviews, they mostly focus on finding out how much does their candidate lie on their cv :) I.e: "So you want to join our product security team and say that you know xml. How would you go about finding an exploit in an app that you can get to parse an xml file?" And I have heard several stories from several people doing interviews, where the candidate failed this sort of question particularly badly :) So simple questions in vein of "I see you tell us you know x, that might help you solve problem y we deal in our team often, how would you do it?"
- 11y ago

dclowd9901 11y ago

Fucking bullshit. I will freely admit my algo knowledge isn't where it needs to be. But I know an algorithm's need where I see one, and consistently. The problems always contain a very specific problem space: 1) sorting 2) Large tables of information 3) categorizing In nearly every case, the appropriate, well researched, proofed, Ph.D approved answer is a quick google away. If you're asking algorithm questions in your interviews, all you're looking for is someone's ability to conjure from memory an appropriate approach. Congratulations, you hired a flash card. You know who I want to hire? Someone who shows creativity and drive through their experience (usually surfaces as having their hands in a lot of disciplines both CS and non), and someone who learns quickly. If they can implement an algorithm (not needing to conjure it on the spot), that's all I need. By the way, no self respecting algo researcher/analyst sits down for 45 minutes to come to a correct and efficient solution to an algorithm problem. Enjoy your grad students. I'll take a maker any day.

thedufer 11y ago
> all you're looking for is someone's ability to conjure from memory an appropriate approach So, it's worth mentioning that there are two types of algorithm questions. You seem to be complaining about the "show me merge sort" style, where the interviewer picks a commonly-taught well-known algorithm. I have, in practice, seen this style exactly once (maybe I'm missing a broader trend, though) and it thus comes off as a strawman. The other type involves solving problems that most interviewees, by shear numbers, can't possibly have seen before. Here, you're testing for on-the-spot thinking, not memorization. This is what I actually see when I interview. Because in practice, how many people need to implement merge sort? 99% of them should call `List.sort` and be done. But the algorithm for traversing this strange dual-tree structure or whatever probably isn't in the standard library, and I do need someone who can do that.
- jacalata 11y ago
  > most interviewees, by shear numbers, can't possibly have seen before. yea, and in a huge coincidence, you're not going to hire most interviewees...
- 11y ago