6 ms·

> If you're unwilling to provide proof you're not a bozo, you're probably going to be just awful to work with as well. I always liked the idea of people lookin

by rb2k_ 14y ago

> If you're unwilling to provide proof you're not a bozo, you're probably going to be just awful to work with as well. I always liked the idea of people looking at your previous work (github, ...) and having a pleasant conversation about it rather than making engineers jump through hoops. Especially if the company comes to you I think it's a weird thing that they'd assume you're a "bozo". Given how lax the US employment laws are, you can always fire somebody if they turn out to be a bozo after all.

varelse 14y ago
So here's where we have to agree to disagree. A pleasant conversation about your previous work is great, really, and as part of a complete package, likely to send you right to the top of my list. However, in my experience, the tech industry is overflowing with pretenders. If I haven't met you personally, those github records are of limited use as there's no way to prove you actually did the work in question. I apologize for the paranoia upfront, but once a bozo gets into the foodchain, they can do a lot of damage before getting expelled. And in the end, the kind of technical questions I ask are so basic that unless you haven't programmed in years or you've never read a programming or algorithms book in your life, you'll get them. What's really disappointing is how few do get them lately. But I attribute that more to the current environment of recruiter cold-calling as opposed to a decline in the expertise of programmers. Much like in dating, most of the "good ones" are taken, and if not, they don't stay on the market very long.
- jessedhillon 14y ago
  Is your mentality typical of Google hiring practices? As long as we're going by anecdotal evidence here, nothing you've said here rings true. I've found great engineers by chatting with them -- if you can't separate a great, well-accomplished engineer from a faker by talking with him/her at length about their previous work, then IMHO the problem is with you, not them. You said it best -- the process you describe above is reflective of a paranoid, neurotic obsession to have "the best" engineers, for some definition of best. Whether or not we agree on what constitutes "best" is not important, but if you insist that people who refuse, or fail, your particular method are bozos then you have your head stuck firmly up your ass.
  - xenen 14y ago
    I think the problem is the fact that we have two types of engineers: the academic geeks, and the creative geeks. I wouldn't give anyone a pass if they show no personality, creativity and out-of-the-box thinking with good product intuition during my interview. Vice versa, I don't think any academic geeks would give me a pass if I couldn't solve their math puzzles with a proof. I could be just talking out of my ass here, but it is nonetheless how I see this situation. I don't like it, but I don't see any evidence of it changing anytime soon.
    - varelse 14y ago
      In an interview, I have 30-60 minutes to figure out whether I want to hire you or not. My team writes a lot of code. Therefore, I'm going to ask you what your favorite language is and then test your ability to write 10-20 lines of code in that language to solve a relatively simple problem. If you can't do that, it seems to me that a) you don't like to write code and therefore I shouldn't hire you or b) you're out of practice and shouldn't have claimed expertise or c) you're a poser. If your expertise is with something else, go apply for positions that require skill with said "something else" as we'll both be a lot happier that way. It's a completely different situation if I know you personally but 95% of the time I don't and I have to make a quick decision.
      - deleted 14y ago
        [deleted]
      - randomdata 14y ago
        Keep in mind that if we only have 30-60 minutes together, I'm going to be putting forth a lot of energy in determining if you are even worth working for or are just another bozo boss/company. It is just as risky on my part as it is yours. That doesn't leave a lot of time to think about any challenges you send my way, no matter how easy they may be. It feels to me like such a process tries to shift the power towards the employer, to make it seem like you would be lucky to even have a chance to work there and focus the time wholly on the business needs, when it really should be a mutual discussion to see if both parties feel it is a good fit. Passing your test with flying colours only to find we are a terrible match is just as damaging as hiring a bozo to begin with, no?
- 23david 14y ago
  If your concern is to ensure that you're not getting a coding bozo, I think that your tests are designed incorrectly. Instead of having a 'simple test', just find some random, buggy sub-optimal code sample online (shouldn't be hard) and ask them to identify the problems with it and refactor. I can almost guarantee you that bozos won't see half the problems, and they definitely won't know how to fix them. Asking someone to code up simple examples on a board ends up just testing a dude's ability to code up simple coding questions. Bug finding/fixing, creating readable and elegant code and the ability to refactor are all much more relevant and important than asking if someone can implement a sorting algorithm or parse a custom data structure. In the end, I think that by testing candidates this way it'll make it more likely that the people you hire actually have skills that are important to their daily work.

