6 ms·

In a certain state of the economy, you're right. But, at least here in the US, we currently have way more demand for good developers than we have supply. Basi

by ap22213 13y ago

In a certain state of the economy, you're right. But, at least here in the US, we currently have way more demand for good developers than we have supply. Basic economics says that your model will not work. For example, the company for which I work bills me out at $250 / hr. I get something like 15-30 job requests from other companies a week. It would not make any economic sense for me to pursue any of these other companies unless the interview process was dead simple, transparent, and easy (and the total compensation was _at least_ 15% higher than my current compensation). But, 99% of them will only offer modest pay adjustment (%2-3?), and then they expect me to sit through several hours of interviews. And, if I pass that nontransparent process, they ask me to sign a ridiculous employment agreement that signs away all my personal IP. Seriously? The problem with recruiting today is that most companies who have good talent understand how valuable their best talent is. They treat them very well. And, the companies that want to obtain that talent completely under-offer their side of the deal. Another problem is that most developers suck at negotiation. I see lots of anger on HN about not getting the 6-figure salary. Well, that's their fault for not asking for it. If they're a relatively good developer (top 25%), they should be making at least 6-figure, easy. And, if they're not, that's their fault, not the fault of others that know their value and how to demand a cut of it.

deleted 13y ago
[deleted]
mason55 13y ago
> But, at least here in the US, we currently have way more demand for good developers than we have supply. Basic economics says that your model will not work. The problem is that hiring someone who can't code doesn't help me. And a bad engineer is worse than no engineer at all. It's not like a grocery store where a bad employee is just really slow and a really bad employee steals things costing me a percent of a percent on my margins. A single bad engineer could theoretically destroy a company if they were savvy enough. Pretty much anyone who does technical hiring will tell you that it's way worse to hire a bad candidate than to not hire a good one and interviews are tuned for that. It's the opposite of the American criminal justice system. A no-hire doesn't mean you're a bad candidate but a hire recommendation is very likely to mean that you're a good one.
- zenbowman 13y ago
  Exactly, I prefer this feet-to-the-fire hiring process that we have now by far to the previous "hire him if he looks and sounds good" which results in far too many bs artists working in the field.
- freework 13y ago
  > A single bad engineer could theoretically destroy a company if they were savvy enough. This sentence does not compute. Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if they fail to hire a great developer then its no big deal, but if they accidentally hire a bad developer, their company will all go to shit. This results in crazy interview multi-hour processes. In the real world, the worst employees rarely ever negate the work of more experienced workers. Thats like saying if you hire a bad teacher, students will forget information rather than learn.
  - tekromancr 13y ago
    I think bad in this sense is malicious as opposed to incompetent.
    - vonmoltke 13y ago
      There is almost nothing about multi-hour coding interviews that does anything to filter out the malicious, unless they happen to be incompetent as well. Screening out malicious people is a very hard task.
  - vonmoltke 13y ago
    Agreed. Many people parrot this line, but I have not seen anyone put actual data behind it. I have seen made-up scenarios about what could happen. Those usually stick to near worst case situations, though, with no indication of the actual risk. People also seem to minimize or ignore the cost of a no-hire. If your company has an open position it is trying to fill, it should be feeling pain. Work isn't getting done. Projects or clients can't be bid on. Current engineers are working overtime to meet commitments. If you can look at this situation, shrug your shoulders, and say, "Eh, we're going along fine. We can wait several months for a perfect fit.", then I think you need to re-evaluate why you have an open position in the first place. I would like to see some actual data to back up this conception. Something that gives the actual statistical risk. As someone mentioned on another story here recently, humans tend to over-estimate the risks of negative events. I think the risk of bad hires in SV has been seriously over-estimated.
skarmklart 13y ago
If they're a relatively good developer (top 25%) How does one know that one is a top developer? I'd imagine it's easy to have a false knowledge of being in the top 25% (what with Dunning-Krueger and all) but how does a true top 25 percenter know that he is such?
- ap22213 13y ago
  I think it's relatively easy if you work within companies of a certain size. If so, compare yourself to another 100 developers that you've worked with. If you only work with start-ups, it may be more difficult. Questions to ask yourself: - Do you consistently get higher ratings than your peers? - Do other developers come to you first if they want advice on the correct way to do something? - Have you produced features that cause applause in sales teams or customers? - Have all of your products been successful (maybe allowing for slips in schedule or budget)? - Do people understand your code? (i.e. do you get a lot of emails from people asking to explain things?) - Do features that you have created have significantly fewer bugs than other features? - Do tech leads or product managers seek you out to help them build products or features?
  - skarmklart 13y ago
    This is also a good scale to use: https://michaelochurch.wordpress.com/2013/04/22/gervais-macleod-23-the-shodan-programmer/ https://michaelochurch.wordpress.com/2013/04/22/gervais-macl...
