7 ms·

The OP's point is, unless I misread it, not that there are no incompetent engineers who can't code, but it is ridiculous to, like, ask some "fancy" algorithm qu

The OP's point is, unless I misread it, not that there are no incompetent engineers who can't code, but it is ridiculous to, like, ask some "fancy" algorithm questions, brain teasers, etc. that are mostly not related to the candidate's working experience at all. For candidates who are fresh graduates, it looks it is the most effective way to ask algo and data structures. For a senior engineer who has at least 10 years of experiences, the interviewers cannot find some better questions to ask, to verify if the candidate is a good coder? I was interviewed once. I was asked a question. I knew the question could be solved with a "fancy" algorithm, since I read the original paper in graduate school. It was elegant and beautiful, very creative. After so many years, I couldn't remember any details, and I had had no opportunity to use it in my work. I am not a genius, so I couldn't figure it out in 20 minutes during interview. Does that mean I am a fake?

morgante 12y ago
> In all my years immersed in the tech industry, I have never once heard a firm talk about the idiots lurking in their own offices. They always seem to be elsewhere. For everyone. It certainly sounds like the author doesn't think there are any actual incompetent engineers out there. Personally, I know that to be false. I have worked with incompetent engineers, who literally couldn't code FizzBuzz.
- learc83 12y ago
  I think the author is saying we should do interviews like nearly every other industry. Look at past experience, and ask the candidate to talk about that experience to verify that they aren't lying. If someone has 5 years experience working at Google, and they can talk coherently about technical aspects of the projects they worked on, there is no reason to ask them to code on a whiteboard. The way it currently works is this: I see you have a CS, degree and 10 years experience at a well known company. Excellent. Now you have 2 eggs and a 100 story skyscraper. Tell me the minimum number of egg drops you'll have to perform to discover the minimum height that will break the egg. Every engineer no matter how experienced has to answer questions like they just left school yesterday, no other industry does this. >Personally, I know that to be false. I have worked with incompetent engineers, who literally couldn't code FizzBuzz. 99 times out of 100 you could catch that engineer by talking to him about technical aspects of past projects he worked on.
  - mahyarm 12y ago
    This is why I like to give laptops to engineers and ask to make something simple, that might require logic, but doesn't require any sort of specialized knowledge. They can even look up documentation. Like make a table view that has word counts for a string. Or make this simple puzzle game. Or make a simple address book app.
    - jaredsohn 12y ago
      Just an FYI -- working on someone else's laptop can often be an unpleasant experience (weird keyboard configuration, different software installed, etc.) My current opinion on this would be to offer a laptop so you aren't disadvantaging candidates who don't have one too badly, but let people use their own if they have one (and let them know ahead of time that it will be an option and what they should be set up for.)
      - jghn 12y ago
        We tell candidates up front that they'll be doing some live coding and welcome them to bring their own laptop if they would like. We have a backup around with just about every reasonable IDE and editor installed for our languages but even then I agree, it's definitely not the same using someone else's computer.
        iopq 12y ago
        I program on my desktop with two monitors, I wouldn't be comfortable on a laptop without at least two extra large monitors hooked up to it already. And a normal keyboard, don't give me that laptop keyboard crap.
        mpercy 12y ago
        Wow... I understand that you'd be much more productive with a large monitor and good keyboard, but to the extent that you couldn't perform in a coding interview? Give me a break... In the past, I've used CollabEdit for "phone screens" and the whiteboard for in-person interviews. I try to ask some "coding" questions (identify a better data structure / algo for a particular scenario and then implement it in code) and some problem-solving conversational questions. Seems to work pretty well, but I'm always on the lookout for better approaches. Part of the problem is that the software field is so broad that it's hard to get a sense of a person's abilities with such a limited amount of time to ask questions.
