3 ms·

I frequently hear this basic point: "Software interviews test algorithms and data structures that are so clearly not relevant to the work being done and soooo t

by wdewind 10y ago

I frequently hear this basic point: "Software interviews test algorithms and data structures that are so clearly not relevant to the work being done and soooo theoretical I don't understand why interviewing isn't better???" I used to believe this myself, mostly because I didn't have a strong CS background and was still successful at carrying out software projects at a relatively high level. The truth is, as I learned more CS I learned that these things are actually pretty crucial. Not necessarily for executing one single project, but for building a large system that scales reasonably? Absolutely. I spent years reinventing the wheel of basic data structures and algos simply because I did not know them or how to use them. Bottom line: I would not want to work with the me of 5 years ago because I wrote shitty code while proudly proclaiming that CS was theoretical bullshit that didn't matter in web development, and I think many people who make these types of claims really just don't understand how applicable a good CS foundation is. I'd agree that ideally you want some kind of work sample as well. Either an OS contribution, github or even small project written specifically for the interview. You can't ask someone to write enough code on an interview that you really see what happens when they have to structure a real project (ie: thousands of lines) or work within a real system (ie: millions of lines). This is where CS foundations in interviews have their relevancy.

mixmastamyk 10y ago
It's not that they're irrelevant, it's that the problems can't be done in a disruptive environment with $100k on the line, by asking questions that must be memorized by chance first.
- wdewind 10y ago
  Well the idea is that they aren't memorized by chance first, they are known pretty well because ideally you have a track record of applying them to real life problems (even if they are just school projects or side projects). I can describe times I've used queues to solve various problems, for instance. The other thing is, as others have pointed out, seeing how someone breaks down and approaches and unfamiliar problem is very valuable. It sucks that we have to do it under the pressure of a 45min-1hour conversation, and I totally get that the stakes are high and so nerves are a problem. In general I think the best way to handle this stuff is to give candidates multiple paths to succeed. I think the nerves problem is slightly overstated though, because I do think many companies do give candidates multiple paths to succeed. For instance, if you have trouble performing well in an interview setting it's pretty crucial that you have a wide array of work on github proving you can code and that will give you an opportunity to have some complicated but familiar code that you can talk about in the interview. If someone comes in with this but is shy or gets frustrated or something, as an interviewer I'm really going to try and pull the magic I see in their github out of them in that interview. Keep in mind that people hiring engineers really want the candidate to succeed in most cases. It's so difficult to find good talent that while I'm never going to lower my standards to hurt the company, I'm definitely on the candidate's team in an interview, trying to get them to shine as best I can.
  - mixmastamyk 10y ago
    Very few people are working as comp scientists, but rather software engineers, making BFS=Queues a random trivia question that must be prepared for in advance.
    - wdewind 10y ago
      BFS queues are not particularly difficult to describe, and deciding whether or not to do breadth or depth first is something I think about all the time. Frequently, for instance, in data access patterns, that decision can have a very big effect on performance. I can't agree that it's a random trivia question. Edit: Ok, let me add some nuance here. I think we both probably agree that implementing a shortest path algo perfectly in an interview setting is beyond reasonable or useful. But I would expect an engineer to be able to have a discussion about it that shows me they understand the basic concepts and given google and a bit of time could relearn that. But without the complexity of shortest path I would not expect basic BFS to be outside of the scope of an interview. I guess that's just where I draw my lines.
      - mixmastamyk 10y ago
        Hmm, their difficulty is irrelevant. Your experience (like everyone's) is anecdotal and not representative of the immense fields of CS and SE that no one person can know all of, but could certainly look up. If you are looking for a computer scientist, ask for one in the job req. No shame in that, it would save everyone time.
        wdewind 10y ago
        I added a sneaky edit (sorry!) that may address some of this, so I think we probably largely agree. I'm responding to a relatively specific claim, frequently heard by bootcampers and inexperienced engineers in web development, that foundational CS isn't useful, which my experience is somewhat representative of, though you are correct it's still anecdotal.
MrBuddyCasino 10y ago
> http://steve-yegge.blogspot.de/2008/06/done-and-gets-things-smart.html http://steve-yegge.blogspot.de/2008/06/done-and-gets-things-... Steve Yegge thinks people disregarding CS questions in interviews is the Dunning-Kruger effect in action. I think he's right, but I have no way of knowing - due to Dunning-Kruger...
throw_for_throw 10y ago
Can you provide a more concrete example of something that you reinvented that you wouldn't have if you had a better CS background?
komali2 10y ago
I didn't finish the problem in my interview, and got hired. I asked the PM later why, and he said "we wanted to see you try to solve a problem we know you couldn't, so we could see your problem-solving process and how you handle stress." The author of the article comes off as defensive and blame-shifting. I'm not surprised he didn't get hired. Since when is it ok to say "why?" when someone asked you to perform something in an interview? Do you really think the multi million dollar news agency will need you to program a maze at some point, so they're testing your ability to? Just how dumb do these engineers think recruiters are?
geebee 10y ago
I don't object to an employer wanting to see a background in data structures and algorithms, sql, binary, and a few branches of math. This is why I agree that hiring is broken but also understand that it isn't easy to fix. Some of it stems from something very wonderful about our profession - we are flexible about how people can acquire this background. In law, you must do a 3 year JD[1], and you must typically pay way over 100k for it. Alternate paths toward learning this material are pretty much illegal (as in, we'll put you in jail if you try to practice law if you haven't done the 3-year degree, regardless of your master of the material). For instance, I was a math major, and I only took a bit of formal CS. However, when I did self-study to try to plug some of these gaps (partially for interviews, partially for my own education), I was surprised with how much I actually had covered from a different angle. Many of my math (and later, in grad school, Industrial Engineering) professors ran "labs", some for a bit of extra credit, others as an optional set of assignments. I took graph theory through a math department and stuck around in the lab and so forth to implement some of the algorithms, to learn about how some types of proofs actually contain an algorithm. BFS, DFS, minimum spanning set. That all involved building trees, lists, using pointers. In numerical analysis, I did a lot of matrix algebra manipulations. And so on. If CS were run like law, it would be illegal for someone like me to work as a programmer, because my degree isn't an ABET accredited CS degree. The downside to all of this, though, is that there is no recognized credential. I don't object to being taken through my paces, I object to how random, capricious, and redundant the process has become. I read a blog article about a programmer who took the bar and studied for 100 hours and passed. Think on that for a second and compare it to the amount of time people spend preparing for and taking what are essentially white board exams in technical interviews. The bar, an exam that is considered one of the most brutal rites of passage for a learned profession? In some ways, we go through that every time we do a new round of interviews when we change jobs! Actuaries have to show understanding of relatively advanced math, but senior actuaries don't (to my knowledge) get grilled on integration by parts or some specialized set of partial differential equations when they interview. Why? Because there is a proper exam for their field (and unlike law, actuaries are free to obtain this background through multiple educational paths, they often major in math, but hardly always). Another problem is the capriciousness of the tech exam/interviews. I believe that a "bill of rights" so to speak slowly evolved between examinee and governing board over time in true professions. The nursing and medical boards, the actuarial exams, the bar - these fields have a tough exam (or series of exams), but they are consistent, there is a clear study path, there is a commitment to grade them fairly, there is a clear study path, if you fail, you get feedback or at least a score (the bar doesn't write you back and say they "decided not to pursue your candidacy further at this time"), there is often a second (or additional) change at the exam, and, most importantly, when you pass you get a lasting, public credential respected by your peers in the field. People often describe these exams as the most brutal, anxiety ridden, stressful events of their professional lives. This is why, I believe, they slowly evolved that "bill or rights" that protects the examinee. Unfortunately, in tech, I believe we experience these exams over and over, but without any of those benefits. I am a-ok with requiring people to show competence, but the way we go about it is, I think, badly broken. I believe that this process accounts for a great deal of attrition in the field, as well as people deciding not to enter the field in the first place. [1] yes, a bit of handwaving, it's not quite that simple in some states.
deleted 10y ago
[deleted]
mkohlmyr 10y ago
I think you are both taking extreme sides of this argument when there is a very reasonable middle ground Should a programmer you hire be able to reason about CS problems? Yes. Do they need to be able to write out the best possible solution to a problem on a whiteboard within 15 minutes? No. The white-board sessions only really serve to intimidate people who aren't good public speakers, think better with some time and peace and quiet, or simply haven't bothered to memorize code they never have to write from scratch. Legitimately bad candidates could just as efficiently be eliminated by having a casual discussion about a CS concept that relates to the job description.
- wdewind 10y ago
  I totally agree with this. In one of my other replies I mentioned the concept of having multiple paths for a candidate to be successful through, and I agree that "whiteboard coding" should not be the only way to prove you are smart and competent.

