6 ms·

100% agree. So unless you spend all day writing compilers from scratch or calculating Pascal's Triangle, please stop with the ridiculous CS questions in interv

100% agree. So unless you spend all day writing compilers from scratch or calculating Pascal's Triangle, please stop with the ridiculous CS questions in interviews. Software Engineering is more of a trade, and requires vocational knowledge and experience. A mountain of theory may not always be required to Get Shit Done.

justicezyx 9y ago
> So unless you spend all day writing compilers from scratch or calculating Pascal's Triangle, please stop with the ridiculous CS questions in interviews. > Software Engineering is more of a trade, and requires vocational knowledge and experience. A mountain of theory may not always be required to Get Shit Done. First, interview questions are engineering problems that either applicable to real world systems, or were inspired from them. Second, interview questions are used to weed away candidates. At certain point, there will be a few candidates that can answer the questions and articulate sound engineering process. And that's one got hired.
- vvanders 9y ago
  Agreed, a good interview question is also a springboard to a discussion of engineering practices related to the problem.
  - LoSboccacc 9y ago
    The only work environment viable engineering answer is to get a library to solve whatever the problem at hand. At best a top candidate should be able to turn a whitepaper into working code. Knowing trivia rarely translate in solid, productive teams. Very, very few companies are pushing the what's known barrier.
- sidlls 9y ago
  "Implement a recursive depth first traversal of a tree" isn't an engineering problem. It's a CS textbook problem. A fairly basic one, surely, but about as useful to a software engineering project in most cases as the ability to smelt and construct a screw is to an automobile engineer. And the software interviews GP complained about these days don't even start with something that trivial. Usually it's more absurd, and involves what are essentially little math tricks.
  - Pyxl101 9y ago
    I wouldn't ask this question but I don't think it's irrelevant. It shows you that the person understands concepts like recursion, is familiar with data structures like trees, and understands how to express and work with those concepts in code. Completing this problem should take only a few minutes and tells you whether a candidate has a basic degree of competence. When someone breezes through a problem like this, you learn something. If someone struggles with it, you also learn something. You can use that knowledge to calibrate subsequent questions and find the limits of their knowledge. I would be skeptical about the effectiveness of software engineer candidate who isn't comfortable with trees or recursion or algorithms like search. It's a weed-out question like FizzBuzz. I wouldn't ask this question because I think there are better questions available that allows candidates to demonstrate mastery of concepts like these and also have depth so you can go into substantially more detail when the candidate performs well. (And questions that permit multiple solutions, etc.)
    - scierama 9y ago
      Then you want to hire people are good at interviewing; not necessarily people who are good at their job.
    - maxxxxx 9y ago
      I have learned programming on the job, not in school. I think I have a pretty good handle on things like recursion or traversing or implementing structures. But I don't speak the lingo so I don't know what "Implement a recursive depth first traversal of a tree" means exactly. I have been doing this for 25 years now and I don't think I have ever heard anybody formulating a problem that way.
      - xfer 9y ago
        What do you mean, you don't understand "lingo"? Do you not understand english? Because that's an easily understood english sentence, and you just claimed "pretty good handle on things like recursion or traversing or implementing structures". What's the difficulty with questions like that? But honestly you are lucky if you get asked these questions. Usually it is more about some absurd dynamic programming questions.