- d23 12y ago
  I worked with a guy who, after having been at the company for 6 months, called me over to his desk to help with a "problem." He wondered why he was getting a syntax error. Okay, fair enough. I looked at his screen, and he was putting the arguments to the function OUTSIDE the parentheses. The guy had clearly just been copying and pasting code until "it worked" the entire time he had been there. I almost palmed my face right off of my head.
  - theVirginian 12y ago
    To be fair, I have done that before when just messing around on my own late at night. After working for as long as I had been I felt like reading my own code was like wading through sludge and my eyes just didn't catch the error. I was still however well aware that putting the arguments outside the parentheses is not how this works, not how any of this works.
  - tormeh 12y ago
    That reminds me of how I deal with C's pointer syntax. "Well, it's either * or & or a combination of a low number of the two, let's try a couple of combinations that seems vaguely reasonable... and some that don't, just in case". I don't know who's most at fault: Me or C.
    - robbles 12y ago
      rule of thumb: "*" means "look up the area of memory this value points to". "&" means the reverse - "give me a reference to this area of memory". The problem with randomly trying things with pointers is that sometimes you can accidentally fix the issue but introduce a subtle bug that's dependent on the data being stored.
    - MaulingMonkey 12y ago
      In case it helps, I've noticed what I'd consider a wart in C that seems to be a common stumbling block with this - including when I first learned C a couple decades ago: * when used for types, has the "opposite" effect when it's used for values/expressions. int* foo; // The addition of a star here, on a type, means we're converting the type /into/ a pointer-to-int /from/ a plain int. int i = *foo; // The addition of a star here, on a value, means we're converting the type /from/ a pointer-to-int /into/ a plain int (reference). I found it much easier to keep the two straight once I segregated their use cases like this. There's a similar duality with & in C++ using references, although not quite as cleanly: int& foo = ...; // The addition of & here, on a type, means we're converting the type /into/ a reference /from/ a plain int. p = &foo; // The addition of & here, on a value, means we're converting the type /from/ a reference /into/ a pointer-to-int. Regardless of "fault", I hope this helps :) (edit: C++ style comments used even in 'C' code to try and prevent YN from treating stars as formatting... replaced a few instances with 'a star'... changed emphasis to use slashes because it's still eating asterisks characters...)
- muddyrivers 12y ago
  I am not sure if your comment is supposed to reply to mine. I do think there are incompetent engineers, and I have interviewed about a dozen of them. It is very easy to filter them out. The challenging part is to evaluate how good the candidates are, and if they would be good for the team and for the applied positions. In start-ups with <20 engineers, you would like to have the candidates to be able to wear many hats. In a big engineering team, the requirements could be different. For example, besides challenging and creative work, there could be some tedious, even boring, work. The latter is also important, both for the whole system running smoothly and for the long term health of the system. So if the candidate is sufficiently competent, very detail-oriented, disciplined, team-oriented, she/he would be an excellent fit for the job, even if she/he is not technically very strong and couldn't figure out challenging technical issues. An excellent engineer, on the other hand, might get bore, grumpy, and leave in 6 months. It is expensive to restart the hiring process.
- hnnewguy 12y ago
  >I have worked with incompetent engineers, who literally couldn't code FizzBuzz. Operative word worked. This is exactly what the article says: "They always seem to be elsewhere. For everyone."
  - morgante 12y ago
    Uh, no? For the time when I was employed there, they weren't "elsewhere." They were sitting right next to me. (The presence of incompetent engineers was certainly a factor in why I left that job.)
    - hnnewguy 12y ago
      You should work on your reading comprehension. What you're saying is precisely what the author is talking about: everyone has a story about terrible engineers, but they're almost always "elsewhere". Co-workers tend to become "stupid" and "incompetent" after you leave. And yet they maintain employment. It's an idea, not an iron-clad rule, that perhaps "incompetence" isn't as rampant as so many people suggest.
- aros 12y ago
  You've misunderstood the author's sentence. His point was that many companies tend to think anyone applying for a position is 100% unqualified instead of focusing on the dead weight within. I've anecdotally experienced this in the form of watching employees who contribute near 0 take years to be let go due to internal politics.