sharingancoder 13y ago
On an unrelated note, I'm curious to know which company this is that hires you out? I'm guessing SAIC is the current client and not the parent company (or am I looking at the wrong LinkedIn profile!)
zerr 13y ago
$250/hr is great, but may I ask you - is it a regular job? i.e. 40 hr/weeks for say 1-2 years or so... Or you negotiate for each small tasks, thus having some overheads?

by ap22213 13y ago

deleted 13y ago

[deleted]

mason55 13y ago

> But, at least here in the US, we currently have way more demand for good developers than we have supply. Basic economics says that your model will not work. The problem is that hiring someone who can't code doesn't help me. And a bad engineer is worse than no engineer at all. It's not like a grocery store where a bad employee is just really slow and a really bad employee steals things costing me a percent of a percent on my margins. A single bad engineer could theoretically destroy a company if they were savvy enough. Pretty much anyone who does technical hiring will tell you that it's way worse to hire a bad candidate than to not hire a good one and interviews are tuned for that. It's the opposite of the American criminal justice system. A no-hire doesn't mean you're a bad candidate but a hire recommendation is very likely to mean that you're a good one.

zenbowman 13y ago
Exactly, I prefer this feet-to-the-fire hiring process that we have now by far to the previous "hire him if he looks and sounds good" which results in far too many bs artists working in the field.
freework 13y ago
> A single bad engineer could theoretically destroy a company if they were savvy enough. This sentence does not compute. Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if they fail to hire a great developer then its no big deal, but if they accidentally hire a bad developer, their company will all go to shit. This results in crazy interview multi-hour processes. In the real world, the worst employees rarely ever negate the work of more experienced workers. Thats like saying if you hire a bad teacher, students will forget information rather than learn.
- tekromancr 13y ago
  I think bad in this sense is malicious as opposed to incompetent.
  - vonmoltke 13y ago
    There is almost nothing about multi-hour coding interviews that does anything to filter out the malicious, unless they happen to be incompetent as well. Screening out malicious people is a very hard task.
- vonmoltke 13y ago
  Agreed. Many people parrot this line, but I have not seen anyone put actual data behind it. I have seen made-up scenarios about what could happen. Those usually stick to near worst case situations, though, with no indication of the actual risk. People also seem to minimize or ignore the cost of a no-hire. If your company has an open position it is trying to fill, it should be feeling pain. Work isn't getting done. Projects or clients can't be bid on. Current engineers are working overtime to meet commitments. If you can look at this situation, shrug your shoulders, and say, "Eh, we're going along fine. We can wait several months for a perfect fit.", then I think you need to re-evaluate why you have an open position in the first place. I would like to see some actual data to back up this conception. Something that gives the actual statistical risk. As someone mentioned on another story here recently, humans tend to over-estimate the risks of negative events. I think the risk of bad hires in SV has been seriously over-estimated.

skarmklart 13y ago

If they're a relatively good developer (top 25%) How does one know that one is a top developer? I'd imagine it's easy to have a false knowledge of being in the top 25% (what with Dunning-Krueger and all) but how does a true top 25 percenter know that he is such?

ap22213 13y ago
I think it's relatively easy if you work within companies of a certain size. If so, compare yourself to another 100 developers that you've worked with. If you only work with start-ups, it may be more difficult. Questions to ask yourself: - Do you consistently get higher ratings than your peers? - Do other developers come to you first if they want advice on the correct way to do something? - Have you produced features that cause applause in sales teams or customers? - Have all of your products been successful (maybe allowing for slips in schedule or budget)? - Do people understand your code? (i.e. do you get a lot of emails from people asking to explain things?) - Do features that you have created have significantly fewer bugs than other features? - Do tech leads or product managers seek you out to help them build products or features?
- skarmklart 13y ago
  This is also a good scale to use: https://michaelochurch.wordpress.com/2013/04/22/gervais-macleod-23-the-shodan-programmer/ https://michaelochurch.wordpress.com/2013/04/22/gervais-macl...

sharingancoder 13y ago

On an unrelated note, I'm curious to know which company this is that hires you out? I'm guessing SAIC is the current client and not the parent company (or am I looking at the wrong LinkedIn profile!)

zerr 13y ago

$250/hr is great, but may I ask you - is it a regular job? i.e. 40 hr/weeks for say 1-2 years or so... Or you negotiate for each small tasks, thus having some overheads?