Hacker News Reader

I'm hiring right now, and I read a lot of job descriptions before I wrote ours. [1] I've definitely seen what she's talking about: generic go-hire-engineers job descriptions. I also think the kind of thing you describe, hiring for a very specific technology, is a similar failure mode. The technological pain point of the moment rarely lasts; the more stable needs are actually organizational. For example, over the next couple of years I want to be able to hire junior engineers, so right now I'm much less concerned with a particular technology stack than with someone who really likes mentoring and working in closely collaborative environments. That way I can bring the junior people rapidly up to speed.

I also have seen whiteboard coding interviews where interviewers are inclined to ding people for not remembering small details, so it's a legitimate concern.

[1] http://www.codeforamerica.org/jobs/chime/

I've been explicitly told that the code should compile, as I write it (Hi Microsoft!). That's daft, and I told the interviewer that that is not how I think and did it my way.

I would ask for a white-board compiler, then.

If you "need a developer to port the Java code to Go", you need a contractor. Once the Java code is ported to Go, they're done, and there will be no more Java code to port to Go, so... why would you hire a permanent employee on the basis of their ability to port Java code to Go?

The point of a permanent software development teammember is to add to the capabilities of your engineering staff. What is it you want them to add?

What I think she means by 'hiring with intent' is this - identify what you need to add to the team to create the kind of team you need. That could mean someone with more follow-through, or someone who will explore and innovate more. Someone with big-picture systemic thinking skills, or someone detail-oriented who will sweat the little things.

>If you "need a developer to port the Java code to Go", you need a contractor. Once the Java code is ported to Go, they're done, and there will be no more Java code to port to Go, so... why would you hire a permanent employee on the basis of their ability to port Java code to Go?

My examples are being interpreted too literally. They are not tasks that must literally go into the job description. Instead, they are bullet points of internal thinking as to what the additional programmer will do. He/she will convert the Java code; and can also refactor the batch data load, and add 2-factor to customer logins, etc. A laundry list of "things to do" gets built up and it justifies another full-time employee. However, sometimes one item such as "make website scale to 1000x users" can be so large in scope that it will require many FTEs just to work on that one objective.

I've just not seen a situation where a team would hire a new developer and he/she just sit there for days and weeks twiddling their thumbs because the company doesn't know what to do with them. Yes, the new programmer may do nothing because of bureaucracy (IT hasn't created userids yet, repository access not granted, etc). Other than that, the hiring manager usually has a an idea of how the new programmer is supposed to add value.

I think this still smacks of too-situational thinking. Every day my inbox fills with "exciting opportunities" that are nothing but a laundry list of requirements. Am I going to learn nothing on this job? Are you going to invest in me by letting me learn new skills? Are you going to unleash me on new problems, etc? If this is a boring maintainance mode job you don't need the 'best and the brightest' that everyone says they want, and let's be honest; anyone decent can learn that laundry list.

It's rare that I see a req that interests me, because most are extremely situational and based on very specific tasks. Again, I recognize these sorts of jobs will always exist in established companies, and I thank the writer for making that clear, but a list of 8 technologies (who am I kidding, it is usually 15 with 10 more 'nice to haves') from a start up that will probably be pivoting in 3 months anyway? Doesn't make a lot of sense to me. "Come work for us and absolutely stall your career as you grind out tasks that you mastered 3 years ago" is not an appealing sales pitch, and not one that will bring in the talent you need to respond to new challenges.

I'm not saying you meant any of that in your post (you might of, but I'm not sure), your post was just a convenient one to respond to.

>I think this still smacks of too-situational thinking. [...] It's rare that I see a req that interests me,

I understand. There are 2 sides on how to describe the existence of a job: (1) for the executive manager approving of the requisition and (2) for the candidates

In other words, when the hiring manager goes to the vice president asking for another FTE, the exec is going to ask the justification. The hiring manager could say, "well, we can teach him the latest cutting edge functional programming techniques, and also let him build up some AWS architecture skills which will boost his resume and make him more valuable to other companies, and he can play in our foosball ping pong table area, and eat our catered food, and take 4 weeks of vacation." Obviously, the vice president would think those are silly reasons for paying someone. Instead, he needs to know what value-added tasks will justify the job position.

(1) hiring manager perspective: the real work that needs to be done is highlighted, the employee's benefits are implied

(2) candidate perspective: the employee's benefits are highlighted, the "real work that needs to be done" is implied

The thread was about Kerri Miller who was talking about job positions from the company's perspective instead of the employee's and that's what guided my examples.

Behind every job ad that says "change the world and come work for us at our beautiful campus!" from YC, Google, or Apple, etc is a list of tasks that need to get done.

> I don't understand what she's talking about here. Every time I see a job opening, the software hiring manager and the team peers know there's a pain point that needs to be solved. E.g. "We need to an embedded C programmer to make this firmware talk to our USB protocol". "We need a developer to port the Java code to Go." "We need to expose our mainframe transactions as a REST API", etc.

Not necessarily here, but there are also a lot of buzzword soup and horribly vague reqs floating around out there. Just browse Dice or Indeed.

> I'm not sure where her experience with whiteboarding comes from. In my experience, companies use whiteboarding to sketch out algorithmic thinking. Whiteboarding is the opposite of reciting trivia such as the "3rd parameter to an obscure library function" Interviewers don't care about perfect syntax or missing semicolons.

My experience has been that significant numbers of interviewers want working code on the whiteboard, Amazon in particular. If whiteboard interviews were what you describe, I and large numbers of other people would not hate them so much.

It isn't just whiteboard interviews, either. I have had phone screens where my Linux programming skills were judged based on how well I had memorized POSIX manpages. Maybe I have just had bad luck in drawing interviews, but then maybe you have had good luck. I don't know. I can dig up anecdotes from around the web to support both our experiences.

I've been in this situation.

Where I'm being told, "Hire more developers! We need more developers!" I respond with, "I don't need any more on my team right now. We can't handle more with our processes and the head count on our other teams."

That's not important though. To the people I was working with, more developers meant you could do more work, even if we didn't have a plan for what that work would be yet. Incredibly frustrating since more devs could actually contribute to gumming up the works if not brought in appropriately.

You may know this, but for anyone else who doesn't this is called Brookes Law "adding manpower to a late software project makes it later" [https://en.wikipedia.org/wiki/Brooks%E2%80%99_law]. I fell foul of this recently, I bowed to the pressure and hired more resource even though I knew it wouldn't make the difference expected. It was more of a political statement; "I'm listening to what you're saying and see? I'm doing what I can to make the project go faster." They were essentially paying to feel that things were being done to meet the deadline.