3 ms·

I strongly agree. This problem applies both to the interview process and to evaluating the performance of engineers after hiring them. A lot of companies try t

I strongly agree. This problem applies both to the interview process and to evaluating the performance of engineers after hiring them. A lot of companies try to use supposedly "data-oriented" approaches to hiring. They assume that a "successful" interview process hires candidates who get good performance reviews a year later. But those reviews are just as subjective as the hiring process. If your metric for "success" is whether you still like someone a year from now, you might as well just hire whomever you like today!

andrewstuart 9y ago
Yes and no. I still think you can have an effective recruiting process which attempts to identify someone's attributes across a range of criteria - I attempted to identify some of those characteristics here: http://www.supercoders.com.au/blog/50characteristicsofagreatsoftwaredeveloper.shtml http://www.supercoders.com.au/blog/50characteristicsofagreat... You would fail entirely in your recruiting effort if you just hired "whomever you like today" - you must make some attempt to measure a persons capabilities. What I am attempting to dispel is the idea that it is possible to measure someone as a "great developer" because it is a matter of opinion - person A may think someone is a "great developer", person B may not. I also think that pretty much every recruiting process at every company is "Voodoo Recruiting", or "Recruiting Theatre" - the appearance of rigor and scientific approach, but really just a show that allows the assessor to feel like some scientific, justifiable process has been executed that has resulted in a "correct" hiring "go/no go" decision, but in fact does nothing more than make people feel comfortable with making a subjective decision in the end. Whether or not someone is a great developer also changes according to time and context. What I mean by this is that some developer X who got amazing results in some job that they had, might be judged as being a shit developer when put into a job where they weren't inspired by the project, were working with unfamiliar technologies, where they are in a life phase dealing with depression, or where their colleagues or boss treated them without respect. Suddenly "great developer" in some previous context is now seen as a shit developer in some other context... again, it is simply not possible to evaluate a given person in a job interview and determine if they are "a great developer".
- JamesBarney 9y ago
  100% agree. I had two jobs doing maintenance on very large(millions of LoC) projects that brought in significant revenue. And there success was making sure your code was bullet proof. And resisting the temptation to do any refactoring. Everything should work was close to how it's always worked. So a good fix was one that was a very specific if statement that covered a very small edge case. This was a very different measure of success from the couple of large Enterprise companies where I worked on new projects, where success was managing 4 different stakeholders with a conflicting set of requirements. And meticulously following large sets of rules and processes around code. Which was a different from building an mvp for a startup where shipping as much code as possible mattered, technical debt didn't matter, breaking things was ok, and there was only one stakeholder to manage. Sometimes you can find one person who fits all these roles, but there are a lot of developers who would be great developers in some of the roles, and not others.

andrewstuart 9y ago

Yes and no. I still think you can have an effective recruiting process which attempts to identify someone's attributes across a range of criteria - I attempted to identify some of those characteristics here: http://www.supercoders.com.au/blog/50characteristicsofagreatsoftwaredeveloper.shtml http://www.supercoders.com.au/blog/50characteristicsofagreat... You would fail entirely in your recruiting effort if you just hired "whomever you like today" - you must make some attempt to measure a persons capabilities. What I am attempting to dispel is the idea that it is possible to measure someone as a "great developer" because it is a matter of opinion - person A may think someone is a "great developer", person B may not. I also think that pretty much every recruiting process at every company is "Voodoo Recruiting", or "Recruiting Theatre" - the appearance of rigor and scientific approach, but really just a show that allows the assessor to feel like some scientific, justifiable process has been executed that has resulted in a "correct" hiring "go/no go" decision, but in fact does nothing more than make people feel comfortable with making a subjective decision in the end. Whether or not someone is a great developer also changes according to time and context. What I mean by this is that some developer X who got amazing results in some job that they had, might be judged as being a shit developer when put into a job where they weren't inspired by the project, were working with unfamiliar technologies, where they are in a life phase dealing with depression, or where their colleagues or boss treated them without respect. Suddenly "great developer" in some previous context is now seen as a shit developer in some other context... again, it is simply not possible to evaluate a given person in a job interview and determine if they are "a great developer".

JamesBarney 9y ago
100% agree. I had two jobs doing maintenance on very large(millions of LoC) projects that brought in significant revenue. And there success was making sure your code was bullet proof. And resisting the temptation to do any refactoring. Everything should work was close to how it's always worked. So a good fix was one that was a very specific if statement that covered a very small edge case. This was a very different measure of success from the couple of large Enterprise companies where I worked on new projects, where success was managing 4 different stakeholders with a conflicting set of requirements. And meticulously following large sets of rules and processes around code. Which was a different from building an mvp for a startup where shipping as much code as possible mattered, technical debt didn't matter, breaking things was ok, and there was only one stakeholder to manage. Sometimes you can find one person who fits all these roles, but there are a lot of developers who would be great developers in some of the roles, and not others.