5 ms·
It took the author of the article 10 years of interviewing candidates to realize this? Ok, it's the author that sucks at his job. I'm sorry if that is not ver
by justin_vanw 17y ago
It took the author of the article 10 years of interviewing candidates to realize this?
Ok, it's the author that sucks at his job. I'm sorry if that is not very constructive, but if I had to choose between having the horror show developer he describes on staff for 10 years taking up a cubicle and a paycheck, or the author on staff for 10 years hiring retards, I would take the horror show developer, as he would do far less damage in the long run.
Probably the author just has a positive view of people, and tends to see the best in people, or believes people when they tell him things. This would be fine for many jobs, but interviewing candidates requires a willingness to ruin someone's week. It is never the goal, but if a totally unqualified candidate shows up you must be willing to push them to answer questions so that you know that they are unqualified.
In any developer interview, you really only need to cover the following things:
- The person knows what they should know, based on their resume.
- If they say they were a linux administrator for 2 years, they should know all about linux basics and shell basics, they should be able to run a machine remotely without breaking it, they should not be dependent on any gui tools, they should know the common server software people run, and so on.
- If they were a web developer for 2 years, they should know about the stuff they supposedly doing, if it was backend code they should know about cache control headers and how ajax requests are or are not cached by the big browsers, they should know POST and GET and when to use them, and so on.
Anyone who doesn't know the things they 'should' know cannot be considered further, either they are lying on their resume or they are just turds who don't learn anything.
- They should be able to demonstrate an ability to code on the spot right in front of you. Some people claim they cannot code in front of someone else. Other than someone with an anxiety disorder, if a person can't code in front of another person it is just because they can't code at all. If their code is incorrect or suboptimal the main thing is that when you go over it they smack themselves on the forhead and seem annoyed that they would make such a mistake, and that they see right away how what they coded is wrong. If they can't get some challenging thing exactly right isn't such a problem as not 'being with it'.
- They should be sane and law abiding, not a drug user (and here I mean drug use which you can notice or that they *brag about), and that they have an ability to conform to some baseline social norms, such as bathing every third day or better, washing their hair and clothes occasionally, use and empty their trashcan, being able to talk to people without freaking out, and not going off on people or constantly insisting on doing things however they want to do it without strong rational each time.
This is basically 'smart, gets things done, can do things (vs coercing others to pick up their slack), makes a point to learn about what they are supposed to be doing, and isn't filthy or crazy.'
- kiba 17y agoYou may need to reread it again. Nowhere did I hear that it took him ten years to become a good reviewer. In fact, the last sentence in the first paragraph is very telling. In my early years I was very much hit and miss in terms of finding the right people and it wasn’t until a horror hire that I realised what I was doing wrong.
- justin_vanw 17y agoYou may be right.
- edw519 17y agoif a person can't code in front of another person it is just because they can't code at all Never thought of it that way before, but it makes perfect sense. If you can ride a bike, change a flat tire, or balance a checkbook, you can do it alone or in front of others. Why not the same for programming?
- deleted 17y ago[deleted]
- justin_vanw 17y agoI don't think it's intentional deception. There are a large number of 'programmers' who read slashdot and reddit and so on religiously. They probably hold a job where they are a developer of some sort, and they know about all the buzzy hot stuff out there from reading about it, but when they sit down to code they don't get anything done. Usually they manage to carve out a niche in whatever organization they are in doing non-coding tasks. They are complete wastes of whatever resources they consume, but they are totally oblivious to this either for psychological reasons (ego defense or something) or the usual 'incompetent people have no way to detect incompetence', but probably a generous helping of each, ego defenses prevent them from integrating the memory of each failure they are responsible for (when they are fired from one job they aren't qualified for they just apply for another job they aren't qualified for) and the incompetence thing means they are unable to detect any real reason for their suckiness, leaving them with only the potential explanations they can come up with (usually stuff about how they were distracted or were having personal problems or had too many things going at once, as they are convinced that if they could just sit long enough and work at it they would eventually get it done. They are of course wrong, no amount of time would allow them to succeed at the task in question.)