4 ms·

You hit the nail in the head, in my career I have fired 3 people (managed thousands). In the interview game to many people focus on the how long have you used X

by kls 17y ago

You hit the nail in the head, in my career I have fired 3 people (managed thousands). In the interview game to many people focus on the how long have you used X technology instead of the person themselves. It is real easy people, interview the person and look for passion, seriously it overcomes all else. As long as the person has no obvious glaring personality flaws and passion, the rest will fall into place. People in tech careers are for the most part self driven and want to do what they do. If you (anyone in general) have had a problem with more than 5% of the people who have worked for you, then you may be the problem. Trust me I have meet far more incompetent tech managers than I ever have tech employees. Who by the way are generally skeptical people who don't follow leaders that they do not respect. Given the grandparents cavalier attitude about firing tech people and the authors I would suspect that they are failing to position themselves as a leader in their technical talents eyes, and loosing their trust with every termination. Seriously firing people does psychological damage to those that remain, it shows a lack of investment in people that resounds in their mind, it should be reserved for those that refuse to work for whatever reason.

hga 17y ago
How do you figure out if purported programmers can "program their way out of a paper bag"? As long as you have a good (enough) method for doing that I agree with everything you say above.
- jacquesm 17y ago
  My way of addressing that part was to simply ask what the most complicated thing was they ever programmed, and then to ask one or two follow up questions about that. I've got enough field experience that just by asking that one question I'd be able to come up with a follow up question that would nail a 'poser' in one go, if the answer was satisfactory I'd let it go at that and assume they're telling the truth, if not then I would ask one or two more follow up questions and by then I'd usually know for sure if someone is fibbing or just nervous (people can be very nervous during interviews, the bigger problem to me always was to not discard 'good' people that are simply nervous and botch answers to questions rather than the fear of hiring the wrong person because they manage to bamboozle me). Another thing I did was to take as much time as I wanted during an interview, I would schedule at most one interview per half day just to make sure that I didn't have to cut an interview short. This made the interview process more relaxed and on the whole gave me enough time to figure out what made someone tick. Most interviews were over very quickly anyway, but every now and then it took a long time to get a feeling for whether or not someone would fit. One of my biggest discoveries was that when hiring someone good that they would refer their friends, and they would be pretty critical about who they'd refer, screening out a lot of potential duds for me without any effort on my part. In the Toronto office we ended up hiring four guys that already knew each other previous to joining the company. This can also work against you, another 'group of friends' applied and I would have been happy to hire just one of them, he stuck with his friends instead. I once hired a guy that just wanted to learn how to program but did not yet have the ability. This was a risky move, because as a startup you don't really have the time to invest a lot of it in to a person that is not yet proven. But it worked out very well, and Jeffrey actually was one of our most reliably productive people, in part because we gave him a chance that probably nobody else would have. Sometimes having a will and a drive trumps technical ability.
  - hga 17y ago
    Interesting. I've never had the luxury of hiring a non-programmer to learn on the job, but I can see how it could work out. But perhaps you mean "technical ability when hired". I certainly am willing to let someone learn a lot of stuff on the job, including a new language. However I quibble with your last point, or at least say that some jobs require an ability to grok abstraction, recursion and/or pointers and that no amount of will can overcome an inability to do that. I'll also note that some paradigms cannot be quickly learned by most. I observed that in general for OO when it became "the thing" in the '90s and I suspect functional programming also takes "more than a month". E.g. one thing I'm saying here is that you couldn't necessarily expect a procedural programmer who already knew C to be able to really learn C++ or Java in a month. Yeah, they could learn how to write C in those languages, but learning the OO paradigm took longer. Then again, the OO paradigms I learned (which did not include any Smalltalk ones) were both very hard (to get right) and I now think they are also very wrong. Learning functional programming might be much easier for those with flexible minds.
    - jacquesm 17y ago
      Hence the 'sometimes', that one person was an exception both in that I hired him without the ability to program yet and in the fact that he actually came through in the end, I doubt that that is something you should try to repeat. I just got lucky. The way I found him was that his father was the cleaner at our offices and if I would please give his son one chance. I did and I never regretted it for one second.
    - gruseom 17y ago
      Then again, the OO paradigms I learned (which did not include any Smalltalk ones) were both very hard (to get right) and I now think they are also very wrong. Based on this and your other comments, I'd like to hear more about how you came to this conclusion. This isn't the right thread for it, though... perhaps, if you're interested in writing about it, you could make a new post?
      - hga 17y ago
        I can put it simply: the only thing worse than an imperative style with side effects is one where the side effects are chained, in this case through a set of interacting objects. I came to it from the hard experience of doing it, e.g. think sequence diagrams; the methodology was OOSE. However lately I have been wondering about the utility of this approach for GUIs.
