Job Descriptions Should Be Better
blog.professorbeekums.com
blog.professorbeekums.com
So "Software Engineers who want to write great code" is meaningless, as is "committed to building the best products".
But I disagree with some of his other examples:
> solve problems from beginning to end: everything from product conceptualizations to engineering implementations.
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".
> solve the toughest problems fast--the first time
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.
Depends where you work. Our company has two experienced developers and we can both do pretty much the full stack - and we need to. We specialize a bit, I am better at Django, the other guy is better at front end but at the end of the day we need to be able to do both.
Seriously though the term full-stack is pointless as everyone has a different definition of what that means but still wants to say "I am full-stack"
If you want to be that pedantic, do you need to forge the metals you use in your computers since thats part of the stack as well?
If you prefer to be specialized, a warning that it won't happen is a positive feature of the listing, so that both you and the hiring company can save some time.
This also works great for filtering political platforms.
> > 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.
There's a scene (https://www.youtube.com/watch?v=p6xK0Hefsq0) 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.
How do you tell the difference between a company that does value their engineers from one that doesn't if both companies say the same thing? It is not an easy thing to do for sure, but generic uplifting statements don't solve that problem and don't add to job descriptions.
You check if they put their money where their mouth is. Generally, a (well-funded) company that pays its (senior) engineers the same as or more than its executives values engineering. To name two, I've noticed both Google and IBM immediately matching friends' competing offers no questions asked. I know two other engineers whose base, cash salary was over USD 400,000 / year. Cash is very expensive to managers, and enormously expensive to startups (equity less so, but still quite a bit) so it is a reliable signal.
A subtler way might be to check the flavour of engineering projects, and particularly their time horizon. Bringing up Google again, one SDE mentioned using machine learning to automate managing their infrastructure. That's the kind of risky, ambitious, long term project you want to look for.
I personally take mentions of intangible things as negative signals from experience. Something along the lines of if someone is trying to reassure you about something, it means they think it's an issue.
In both cases the work was difficult to do, difficult to share across a team (solve a few hard problems well rather than cycle through hundreds of small JIRA tickets) and highly value adding for the company which is why they were willing to pay.
There are many, many different roles in any large company. You can't please all of the people all of the time. I think the key is recognizing what people the company truly values. In some companies it's the software folks, in others it's sales, and in others it may even be front line support. If you are outside the in group, then it may still be a good company to work for as long as you a) recognize you are but a cog in the machine, and b) can be happy doing your non-glamorous work and going home to your (hopefully happy) life. Just make sure you are a well compensated cog.
Someone who has worked a couple places should be able to infer from that whether they are going to be part of a cost or profit center, and whether that environment is something they want.
I think the post makes some good points. Fluff and buzzword skill lists are useful for entry-level positions, so that a potential candidate who wants to get into a new career and knows little about it has at least some idea of what to look up. But for higher-level positions, the things that candidates want to know about the company and the things that the company wants to know about the candidate, are a bit different, and they both know more about the industry/career path. So fluff and buzzword skill lists are as ineffective in a job description as in a resume.
Taking in account of all three, the salary ranges can be too broad. Yeah, Buffer and StackExchange are doing good but then again, quite a lot of times they have been said to be giving low salaries which also is compensated by the fact that they are super-remote-friendly.
I can't imagine if it'd work for every organisation though.
The tax department here in Norway pays between 80k-130k annually for senior software developers. While earlier this year I got a 55k offer from a private company. I so wanted to show them the job listing from the tax department, but I just said thanks for the interview, but no thanks.
EDIT: Another place to take a look at is REA. http://careers.realestate.com.au/
I found locally there was very little that paid well that wasn't in a C# shop.
Middlemen also change resumes without your permission, remove all your contact info from the resume before sending to employers etc. Overall, it is a real shitty business to be in.
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.
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 (https://de.wikipedia.org/wiki/Betriebsblindheit). 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.
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": https://medium.com/@iwaninzurich/eight-reasons-why-i-moved-t...
The literal translation would be "business-blindness" or "working-blindness", and you're correct that there's not really a good immediate translation that I can think of. It's maybe a kind of sensory familiarity -- the non-perception of things that are familiar. Like how you forget that the loud air conditioner is blowing, because it's been constantly droning for a while.
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.
I'd suggest, even if you think a document writer and tester is way cheaper, you're probably not charging enough for your time. I've always found an inflated rate a very effective way of avoiding tedious work.
That's something I have found too. The more you make the less inclined they are to waste your time.
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.
If you already have a candidate in mind, making the JD fit their CV both repels other qualified local candidates ("it says 4.5 years of Erlang backend experience, I'll get rejected") and makes it easy for you to justify the foreign hire. There's usually someone in HR who used to work for the relevant government ministry who will tell you exactly how to word the job ad and later visa application and appeals.
Note in case not obvious: I'm not advocating doing this.
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.
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.
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.
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.
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 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.
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.
Generally it was positively received, although in large companies there was some deflection with "non-issues", like:
- "oh but you know, our insurance does not cover for you being here" (oh yeah? So I was totally covered during the interview?) - "we'd need to notify security" (hmm, I'm already here) - "you know, everybody is probably too busy" (I'd hope so...) - "not sure where we'll put you" (and when I start in 2 weeks, if that desk hasn't appeared, I also don't show up?)
And even with these casual "non-issues", I actually never was denied this. Usually I stuck for one or 2 hours.
1 company let me stay for a day (they had flown me in for the interview and wanted me to stick around, which says a lot already).
Another one allowed me to attend an entire day of team meeting. After I had received a contract, but still, something like 2 months prior to my starting date. And that actually is what made me accept the offer as I hadn't signed it yet.
If I wasn't still there to tell them, it'd have been total nonsense.