Great job description
I wanted to share what I think (from a candidate perspective) is a great job description. Perhaps there are some recruiters who can talk about how successful they think a description like this would be.:
http://www.texasstartupblog.com/2008/06/11/simpleticket-ruby-on-rails/
(text reposted below)
Positives:
- Specific. It includes the skills desired (and not some impossible laundry list) to succeed, timeframes for the major chunks of the project so you know how you'll be spending your time, and details on salary. Reading this, even though I'm not an RoR developer, I know more or less what the first 6 months are about.
- Tone. It makes big offers--build something great, MOST significant project, internet fame. If you're the company trying to attract talent, you need to offer people something they want. At this level, I as a candidate need to be inspired and excited about my work; if your recruiting tone/actions say that I should be lucky to have a job, I am so firing you as my employer the first chance I get.
- Contact. An actual name! A phone number! I always thought it interesting that the department named Human Resources hid behind jobs@...
Negatives:
- Pretty dry on the culture/personality side. I don't get a sense of what kind of personality they are looking for.
- I probably would have left out the sodas and foosball, but maybe the target candidates are still in to that kind of thing.
I hope they find someone good! Maybe one of those apparently superfluous Austin developers.
Text of description
Ruby on Rails developer needed to run SimpleTicket
June 11, 2008
We are looking for a Ruby on Rails developer to join Big in Japan to lead the SimpleTicket project. We are not looking for someone to come work for us, but someone who wants to build something great. Some of the most talent developers in North Texas have worked on this project and we need the right person to carry the ball across the goal line.
Project History: Original SimpleTicket code written (pre-Rails 1.0) by Big in Japan alumni Kevin Marvin, Alex Leverington, Scott Bauer and a few other contributors whose names escape me.
Step One: Test and Release SimpleTicket 2.0. The original code was completely rewritten by Scott Bauer earlier this year, but was never released. Your first job will be to work with Scott to understand the new SimpleTicket code, test it resolving various bugs and problems that likely exist and release it for use by Architel (our IT services business). This should take around 30 days.
Step Two: Integrate the new SimpleTicket UI created by Jeremy Harrington in the code base written by Scott Bauer. This should take around 60 days.
Step Three: Fork the source code to allow for a public release of the SimpleTicket source code using the GPL (open source license), while keeping our custom version of SimpleTicket operational. This should take around 45 days
Step Four: Create a hosted version of SimpleTicket using a Basecamp or Salesforce SaaS model. You will receive a significant portion of revenues generated in addition to your salary. This should take as long as six months.
The right candidate will be a) skilled with Ruby on Rails, b) love open source, c) be willing to blog about their progress and experience daily, d) be willing to appear at conferences as a panel speaker talking about SimpleTicket. If we are successful, SimpleTicket will be the MOST significant project you have been involved with in your career. You will have access to a full team of engineers, developers and business people to help you on your journey to internet fame.
Salary: $100,000 first year total comp. $50,000 Base + $50,000 in Completion Bonuses ($5,000 for Step One completion, $5,000 for Step Two completion, $5,000 for Step Three completion and $5,000 for Step Four beta release and $30,000 for Step Four final release. Upon final release we will negotiate a new base salary as well as profit sharing.
Benefits: 100% payment of health care benefits (United Healthcare PPO), as many sodas as you can drink, foosball and a 30 inch Apple Cinema Display.
Interested? Give Jennifer Donica a call 214.550.3534 and schedule an appointment to come in.
Of course... the job is in Dallas, not Austin... Cue sound of head banging against desk.
They're looking for heroes, not software engineers.
It's pretty typical with startups and such. It's funny because they're talking about a re-write because they got into this mess by hiring and using hero-coders and now here they're trying to do it again.
Sadly, the stereotype of software developers (cavemen with neckbeards in dark rooms smoking a pack an hour pouring over code on a greenscreen) still persists and people still think that it's the best way to get code done.
Heroes (or what I call 'problem solvers') may get you code quick, but it'll be largely crap code, probably not well testing, horribly architected (if at all), and won't carry you through but maybe one or two more releases before you have to rewrite it... again!
------
This message brought to you by the Department of Problem Prevention
------
blog: http://chadmyers.lostechies.com
I don't quite completely agree with your calling that sort of developer a "problem solver". I personally think they are more correctly called "cowboy coders". The reason that "problem solver" doesn't fit is that they often never actually try to solve any problems. They start a new project, pound out huge mountains of steaming code and then once the going gets tough leave (or are fired once problems start to happen and they can't fix them). Sometimes it is just that this kind of personality doesn't seem to like to deal with the boring details of building systems that are supportable, stable, maintainable, perform under load, etc. They often shortcut things and leave out details like support interfaces, logging, error handling, documentation, etc. Then someone else gets brought in to try to finish and/or rescue the project. That definitely sounds like what is going on in this case. I've been the person brought in to clean up after this sort of person (or persons) many times in the past and over the years I've developed strategies and processes to deal with this sort of situation... Anyway, while an argument can be made (and I really wouldn't argue against) that avoiding problems in the first place is better, there is a legitimate need and place for problem solving skills and I don't think that such skills should be routinely maligned. And there are many types of problems and potential pitfalls in large and complex software systems that are hard to avoid unless you've dealt with them in the past.
I didn't quite have my finger on it, but yes. Why are all these pieces lying around waiting to be finished? Why is 30% of salary wrapped up in a completion bonus which might well be entirely unreachable?
If they were in Austin I would talk to them, but I want a different compensation structure at least.
I can't argue with the compensation structure. I'd also want a bit more in reliable salary, if for no other reason than it would be hard to make ends meet until completion. Of course if their target is the single 20-something hotshot, that is less of an issue than it is for people who've got bills to pay, etc.