My rule of thumb for writing things like job descriptions is that it doesn't mean anything unless someone else might write the opposite.<p>So "Software Engineers who want to write great code" is meaningless, as is "committed to building the best products".<p>But I disagree with some of his other examples:<p>> solve problems from beginning to end: everything from product conceptualizations to engineering implementations.<p>This tends to put me off a bit. Just like "full-stack developer". I agree everyone should be able to do beginning to end when needed, but I much prefer to be able to specialize. And I really don't want to be involved with "product conceptualizations".<p>> solve the toughest problems fast--the first time<p>This is also a bit off-putting. It suggests that they aren't very tolerant of failure. I may just be a bad developer, but I generally assume the first solution we build won't be the correct one.
Lot of heat in this one with only a little light.<p>> > We are an engineering driven organization and we are proud of our engineers. Come join them!
> Thank goodness. Every other company is ashamed of their engineers.<p>There's a scene (<a href="https://www.youtube.com/watch?v=p6xK0Hefsq0" rel="nofollow">https://www.youtube.com/watch?v=p6xK0Hefsq0</a>) in IT crowd where upper management is celebrating the completion of a major project. It's hyperbole, but there's plenty of programmers working in companies and industries where writing software is sort of a bit role in the greater company structure. As a sales pitch, it would resonate with those programmers a bit that software companies have executives who don't ignore software.
The main thing I want from job descriptions is a salary range. The fact that companies don't post salaries is a strong counter-point to how companies complain about how hard it is to hire software engineers.
It's far worse here in Australia. Almost every job ad is written by a slimey salesman in a recruitment company, so:
a) The ads are deliberately vague so you can't go direct to the client
b) A single job / employer will be listed in several vaguely-worded ads from competing rent-seeking-middlemen
c) For the invaluable work of obfuscating the description and wasting everybody's time, these people will take 10-20% of your gross wage.
Hiring engineers is truly a sourcing problem. Bad ad-copy is part of this problem.<p>When I interview companies, I almost always find something that makes them special (young engineers, exceptional tech-stack, real engineering-driven culture etc.). This is what I pitch to potential candidates.<p>Maybe ad-copy of (great) company is often bad, even if engineers write them because authors ca not see the peculiarities of their company compared to other companies. (In German we call this "Betriebsblindheit" and there seems to be no translation to English (<a href="https://de.wikipedia.org/wiki/Betriebsblindheit" rel="nofollow">https://de.wikipedia.org/wiki/Betriebsblindheit</a>). Maybe this is one reason why recruiters / staffing firms still exist. Good recruiters know the companies in their market well, can judge them more or less neutrally and match accordingly.<p>Full disclosure: I am well-connected tech-recruiter in Zurich and if you're thinking of moving here and getting a tech-job, feel free to contact me - you find my email address in my HN profile. Also you can read my blogpost "8 reasons why I moved to Switzerland to work in IT": <a href="https://medium.com/@iwaninzurich/eight-reasons-why-i-moved-to-switzerland-to-work-in-it-c7ac18af4f90" rel="nofollow">https://medium.com/@iwaninzurich/eight-reasons-why-i-moved-t...</a>
I want to know more about what I am going to do on a day-to-day basis. The last job I quit was because I spent about three days a months writing uptime reports and incident descriptions in Microsoft Excel and Word. And about five days per month on manual testing (clicking through the web-interface to see if everything was still in place). I'm a specialized back-end developer, hire a (way cheaper) document writer and tester for that.<p>Had they told me what I was going to do beforehand I would've declined the job and that would have spared them a lot of money on onboarding and orientation.
With a lot of hiring processes I get the impression of filters tuned to the exact match of skill and experience requirements, plus some padding. This is systemically bound to fail because the candidate pool for any one cross section of a growing area is going to be small enough to put you in competition over the qualified candidates. As well, it tunes for a stodgy "best practices" mindset, with no chance of spreading skills diversity through your team.<p>For a field requiring some creativity as well as learned knowledge, enthusiasm and willingness to learn really matters, and the easiest way to induce enthusiasm is actually to go a little off of the mark and present candidates with an opportunity to learn the role based on their existing strengths. That presents some risk, and it's much harder to make it work as you go for "senior" candidates. But case-by-case, there are always ways to offset that risk if you are creative enough - better ways than putting folks who claim to know everything under the microscope in order to fail them as fast as possible, a process which builds a high level of mistrust.
Here's a list of job descriptions that some may find handy; check the IT part for example: <a href="https://resources.workable.com/job-descriptions" rel="nofollow">https://resources.workable.com/job-descriptions</a>
I've been thinking about this a lot recently as we come to hire our third software engineer, in a company which historically hasn't valued their engineers - but with our help has changed a lot in the last year. With myself being the technical team lead going forward, it's important for me that my engineers understand what they will be doing and what value they provide to us, so I've been leaning towards the following:<p>We're looking for a senior software engineer with PHP experience who is interested in learning Golang in the near future. You don't have to enjoy working in Magento, as we're stripping out as much as possible, but a knowledge of Zend Framework 1 or 2 would be a significant benefit.<p>We've worked on some cool problems recently, like converting our monolithic architecture to auto-scaling EC2 instance groups, moving our local development from using a "dev.domain.com" domain to Vagrant (and soon, Docker across the stack) and writing custom security monitoring tools for our various bespoke applications.<p>Outside of the every day work of managing our E-commerce websites, you have fairly unlimited scope for the projects you work on, as long as the team sees value in the idea. You get one day per week to work on whatever you want and to experiment with new languages.<p>We don't currently allow remote working, but we're in talks with the MD to allow us to work from home one day per week, with a view to increase this going forward.<p>Your hours are fixed, you're expected to leave at 5.30, though very occasionally you will get a call out of hours if you're on call (which is a voluntary, paid schedule.)
> The whole point of them is to provide a candidate a description of what a position is like.<p>The trouble is I don't think its possible to know what a position is like until you start it. At least it has been thus with all my jobs so far.<p>Best you can do is tell the candidate what (a) skills are needed, and (b) what the team is doing. I guess a lot of these job descriptions are doing a poor job of (b) by trying to be too bubbly.
At my employer (very large) the hiring managers don't get to see the job descriptions that were written by HR and resumes can only be submitted to some system that limits how many can be submitted by each recruiting agency. So we never get anyone to even interview that matches what we need unless we cheat the system.
Great article but bright purple background was so intolerable I had to switch to safari and use the reader. I actually wanted to share it to someone but decided not to assault their retina.