- gravypod 9y ago
  I would never hire someone who would rather spend 20 minutes thumbing together a solution that may work instead of someone who would rather read available documentation and literature to find either... 1. A trusted library that implements a complex feature 2. A way to abstract away the need for a complex solution 3. Feel the need to rush an implementation of a mission critical piece of code I'd say software engineering is more about organization, abstracting, and simplification of a problem than it is about writing complex data structure implementations or complex algorithms. When you do need to implement a complex data structure or algorithm I think it's much more wise to survey available (and current) literature and implement the algorithm after thinking about the problem for a day or two then it is to attempt to implement it yourself in front of 3 people in a stressful time. I'd expect no one I've ever worked with to be able to correctly meet any business requirement (full battery of tests, an attempt to avoid the more complex solution, documentation for the need and edge cases of an algorithm, real error messages, abstraction or library-extraction of this algorithm into a documented sub-project in our company's git server, etc) I have with a big 5 styled interview question. It boils down to this: 1. Your question is so simple it is stupid to ask someone who is actually qualified 2. Your question is so complicated that anyone who would feel semi-confident in having actually solved it in 40 minutes is someone too dangerous to keep around
  - saghm 9y ago
    > It boils down to this: 1. Your question is so simple it is stupid to ask someone who is actually qualified 2. Your question is so complicated that anyone who would feel semi-confident in having actually solved it in 40 minutes is someone too dangerous to keep around Really? You don't think there's any possibility of a middle ground here?
    - gravypod 9y ago
      I don't think there is anything representative of an employee's quality of work that can be done during a short interview that would have a strong correlate to productivity and quality. I think a real-world take-home problem followed by a meeting-style presentation of your work, your solution, and a Q&A about the implementation with a representative subset of your peers would be better as this would actually be representative of the work load at hand at the company.
- rocky1138 9y ago
  > interview questions are engineering problems that either applicable to real world systems, or were inspired from them. My experience has shown me that in all cases except for two, this is false.
sidlls 9y ago
It's not as simple as being "more of a trade." It's quite similar to the distinction between physics and, say, aerospace engineering in that regard. I'd never describe the latter as being a vocation or trade.
- kohanz 9y ago
  Agreed. Engineering is a "profession". You wouldn't call medicine or law "trades". In some jurisdictions (Canada for example) calling yourself a "software engineer" without having a professional engineering license is unlawful (although lots of people still do it and it's difficult for the regulatory agencies to enforce it at scale).
Nokinside 9y ago
Computer engineer != programmer. 1. Computer engineer is someone who knows computer science. Acquires knowledge that survives when tools die. Hired by Google and other firms. 2. Programmer. Blue collar worker writing bean counting programs. Mainly writes customer software for order. Gets shit done. Becomes difficult to employ when he turns 40 if the shit he does is outdated.
- DaiPlusPlus 9y ago
  A "computer engineer" is someone who designs microprocessors and physical computational hardware - not software. (And for the laity, it is not someone who fixes your broken desktop PC either). Even if you meant SE instead of CE, I feel your distinction is arbitrary and almost classist - while it's true that the top notch folks hired by Google and Microsoft could write "bean counting programs" its fallacious to assume the contrarywise - major accounting and business software firms are just as picky when it comes to hiring - similarly I know plenty of small startups writing exotic software that are able to ship without needing to hire everyone from MIT an Stanford - I also know plenty of very intelligent and capable minds going to waste at companies like Google, MSFT and Facebook working on projects they dislike or for low-impact internal systems - while their contemporaries who went to a coding boot camp got picked up by Snapitterbook and become hot stuff despite never having read the Mythical Man-Month.
- SAI_Peregrinus 9y ago
  Computer Engineer != computer scientist. 1. Computer engineer works at and around the boundary between electrical engineering and computer science. Hardware, firmware, drivers, and other low-level systems that interact closely with the physical world. Hired by Intel and other firms. 2. Computer scientist knows the study of computation. Computer science tends to abstract the hardware away and consider ideal systems. There is of course some overlap. Computer engineering is all about the overlap between CS and EE, so some CS people will work in some of the same areas as CEs. Likewise with EEs. And the terms are fuzzy, and may have different definitions to different people, but the distinction I made seems to be present in most college degree programs I've seen.
- tensor 9y ago
deathanatos 9y ago
I disagree. * I routinely find people using the wrong data structure, when there exists a better one, with better O() time/space. * I find people tend to not understand BTrees, particularly when there are two attributes being indexed. Given an index on (a, b), I find it common misconception that the BTree can efficiently answer `$a_min < a < $a_max AND $b_min < b < $b_max`. (I.e., people do not understand that the tree cannot make use of the second < condition, and must scan potentially many more rows than they intend.) * Graph theory. git uses it. Any sort of dependency tree uses it. That said, I acknowledge that software engineering does require a lot of non-theoretical knowledge, which is why I ask both types of questions in an interview.
- Shank 9y ago
  Yeah, but data structures and binary trees are about as much as you really need to get. There's a big difference between selecting the right data structure and re-implementing dijkstra's work on a whiteboard.