by rb2k_ 14y ago

varelse 14y ago

So here's where we have to agree to disagree. A pleasant conversation about your previous work is great, really, and as part of a complete package, likely to send you right to the top of my list. However, in my experience, the tech industry is overflowing with pretenders. If I haven't met you personally, those github records are of limited use as there's no way to prove you actually did the work in question. I apologize for the paranoia upfront, but once a bozo gets into the foodchain, they can do a lot of damage before getting expelled. And in the end, the kind of technical questions I ask are so basic that unless you haven't programmed in years or you've never read a programming or algorithms book in your life, you'll get them. What's really disappointing is how few do get them lately. But I attribute that more to the current environment of recruiter cold-calling as opposed to a decline in the expertise of programmers. Much like in dating, most of the "good ones" are taken, and if not, they don't stay on the market very long.

jessedhillon 14y ago
Is your mentality typical of Google hiring practices? As long as we're going by anecdotal evidence here, nothing you've said here rings true. I've found great engineers by chatting with them -- if you can't separate a great, well-accomplished engineer from a faker by talking with him/her at length about their previous work, then IMHO the problem is with you, not them. You said it best -- the process you describe above is reflective of a paranoid, neurotic obsession to have "the best" engineers, for some definition of best. Whether or not we agree on what constitutes "best" is not important, but if you insist that people who refuse, or fail, your particular method are bozos then you have your head stuck firmly up your ass.
- xenen 14y ago
  I think the problem is the fact that we have two types of engineers: the academic geeks, and the creative geeks. I wouldn't give anyone a pass if they show no personality, creativity and out-of-the-box thinking with good product intuition during my interview. Vice versa, I don't think any academic geeks would give me a pass if I couldn't solve their math puzzles with a proof. I could be just talking out of my ass here, but it is nonetheless how I see this situation. I don't like it, but I don't see any evidence of it changing anytime soon.
  - varelse 14y ago
    In an interview, I have 30-60 minutes to figure out whether I want to hire you or not. My team writes a lot of code. Therefore, I'm going to ask you what your favorite language is and then test your ability to write 10-20 lines of code in that language to solve a relatively simple problem. If you can't do that, it seems to me that a) you don't like to write code and therefore I shouldn't hire you or b) you're out of practice and shouldn't have claimed expertise or c) you're a poser. If your expertise is with something else, go apply for positions that require skill with said "something else" as we'll both be a lot happier that way. It's a completely different situation if I know you personally but 95% of the time I don't and I have to make a quick decision.
    - deleted 14y ago
      [deleted]
    - randomdata 14y ago
      Keep in mind that if we only have 30-60 minutes together, I'm going to be putting forth a lot of energy in determining if you are even worth working for or are just another bozo boss/company. It is just as risky on my part as it is yours. That doesn't leave a lot of time to think about any challenges you send my way, no matter how easy they may be. It feels to me like such a process tries to shift the power towards the employer, to make it seem like you would be lucky to even have a chance to work there and focus the time wholly on the business needs, when it really should be a mutual discussion to see if both parties feel it is a good fit. Passing your test with flying colours only to find we are a terrible match is just as damaging as hiring a bozo to begin with, no?
23david 14y ago
If your concern is to ensure that you're not getting a coding bozo, I think that your tests are designed incorrectly. Instead of having a 'simple test', just find some random, buggy sub-optimal code sample online (shouldn't be hard) and ask them to identify the problems with it and refactor. I can almost guarantee you that bozos won't see half the problems, and they definitely won't know how to fix them. Asking someone to code up simple examples on a board ends up just testing a dude's ability to code up simple coding questions. Bug finding/fixing, creating readable and elegant code and the ability to refactor are all much more relevant and important than asking if someone can implement a sorting algorithm or parse a custom data structure. In the end, I think that by testing candidates this way it'll make it more likely that the people you hire actually have skills that are important to their daily work.