- kls 17y ago
  In my opinion that is the easy part, It is a testable skill (not trick questions). I always have a dummy environment set up with a skeleton app set up and once I am down to the last few quys I ask them to write something from scratch. Generally something simple like a CRUD screen that takes no more than an hour. I generally pair with them and work as a sound board to work out the problem with them. It is very natural and puts a real developer in an environment they are comfortable with. As soon as they see an IDE and no trick questions, the good ones tend to fall into a groove. The cool part is that I have learned so many tricks from many of these sessions.

by kls 17y ago

hga 17y ago

How do you figure out if purported programmers can "program their way out of a paper bag"? As long as you have a good (enough) method for doing that I agree with everything you say above.

jacquesm 17y ago
My way of addressing that part was to simply ask what the most complicated thing was they ever programmed, and then to ask one or two follow up questions about that. I've got enough field experience that just by asking that one question I'd be able to come up with a follow up question that would nail a 'poser' in one go, if the answer was satisfactory I'd let it go at that and assume they're telling the truth, if not then I would ask one or two more follow up questions and by then I'd usually know for sure if someone is fibbing or just nervous (people can be very nervous during interviews, the bigger problem to me always was to not discard 'good' people that are simply nervous and botch answers to questions rather than the fear of hiring the wrong person because they manage to bamboozle me). Another thing I did was to take as much time as I wanted during an interview, I would schedule at most one interview per half day just to make sure that I didn't have to cut an interview short. This made the interview process more relaxed and on the whole gave me enough time to figure out what made someone tick. Most interviews were over very quickly anyway, but every now and then it took a long time to get a feeling for whether or not someone would fit. One of my biggest discoveries was that when hiring someone good that they would refer their friends, and they would be pretty critical about who they'd refer, screening out a lot of potential duds for me without any effort on my part. In the Toronto office we ended up hiring four guys that already knew each other previous to joining the company. This can also work against you, another 'group of friends' applied and I would have been happy to hire just one of them, he stuck with his friends instead. I once hired a guy that just wanted to learn how to program but did not yet have the ability. This was a risky move, because as a startup you don't really have the time to invest a lot of it in to a person that is not yet proven. But it worked out very well, and Jeffrey actually was one of our most reliably productive people, in part because we gave him a chance that probably nobody else would have. Sometimes having a will and a drive trumps technical ability.
- hga 17y ago
  Interesting. I've never had the luxury of hiring a non-programmer to learn on the job, but I can see how it could work out. But perhaps you mean "technical ability when hired". I certainly am willing to let someone learn a lot of stuff on the job, including a new language. However I quibble with your last point, or at least say that some jobs require an ability to grok abstraction, recursion and/or pointers and that no amount of will can overcome an inability to do that. I'll also note that some paradigms cannot be quickly learned by most. I observed that in general for OO when it became "the thing" in the '90s and I suspect functional programming also takes "more than a month". E.g. one thing I'm saying here is that you couldn't necessarily expect a procedural programmer who already knew C to be able to really learn C++ or Java in a month. Yeah, they could learn how to write C in those languages, but learning the OO paradigm took longer. Then again, the OO paradigms I learned (which did not include any Smalltalk ones) were both very hard (to get right) and I now think they are also very wrong. Learning functional programming might be much easier for those with flexible minds.
  - jacquesm 17y ago
    Hence the 'sometimes', that one person was an exception both in that I hired him without the ability to program yet and in the fact that he actually came through in the end, I doubt that that is something you should try to repeat. I just got lucky. The way I found him was that his father was the cleaner at our offices and if I would please give his son one chance. I did and I never regretted it for one second.
  - gruseom 17y ago
    Then again, the OO paradigms I learned (which did not include any Smalltalk ones) were both very hard (to get right) and I now think they are also very wrong. Based on this and your other comments, I'd like to hear more about how you came to this conclusion. This isn't the right thread for it, though... perhaps, if you're interested in writing about it, you could make a new post?
    - hga 17y ago
      I can put it simply: the only thing worse than an imperative style with side effects is one where the side effects are chained, in this case through a set of interacting objects. I came to it from the hard experience of doing it, e.g. think sequence diagrams; the methodology was OOSE. However lately I have been wondering about the utility of this approach for GUIs.
kls 17y ago
In my opinion that is the easy part, It is a testable skill (not trick questions). I always have a dummy environment set up with a skeleton app set up and once I am down to the last few quys I ask them to write something from scratch. Generally something simple like a CRUD screen that takes no more than an hour. I generally pair with them and work as a sound board to work out the problem with them. It is very natural and puts a real developer in an environment they are comfortable with. As soon as they see an IDE and no trick questions, the good ones tend to fall into a groove. The cool part is that I have learned so many tricks from many of these sessions.