- walrus1066 9y ago
  Does your job actually require knowledge of BTrees?
  - arianvanp 9y ago
    Yes! Our database blew up in our face because we misused and had wrong performance assumptions some indexes. Colleague had knowledge of btrees (the underlying data structure of database, iirc) and database internals. Optimised the whole thing. Queries are now 500x faster
  - deathanatos 9y ago
    Yes. They're the typical data structure backing most relation database indexes. Knowing when they will perform well (and more often, when they won't) follows directly from knowing their structure. (The example of trying to do a range search on two dimensions in the post above is an example that doesn't perform as well as — again, I find — people naively expect it to.) Have I ever implemented one? Not yet. Do I ask for a BTree implementation or exact, low-level understanding on an interview? No.

justicezyx 9y ago

> So unless you spend all day writing compilers from scratch or calculating Pascal's Triangle, please stop with the ridiculous CS questions in interviews. > Software Engineering is more of a trade, and requires vocational knowledge and experience. A mountain of theory may not always be required to Get Shit Done. First, interview questions are engineering problems that either applicable to real world systems, or were inspired from them. Second, interview questions are used to weed away candidates. At certain point, there will be a few candidates that can answer the questions and articulate sound engineering process. And that's one got hired.

vvanders 9y ago
Agreed, a good interview question is also a springboard to a discussion of engineering practices related to the problem.
- LoSboccacc 9y ago
  The only work environment viable engineering answer is to get a library to solve whatever the problem at hand. At best a top candidate should be able to turn a whitepaper into working code. Knowing trivia rarely translate in solid, productive teams. Very, very few companies are pushing the what's known barrier.
sidlls 9y ago
"Implement a recursive depth first traversal of a tree" isn't an engineering problem. It's a CS textbook problem. A fairly basic one, surely, but about as useful to a software engineering project in most cases as the ability to smelt and construct a screw is to an automobile engineer. And the software interviews GP complained about these days don't even start with something that trivial. Usually it's more absurd, and involves what are essentially little math tricks.
- Pyxl101 9y ago
  I wouldn't ask this question but I don't think it's irrelevant. It shows you that the person understands concepts like recursion, is familiar with data structures like trees, and understands how to express and work with those concepts in code. Completing this problem should take only a few minutes and tells you whether a candidate has a basic degree of competence. When someone breezes through a problem like this, you learn something. If someone struggles with it, you also learn something. You can use that knowledge to calibrate subsequent questions and find the limits of their knowledge. I would be skeptical about the effectiveness of software engineer candidate who isn't comfortable with trees or recursion or algorithms like search. It's a weed-out question like FizzBuzz. I wouldn't ask this question because I think there are better questions available that allows candidates to demonstrate mastery of concepts like these and also have depth so you can go into substantially more detail when the candidate performs well. (And questions that permit multiple solutions, etc.)
  - scierama 9y ago
    Then you want to hire people are good at interviewing; not necessarily people who are good at their job.
  - maxxxxx 9y ago
    I have learned programming on the job, not in school. I think I have a pretty good handle on things like recursion or traversing or implementing structures. But I don't speak the lingo so I don't know what "Implement a recursive depth first traversal of a tree" means exactly. I have been doing this for 25 years now and I don't think I have ever heard anybody formulating a problem that way.
    - xfer 9y ago
      What do you mean, you don't understand "lingo"? Do you not understand english? Because that's an easily understood english sentence, and you just claimed "pretty good handle on things like recursion or traversing or implementing structures". What's the difficulty with questions like that? But honestly you are lucky if you get asked these questions. Usually it is more about some absurd dynamic programming questions.
gravypod 9y ago
I would never hire someone who would rather spend 20 minutes thumbing together a solution that may work instead of someone who would rather read available documentation and literature to find either... 1. A trusted library that implements a complex feature 2. A way to abstract away the need for a complex solution 3. Feel the need to rush an implementation of a mission critical piece of code I'd say software engineering is more about organization, abstracting, and simplification of a problem than it is about writing complex data structure implementations or complex algorithms. When you do need to implement a complex data structure or algorithm I think it's much more wise to survey available (and current) literature and implement the algorithm after thinking about the problem for a day or two then it is to attempt to implement it yourself in front of 3 people in a stressful time. I'd expect no one I've ever worked with to be able to correctly meet any business requirement (full battery of tests, an attempt to avoid the more complex solution, documentation for the need and edge cases of an algorithm, real error messages, abstraction or library-extraction of this algorithm into a documented sub-project in our company's git server, etc) I have with a big 5 styled interview question. It boils down to this: 1. Your question is so simple it is stupid to ask someone who is actually qualified 2. Your question is so complicated that anyone who would feel semi-confident in having actually solved it in 40 minutes is someone too dangerous to keep around
- saghm 9y ago
  > It boils down to this: 1. Your question is so simple it is stupid to ask someone who is actually qualified 2. Your question is so complicated that anyone who would feel semi-confident in having actually solved it in 40 minutes is someone too dangerous to keep around Really? You don't think there's any possibility of a middle ground here?
  - gravypod 9y ago
    I don't think there is anything representative of an employee's quality of work that can be done during a short interview that would have a strong correlate to productivity and quality. I think a real-world take-home problem followed by a meeting-style presentation of your work, your solution, and a Q&A about the implementation with a representative subset of your peers would be better as this would actually be representative of the work load at hand at the company.
rocky1138 9y ago
> interview questions are engineering problems that either applicable to real world systems, or were inspired from them. My experience has shown me that in all cases except for two, this is false.

sidlls 9y ago

It's not as simple as being "more of a trade." It's quite similar to the distinction between physics and, say, aerospace engineering in that regard. I'd never describe the latter as being a vocation or trade.

kohanz 9y ago
Agreed. Engineering is a "profession". You wouldn't call medicine or law "trades". In some jurisdictions (Canada for example) calling yourself a "software engineer" without having a professional engineering license is unlawful (although lots of people still do it and it's difficult for the regulatory agencies to enforce it at scale).

Nokinside 9y ago

Computer engineer != programmer. 1. Computer engineer is someone who knows computer science. Acquires knowledge that survives when tools die. Hired by Google and other firms. 2. Programmer. Blue collar worker writing bean counting programs. Mainly writes customer software for order. Gets shit done. Becomes difficult to employ when he turns 40 if the shit he does is outdated.

DaiPlusPlus 9y ago
A "computer engineer" is someone who designs microprocessors and physical computational hardware - not software. (And for the laity, it is not someone who fixes your broken desktop PC either). Even if you meant SE instead of CE, I feel your distinction is arbitrary and almost classist - while it's true that the top notch folks hired by Google and Microsoft could write "bean counting programs" its fallacious to assume the contrarywise - major accounting and business software firms are just as picky when it comes to hiring - similarly I know plenty of small startups writing exotic software that are able to ship without needing to hire everyone from MIT an Stanford - I also know plenty of very intelligent and capable minds going to waste at companies like Google, MSFT and Facebook working on projects they dislike or for low-impact internal systems - while their contemporaries who went to a coding boot camp got picked up by Snapitterbook and become hot stuff despite never having read the Mythical Man-Month.
SAI_Peregrinus 9y ago
Computer Engineer != computer scientist. 1. Computer engineer works at and around the boundary between electrical engineering and computer science. Hardware, firmware, drivers, and other low-level systems that interact closely with the physical world. Hired by Intel and other firms. 2. Computer scientist knows the study of computation. Computer science tends to abstract the hardware away and consider ideal systems. There is of course some overlap. Computer engineering is all about the overlap between CS and EE, so some CS people will work in some of the same areas as CEs. Likewise with EEs. And the terms are fuzzy, and may have different definitions to different people, but the distinction I made seems to be present in most college degree programs I've seen.
tensor 9y ago

deathanatos 9y ago

I disagree. * I routinely find people using the wrong data structure, when there exists a better one, with better O() time/space. * I find people tend to not understand BTrees, particularly when there are two attributes being indexed. Given an index on (a, b), I find it common misconception that the BTree can efficiently answer `$a_min < a < $a_max AND $b_min < b < $b_max`. (I.e., people do not understand that the tree cannot make use of the second < condition, and must scan potentially many more rows than they intend.) * Graph theory. git uses it. Any sort of dependency tree uses it. That said, I acknowledge that software engineering does require a lot of non-theoretical knowledge, which is why I ask both types of questions in an interview.

Shank 9y ago
Yeah, but data structures and binary trees are about as much as you really need to get. There's a big difference between selecting the right data structure and re-implementing dijkstra's work on a whiteboard.
walrus1066 9y ago
Does your job actually require knowledge of BTrees?
- arianvanp 9y ago
  Yes! Our database blew up in our face because we misused and had wrong performance assumptions some indexes. Colleague had knowledge of btrees (the underlying data structure of database, iirc) and database internals. Optimised the whole thing. Queries are now 500x faster
- deathanatos 9y ago
  Yes. They're the typical data structure backing most relation database indexes. Knowing when they will perform well (and more often, when they won't) follows directly from knowing their structure. (The example of trying to do a range search on two dimensions in the post above is an example that doesn't perform as well as — again, I find — people naively expect it to.) Have I ever implemented one? Not yet. Do I ask for a BTree implementation or exact, low-level understanding on an interview? No.