4 ms·

Hmm.. this viewpoint needs a bit of balancing: - An employer has money and needs a developer. A developer needs the money. If the employer has foresight, then t

Hmm.. this viewpoint needs a bit of balancing: - An employer has money and needs a developer. A developer needs the money. If the employer has foresight, then the developer is at a disadvantage in this early stage of the relationship because it allows the employer to put out a ridiculous sounding job requirement yet still get a decent developer by playing the numbers game (interview lots of devs; hire one temporarily and fire them if they're no good.. then hire another etc...). With that in mind, lets look at the points: #1) We need some guy who should probably know all these things because we use them all.. somewhere.. in our organization. The more they know all these thing, the more useful they'll be to us from day 1. #2) We need someone who has a pair. Either from experience or sheer will. Come in and show us that you're the one we need. If the big numbers scare you, then you're probably not our guy anyway. We also use a few old technologies that have served us very well - it would be fantastic if you already know them. #3) You're not a unique or a beautiful little snowflake. You'll find out how we work when you get here. If you can't adapt, you'll leave - probably against your will. #4) The last guy who did this job was awesome. He worked hard to help us become who we are now. We expect no less of you. #5) We do things a certain way and it seems to be working for us. We expect you to respect that, considering we don't even know you yet. You'll have plenty of opportunity to help make this a more welcoming place if a) we hire you, and b) you don't forget all these pain points once you come on board, and are motivated to do more than just your job description. Jobs are like girlfriends (or boyfriends) are like most relationships. They may or may not start out smoothly. You'll find out that they're single (existence of job ad), kinda cute ($, benefits), and maybe, but they might only be nice to their friends and a firewall to everyone else (job description / initial response etc..). They are all different, and it is up to you to find one to fall in-love with.

roc 17y ago
> "An employer has money and needs a developer. A developer needs the money. If the employer has foresight, then the developer is at a disadvantage in this early stage of the relationship" Frankly, if you approach hiring with this mindset you're only going to get a good developer through sheer luck. As evidenced from your justifications: you're searching for the cheapest cog.
- vishaldpatel 17y ago
  If by cheapest you mean, a good cog for a good price, then yes, that is exactly what an employer wants. At the end of the day, everyone likes to feel like a winner. While it would be nice for everyone to be great and welcoming from the outset, it isn't realistic to have that expectation. If we inspect the job ads out there, it is pretty obvious that many employers feel that they can get away with a crappy job ad but still get the cog of their needs with it. So this may not be sheer luck - there are probably more good developers than companies with great job descriptions. But yes, I do agree that a company can increase its chances significantly by tailoring a job description to its intended audience a bit better (but perhaps they already are? ;)).
timwiseman 17y ago
#3) You're not a unique or a beautiful little snowflake. You'll find out how we work when you get here. If you can't adapt, you'll leave - probably against your will. This one is interesting. Now, I would never consider myself a "unique or beautiful little" anything, but I do strive for excellence and I think most good developers/DBAs/any other position that requires any creativity also do that. This does mean that the good ones are not cogs where you can easily substitute one of us for another. I would be reluctant to work for any company that wanted to treat me as a replaceable cog. While I have done it in the past and would do it again in the future if I had to, I think and hope I am long past the point where I would have to work for a company like that again. As for the adaptation, I agree to a degree. Starting any new job involves adaptation. With that said, what kind of adaptation the company expect plays a large role in how interested I would be in the job. A company that expects me to adapt because they are on the bleeding edge of tech, or wants me to work with something that is both new to me and interesting will find me quite eager. One that expects me to adapt because they are using say SQL Server 6.5 on Windows NT will not find me so eager. If a company is hiring commodity coders to create yet more basic CRUD apps, then the company holds all the cards and can be very picky. If a company is looking for truly good, experienced developers/DBAs/engineers that are capable of working independently and substantial new projects, then the company is no longer looking for a cog in the machine and they are more likely to find a good candidate by remembering that fact and acting accordingly.
flatline 17y ago
"Jobs are like girlfriends (or boyfriends) are like most relationships." Completely one-sided? Because that's what the rest of the post makes it sound like...
- vishaldpatel 17y ago
  In this case, where companies put out job ads, yes! It is usually pretty one-sided, at least, in the beginning.
praptak 17y ago
"interview lots of devs; hire one temporarily and fire them if they're no good.. then hire another etc..." This only works for positions with no ramp up time, i.e. the crappy ones no qualified developer would want anyway.
- lief79 17y ago
  You can tell if someone is coming up to speed within the 60 to 90 days associated with most contract to hire jobs. What you can't tell is if they'll pass that 90 day mark, or if that is actually their peak.
  - Calamitous 17y ago
    True, but 3 or 4 wasted 90-day trials is a man-year's worth of wasted development time (not to mention the damage trail a string of unqualified programmers will leave through your codebase).
    - aaronblohowiak 17y ago
      "not to mention the damage trail a string of unqualified programmers will leave through your codebase" In my experience, code reviews don't take too much time, make code quality more consistent, increase knowledge-share, and lower defect rates.
    - praptak 17y ago
      You also have to take into account the fact that the new team members always drain some time from the existing ones. They will always have some problems requiring assistance from more experienced folks, no amount of docs can prevent that. Mythical man-month and that.
mattm 17y ago
> #4) The last guy who did this job was awesome. He worked hard to help us become who we are now. The fact that he left should tell you something.
- dagw 17y ago
  There are lots of perfectly valid reasons to leave a job you enjoy, that has nothing to with the actual job.

roc 17y ago

> "An employer has money and needs a developer. A developer needs the money. If the employer has foresight, then the developer is at a disadvantage in this early stage of the relationship" Frankly, if you approach hiring with this mindset you're only going to get a good developer through sheer luck. As evidenced from your justifications: you're searching for the cheapest cog.

vishaldpatel 17y ago
If by cheapest you mean, a good cog for a good price, then yes, that is exactly what an employer wants. At the end of the day, everyone likes to feel like a winner. While it would be nice for everyone to be great and welcoming from the outset, it isn't realistic to have that expectation. If we inspect the job ads out there, it is pretty obvious that many employers feel that they can get away with a crappy job ad but still get the cog of their needs with it. So this may not be sheer luck - there are probably more good developers than companies with great job descriptions. But yes, I do agree that a company can increase its chances significantly by tailoring a job description to its intended audience a bit better (but perhaps they already are? ;)).

timwiseman 17y ago

#3) You're not a unique or a beautiful little snowflake. You'll find out how we work when you get here. If you can't adapt, you'll leave - probably against your will. This one is interesting. Now, I would never consider myself a "unique or beautiful little" anything, but I do strive for excellence and I think most good developers/DBAs/any other position that requires any creativity also do that. This does mean that the good ones are not cogs where you can easily substitute one of us for another. I would be reluctant to work for any company that wanted to treat me as a replaceable cog. While I have done it in the past and would do it again in the future if I had to, I think and hope I am long past the point where I would have to work for a company like that again. As for the adaptation, I agree to a degree. Starting any new job involves adaptation. With that said, what kind of adaptation the company expect plays a large role in how interested I would be in the job. A company that expects me to adapt because they are on the bleeding edge of tech, or wants me to work with something that is both new to me and interesting will find me quite eager. One that expects me to adapt because they are using say SQL Server 6.5 on Windows NT will not find me so eager. If a company is hiring commodity coders to create yet more basic CRUD apps, then the company holds all the cards and can be very picky. If a company is looking for truly good, experienced developers/DBAs/engineers that are capable of working independently and substantial new projects, then the company is no longer looking for a cog in the machine and they are more likely to find a good candidate by remembering that fact and acting accordingly.

flatline 17y ago

"Jobs are like girlfriends (or boyfriends) are like most relationships." Completely one-sided? Because that's what the rest of the post makes it sound like...

vishaldpatel 17y ago
In this case, where companies put out job ads, yes! It is usually pretty one-sided, at least, in the beginning.

praptak 17y ago

"interview lots of devs; hire one temporarily and fire them if they're no good.. then hire another etc..." This only works for positions with no ramp up time, i.e. the crappy ones no qualified developer would want anyway.

lief79 17y ago
You can tell if someone is coming up to speed within the 60 to 90 days associated with most contract to hire jobs. What you can't tell is if they'll pass that 90 day mark, or if that is actually their peak.
- Calamitous 17y ago
  True, but 3 or 4 wasted 90-day trials is a man-year's worth of wasted development time (not to mention the damage trail a string of unqualified programmers will leave through your codebase).
  - aaronblohowiak 17y ago
    "not to mention the damage trail a string of unqualified programmers will leave through your codebase" In my experience, code reviews don't take too much time, make code quality more consistent, increase knowledge-share, and lower defect rates.
  - praptak 17y ago
    You also have to take into account the fact that the new team members always drain some time from the existing ones. They will always have some problems requiring assistance from more experienced folks, no amount of docs can prevent that. Mythical man-month and that.

mattm 17y ago

> #4) The last guy who did this job was awesome. He worked hard to help us become who we are now. The fact that he left should tell you something.

dagw 17y ago
There are lots of perfectly valid reasons to leave a job you enjoy, that has nothing to with the actual job.