Gibbon1 12y ago
I read a really good comment by I think Nolan Bushnell about engineers. He said said he got asked all the time about how to avoid hiring unproductive engineers. And he said he found that baffling. Because an unproductive engineer just costs the company their salary. More important is ferreting out and eliminating negatively productive managers, engineers, and technicians in that order. Algorithms? Why would you care if a programmer knows the details unless that's the job. More important is how they approach and attack a problem. Sometimes a half broken shell script is fine. Or leveraging a database because even though slow an inefficient it will do it right. Half the secret to success is... Um.. seriously just watch this video and you'll know it's truth. https://www.youtube.com/watch?v=q5LiQcY0bqk https://www.youtube.com/watch?v=q5LiQcY0bqk

morgante 12y ago

> In all my years immersed in the tech industry, I have never once heard a firm talk about the idiots lurking in their own offices. They always seem to be elsewhere. For everyone. It certainly sounds like the author doesn't think there are any actual incompetent engineers out there. Personally, I know that to be false. I have worked with incompetent engineers, who literally couldn't code FizzBuzz.

learc83 12y ago
I think the author is saying we should do interviews like nearly every other industry. Look at past experience, and ask the candidate to talk about that experience to verify that they aren't lying. If someone has 5 years experience working at Google, and they can talk coherently about technical aspects of the projects they worked on, there is no reason to ask them to code on a whiteboard. The way it currently works is this: I see you have a CS, degree and 10 years experience at a well known company. Excellent. Now you have 2 eggs and a 100 story skyscraper. Tell me the minimum number of egg drops you'll have to perform to discover the minimum height that will break the egg. Every engineer no matter how experienced has to answer questions like they just left school yesterday, no other industry does this. >Personally, I know that to be false. I have worked with incompetent engineers, who literally couldn't code FizzBuzz. 99 times out of 100 you could catch that engineer by talking to him about technical aspects of past projects he worked on.
- mahyarm 12y ago
  This is why I like to give laptops to engineers and ask to make something simple, that might require logic, but doesn't require any sort of specialized knowledge. They can even look up documentation. Like make a table view that has word counts for a string. Or make this simple puzzle game. Or make a simple address book app.
  - jaredsohn 12y ago
    Just an FYI -- working on someone else's laptop can often be an unpleasant experience (weird keyboard configuration, different software installed, etc.) My current opinion on this would be to offer a laptop so you aren't disadvantaging candidates who don't have one too badly, but let people use their own if they have one (and let them know ahead of time that it will be an option and what they should be set up for.)
    - jghn 12y ago
      We tell candidates up front that they'll be doing some live coding and welcome them to bring their own laptop if they would like. We have a backup around with just about every reasonable IDE and editor installed for our languages but even then I agree, it's definitely not the same using someone else's computer.
      - iopq 12y ago
        I program on my desktop with two monitors, I wouldn't be comfortable on a laptop without at least two extra large monitors hooked up to it already. And a normal keyboard, don't give me that laptop keyboard crap.
        mpercy 12y ago
        Wow... I understand that you'd be much more productive with a large monitor and good keyboard, but to the extent that you couldn't perform in a coding interview? Give me a break... In the past, I've used CollabEdit for "phone screens" and the whiteboard for in-person interviews. I try to ask some "coding" questions (identify a better data structure / algo for a particular scenario and then implement it in code) and some problem-solving conversational questions. Seems to work pretty well, but I'm always on the lookout for better approaches. Part of the problem is that the software field is so broad that it's hard to get a sense of a person's abilities with such a limited amount of time to ask questions.
d23 12y ago
I worked with a guy who, after having been at the company for 6 months, called me over to his desk to help with a "problem." He wondered why he was getting a syntax error. Okay, fair enough. I looked at his screen, and he was putting the arguments to the function OUTSIDE the parentheses. The guy had clearly just been copying and pasting code until "it worked" the entire time he had been there. I almost palmed my face right off of my head.
- theVirginian 12y ago
  To be fair, I have done that before when just messing around on my own late at night. After working for as long as I had been I felt like reading my own code was like wading through sludge and my eyes just didn't catch the error. I was still however well aware that putting the arguments outside the parentheses is not how this works, not how any of this works.