by wdewind 10y ago

mixmastamyk 10y ago

It's not that they're irrelevant, it's that the problems can't be done in a disruptive environment with $100k on the line, by asking questions that must be memorized by chance first.

wdewind 10y ago
Well the idea is that they aren't memorized by chance first, they are known pretty well because ideally you have a track record of applying them to real life problems (even if they are just school projects or side projects). I can describe times I've used queues to solve various problems, for instance. The other thing is, as others have pointed out, seeing how someone breaks down and approaches and unfamiliar problem is very valuable. It sucks that we have to do it under the pressure of a 45min-1hour conversation, and I totally get that the stakes are high and so nerves are a problem. In general I think the best way to handle this stuff is to give candidates multiple paths to succeed. I think the nerves problem is slightly overstated though, because I do think many companies do give candidates multiple paths to succeed. For instance, if you have trouble performing well in an interview setting it's pretty crucial that you have a wide array of work on github proving you can code and that will give you an opportunity to have some complicated but familiar code that you can talk about in the interview. If someone comes in with this but is shy or gets frustrated or something, as an interviewer I'm really going to try and pull the magic I see in their github out of them in that interview. Keep in mind that people hiring engineers really want the candidate to succeed in most cases. It's so difficult to find good talent that while I'm never going to lower my standards to hurt the company, I'm definitely on the candidate's team in an interview, trying to get them to shine as best I can.
- mixmastamyk 10y ago
  Very few people are working as comp scientists, but rather software engineers, making BFS=Queues a random trivia question that must be prepared for in advance.
  - wdewind 10y ago
    BFS queues are not particularly difficult to describe, and deciding whether or not to do breadth or depth first is something I think about all the time. Frequently, for instance, in data access patterns, that decision can have a very big effect on performance. I can't agree that it's a random trivia question. Edit: Ok, let me add some nuance here. I think we both probably agree that implementing a shortest path algo perfectly in an interview setting is beyond reasonable or useful. But I would expect an engineer to be able to have a discussion about it that shows me they understand the basic concepts and given google and a bit of time could relearn that. But without the complexity of shortest path I would not expect basic BFS to be outside of the scope of an interview. I guess that's just where I draw my lines.
    - mixmastamyk 10y ago
      Hmm, their difficulty is irrelevant. Your experience (like everyone's) is anecdotal and not representative of the immense fields of CS and SE that no one person can know all of, but could certainly look up. If you are looking for a computer scientist, ask for one in the job req. No shame in that, it would save everyone time.
      - wdewind 10y ago
        I added a sneaky edit (sorry!) that may address some of this, so I think we probably largely agree. I'm responding to a relatively specific claim, frequently heard by bootcampers and inexperienced engineers in web development, that foundational CS isn't useful, which my experience is somewhat representative of, though you are correct it's still anecdotal.

MrBuddyCasino 10y ago

> http://steve-yegge.blogspot.de/2008/06/done-and-gets-things-smart.html http://steve-yegge.blogspot.de/2008/06/done-and-gets-things-... Steve Yegge thinks people disregarding CS questions in interviews is the Dunning-Kruger effect in action. I think he's right, but I have no way of knowing - due to Dunning-Kruger...

throw_for_throw 10y ago

Can you provide a more concrete example of something that you reinvented that you wouldn't have if you had a better CS background?

komali2 10y ago

I didn't finish the problem in my interview, and got hired. I asked the PM later why, and he said "we wanted to see you try to solve a problem we know you couldn't, so we could see your problem-solving process and how you handle stress." The author of the article comes off as defensive and blame-shifting. I'm not surprised he didn't get hired. Since when is it ok to say "why?" when someone asked you to perform something in an interview? Do you really think the multi million dollar news agency will need you to program a maze at some point, so they're testing your ability to? Just how dumb do these engineers think recruiters are?

geebee 10y ago

I don't object to an employer wanting to see a background in data structures and algorithms, sql, binary, and a few branches of math. This is why I agree that hiring is broken but also understand that it isn't easy to fix. Some of it stems from something very wonderful about our profession - we are flexible about how people can acquire this background. In law, you must do a 3 year JD[1], and you must typically pay way over 100k for it. Alternate paths toward learning this material are pretty much illegal (as in, we'll put you in jail if you try to practice law if you haven't done the 3-year degree, regardless of your master of the material). For instance, I was a math major, and I only took a bit of formal CS. However, when I did self-study to try to plug some of these gaps (partially for interviews, partially for my own education), I was surprised with how much I actually had covered from a different angle. Many of my math (and later, in grad school, Industrial Engineering) professors ran "labs", some for a bit of extra credit, others as an optional set of assignments. I took graph theory through a math department and stuck around in the lab and so forth to implement some of the algorithms, to learn about how some types of proofs actually contain an algorithm. BFS, DFS, minimum spanning set. That all involved building trees, lists, using pointers. In numerical analysis, I did a lot of matrix algebra manipulations. And so on. If CS were run like law, it would be illegal for someone like me to work as a programmer, because my degree isn't an ABET accredited CS degree. The downside to all of this, though, is that there is no recognized credential. I don't object to being taken through my paces, I object to how random, capricious, and redundant the process has become. I read a blog article about a programmer who took the bar and studied for 100 hours and passed. Think on that for a second and compare it to the amount of time people spend preparing for and taking what are essentially white board exams in technical interviews. The bar, an exam that is considered one of the most brutal rites of passage for a learned profession? In some ways, we go through that every time we do a new round of interviews when we change jobs! Actuaries have to show understanding of relatively advanced math, but senior actuaries don't (to my knowledge) get grilled on integration by parts or some specialized set of partial differential equations when they interview. Why? Because there is a proper exam for their field (and unlike law, actuaries are free to obtain this background through multiple educational paths, they often major in math, but hardly always). Another problem is the capriciousness of the tech exam/interviews. I believe that a "bill of rights" so to speak slowly evolved between examinee and governing board over time in true professions. The nursing and medical boards, the actuarial exams, the bar - these fields have a tough exam (or series of exams), but they are consistent, there is a clear study path, there is a commitment to grade them fairly, there is a clear study path, if you fail, you get feedback or at least a score (the bar doesn't write you back and say they "decided not to pursue your candidacy further at this time"), there is often a second (or additional) change at the exam, and, most importantly, when you pass you get a lasting, public credential respected by your peers in the field. People often describe these exams as the most brutal, anxiety ridden, stressful events of their professional lives. This is why, I believe, they slowly evolved that "bill or rights" that protects the examinee. Unfortunately, in tech, I believe we experience these exams over and over, but without any of those benefits. I am a-ok with requiring people to show competence, but the way we go about it is, I think, badly broken. I believe that this process accounts for a great deal of attrition in the field, as well as people deciding not to enter the field in the first place. [1] yes, a bit of handwaving, it's not quite that simple in some states.

deleted 10y ago

[deleted]

mkohlmyr 10y ago

I think you are both taking extreme sides of this argument when there is a very reasonable middle ground Should a programmer you hire be able to reason about CS problems? Yes. Do they need to be able to write out the best possible solution to a problem on a whiteboard within 15 minutes? No. The white-board sessions only really serve to intimidate people who aren't good public speakers, think better with some time and peace and quiet, or simply haven't bothered to memorize code they never have to write from scratch. Legitimately bad candidates could just as efficiently be eliminated by having a casual discussion about a CS concept that relates to the job description.

wdewind 10y ago
I totally agree with this. In one of my other replies I mentioned the concept of having multiple paths for a candidate to be successful through, and I agree that "whiteboard coding" should not be the only way to prove you are smart and competent.