- tormeh 12y ago
  That reminds me of how I deal with C's pointer syntax. "Well, it's either * or & or a combination of a low number of the two, let's try a couple of combinations that seems vaguely reasonable... and some that don't, just in case". I don't know who's most at fault: Me or C.
  - robbles 12y ago
    rule of thumb: "*" means "look up the area of memory this value points to". "&" means the reverse - "give me a reference to this area of memory". The problem with randomly trying things with pointers is that sometimes you can accidentally fix the issue but introduce a subtle bug that's dependent on the data being stored.
  - MaulingMonkey 12y ago
    In case it helps, I've noticed what I'd consider a wart in C that seems to be a common stumbling block with this - including when I first learned C a couple decades ago: * when used for types, has the "opposite" effect when it's used for values/expressions. int* foo; // The addition of a star here, on a type, means we're converting the type /into/ a pointer-to-int /from/ a plain int. int i = *foo; // The addition of a star here, on a value, means we're converting the type /from/ a pointer-to-int /into/ a plain int (reference). I found it much easier to keep the two straight once I segregated their use cases like this. There's a similar duality with & in C++ using references, although not quite as cleanly: int& foo = ...; // The addition of & here, on a type, means we're converting the type /into/ a reference /from/ a plain int. p = &foo; // The addition of & here, on a value, means we're converting the type /from/ a reference /into/ a pointer-to-int. Regardless of "fault", I hope this helps :) (edit: C++ style comments used even in 'C' code to try and prevent YN from treating stars as formatting... replaced a few instances with 'a star'... changed emphasis to use slashes because it's still eating asterisks characters...)
muddyrivers 12y ago
I am not sure if your comment is supposed to reply to mine. I do think there are incompetent engineers, and I have interviewed about a dozen of them. It is very easy to filter them out. The challenging part is to evaluate how good the candidates are, and if they would be good for the team and for the applied positions. In start-ups with <20 engineers, you would like to have the candidates to be able to wear many hats. In a big engineering team, the requirements could be different. For example, besides challenging and creative work, there could be some tedious, even boring, work. The latter is also important, both for the whole system running smoothly and for the long term health of the system. So if the candidate is sufficiently competent, very detail-oriented, disciplined, team-oriented, she/he would be an excellent fit for the job, even if she/he is not technically very strong and couldn't figure out challenging technical issues. An excellent engineer, on the other hand, might get bore, grumpy, and leave in 6 months. It is expensive to restart the hiring process.
hnnewguy 12y ago
>I have worked with incompetent engineers, who literally couldn't code FizzBuzz. Operative word worked. This is exactly what the article says: "They always seem to be elsewhere. For everyone."
- morgante 12y ago
  Uh, no? For the time when I was employed there, they weren't "elsewhere." They were sitting right next to me. (The presence of incompetent engineers was certainly a factor in why I left that job.)
  - hnnewguy 12y ago
    You should work on your reading comprehension. What you're saying is precisely what the author is talking about: everyone has a story about terrible engineers, but they're almost always "elsewhere". Co-workers tend to become "stupid" and "incompetent" after you leave. And yet they maintain employment. It's an idea, not an iron-clad rule, that perhaps "incompetence" isn't as rampant as so many people suggest.
aros 12y ago
You've misunderstood the author's sentence. His point was that many companies tend to think anyone applying for a position is 100% unqualified instead of focusing on the dead weight within. I've anecdotally experienced this in the form of watching employees who contribute near 0 take years to be let go due to internal politics.

Gibbon1 12y ago

I read a really good comment by I think Nolan Bushnell about engineers. He said said he got asked all the time about how to avoid hiring unproductive engineers. And he said he found that baffling. Because an unproductive engineer just costs the company their salary. More important is ferreting out and eliminating negatively productive managers, engineers, and technicians in that order. Algorithms? Why would you care if a programmer knows the details unless that's the job. More important is how they approach and attack a problem. Sometimes a half broken shell script is fine. Or leveraging a database because even though slow an inefficient it will do it right. Half the secret to success is... Um.. seriously just watch this video and you'll know it's truth. https://www.youtube.com/watch?v=q5LiQcY0bqk https://www.youtube.com/watch?v=q5LiQcY0bqk