Job Descriptions Should Be Better(blog.professorbeekums.com)
blog.professorbeekums.com
Job Descriptions Should Be Better
http://blog.professorbeekums.com/2016/07/job-descriptions-should-be-better.html
66 comments
> solve problems from beginning to end: everything from product conceptualizations to engineering implementations.
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.
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 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".
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.
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.
Ok, that's half the stack... Who specialises in the lower parts?
You aren't full-stack unless you are writing the Verilog for the chips that run your other code.
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"
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"
The size and contents of the stack might change from application to application, but it has a consistent definition as, "Whatever it is we need to hire developers to do, I can do all of it."
The parent poster's point was, if you're going to credibly say you "can do all of it", you need to list expertise in x86 assembly and VHDL on your resume. Otherwise, you're only a "most stack" developer.
Not at all. Most companies will never need to write assembly, or anything at that level, so its not part of the 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 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?
I would reply on my new machine but I'm still waiting on my drum of oil so I can process it into plastics for the keyboard.
In the context of web development, I've always thought of full stack as: deep knowledge of front end, more than one back end language/framework, database optimization, networking and linux system administration, and a little bit of graphic design sense. If you can ship a professional-looking and scalable app alone, you can call yourself a full stack web developer. If you're working with embedded systems, obviously the definition changes.
That's not consistent at all, since what companies need isn't consistent.
You can be contrarian about it but full stack includes assembly.
Rackspace. Though we are setting up our own dev server locally.
[deleted]
> it doesn't mean anything unless someone else might write the opposite
This also works great for filtering political platforms.
This also works great for filtering political platforms.
Lot of heat in this one with only a little light.
> > 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.
> > 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.
Your statement is very fair. However, even though there are definitely companies that don't value their programmers, I would be surprised if any of them actually said that in a job description.
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.
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.
> 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?
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.
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.
How many people does an engineer making 400k have to manage?
The first had a small team (< 5) of also highly paid senior developers like him to build and maintain a set of systems. I wouldn't call it "manage" so much as "coordinate colleagues". The second was working alone.
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.
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.
Ideally zero as they're on an "individual contributor" track where they're focused on engineering. They may have other people who they mentor but no direct reports.
None? Some companies have individual contributor tracks that end up as positions like "senior architect".
How do you tell the difference? You interview with them and find out what they are willing to offer - the whole package including getting an idea of the human side.
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.
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.
I think it would be more informative to write a listing that characterizes what the team does in relation to the rest of the company. E.g. engineers are responsible for building new products, doing consulting work, executing internal IT projects etc.
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.
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.
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.
That is a pretty basic piece of info that companies like to exclude. They tend to just post "competitive salary" when in fact a lot of the ones that state that pay well below market.
But it is competitive. It's a competition to pay the least amount possible for the best employee possible. Hopefully a competition against other potential employers, not against the employee, but it's really a bit of both since salaries are a negotiated thing.
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.
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.
Most companies that actually pay a competitive salary should have no issues posting that in their job advertisements.
I remember a company I had a contract with sometimes (not always) posted jobs and advertised a pretty high salary. These salaries were actually competitive and not just in line with the competition. You can't imagine how easy it is to find high quality people that way. Go figure...
In Norway, positions from public departments like the tax department usually includes salary range in the job description. They often pay very well too, while at the same time they have a very good description of what expertize they need. In fact most developers here in Norway should read those job descriptions, take notes and be ready fight for better salary for their next job interview.
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.
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.
In Germany is even worse, they expect you to tell them how much you want, thus making it yet another selection bullet.
The hard thing about salary ranges is that there are multiple levels of an engineer, some of which can't always be factually expressed in terms of work experience or any other variable. Although, a great deal of companies claim to hire the best, in most cases, this is not the case. It's always a mixbag of "Ok-hires", "Brilliant-hires" and "Ok-hires-who-turned-to-be-brilliant".
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.
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.
That does seem to be a very critical piece that is missing. Not that engineers say what they are selling themselves for in their applications either...
Why should they, though? When selling non-trivial product or service, and it's pretty safe to assume an engineer's time is not at all trivial, a good rule of thumb is to not reveal your price until the reasons to purchase are well understood and agreed upon.
What's worse in when they post a salary range but then go through the whole "what are your salary expectations" thing. Half the time the posted salary was all that interested me but I can't say that because I can't remember what it was listed as.
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.
Another data point for Australia - I recently applied for a job with a description that included quite a large range of technologies, all of which I happened to know reasonably well. Was contacted back only to find out that not only was it not a single position, but it wasn't even for the one company. The recruiters had just pulled together all of the requirements from multiple jobs and put them all in one ad, which would have been fine if they'd made that obvious. Maybe to save advertising costs? Whatever the reason, it didn't leave a good impression.
That would be funny if it wasn't so awful.
I would like to add that some recruitment companies place ads when there are no jobs as well to increase their candidate pool. It happens a lot when there is a lot of competition to get the best candidate at a moments notice.
Any advice for finding dev jobs in Australia? Moving to Melbourne from London in a few months and I've only been told to look on seek.com.au. Is this where you're having issues with recruiters?
After almost a year searching for a job in Melbourne, I now work remote (in melbourne) for a bay area company.
I found locally there was very little that paid well that wasn't in a C# shop.
I found locally there was very little that paid well that wasn't in a C# shop.
seek.com.au is a good start. If you're looking for a mobile role you could try Outware Mobile http://www.outware.com.au/working-at-outware/. I worked there some years ago (in Edinburgh now).
EDIT: Another place to take a look at is REA. http://careers.realestate.com.au/
EDIT: Another place to take a look at is REA. http://careers.realestate.com.au/
Same case here in the U.S. Not just recruiters, even the job sites are slimy. In addition to what you mentioned, I've noticed this - job sites keep changing the date. So a job that looks like it was posted "today" was likely posted two weeks ago. I'm just waiting to see if one of these days the posted date is in the future!
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.
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.
Somewhat tangentially, do you remember how you described your job in the Australian census? I always really struggle with distilling my job into half a dozen words (but more than a simple job title).
I didn't. I got the paper form, filled in relevant demographic-level information honestly, and simply ignored all the invasive BS.
Hear hear!
Hiring engineers is truly a sourcing problem. Bad ad-copy is part of this problem.
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...
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...
> In German we call this "Betriebsblindheit" and there seems to be no translation to English.
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.
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.
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.
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.
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'm a specialized back-end developer, hire a (way cheaper) document writer and tester for that.
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.
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.
"I've always found an inflated rate a very effective way of avoiding tedious "
That's something I have found too. The more you make the less inclined they are to waste your time.
That's something I have found too. The more you make the less inclined they are to waste your time.
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.
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.
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.
One reason you put filters is to import foreigners. I haven't seen the US side of things but in other locations I've worked, you are required to list jobs on a national jobs database for a couple of weeks first and in theory to prove you couldn't find locals before hiring foreigners. The H1B system looks similar.
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.
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.
Here's a list of job descriptions that some may find handy; check the IT part for example: https://resources.workable.com/job-descriptions
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:
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.)
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 whole point of them is to provide a candidate a description of what a position is like.
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.
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.
I asked a few times to be allowed to lurk around the offices, either directly one the day of the interview, or for a day prior to my starting date (but after having signed a contract, though). Helps to get a feel of the place at least, if not necessarily of your day job (but obviously, looking at your future team's activity is recommended here).
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.
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.
One of my mentors makes it a point to always ask to meet the team he will be working with during the interview, rather than just meeting the hiring manager. I would consider it a huge red flag if your interviewer didn't allow you to meet your potential future team members.
In my very limited experience companies often don't know what they are in need of, and therefore end up writing all sorts of things.
Very true - I actually helped rewrite the JD for my own job after I'd handed in my notice. They were going to repost the one that I went for, but the nature of the role had changed so much it was almost unrecognisable (that being said, £25k for someone to do everything from sysadmin to social media, i.e. about as much full stack as you can do without writing an operating system was utter BS...).
If I wasn't still there to tell them, it'd have been total nonsense.
If I wasn't still there to tell them, it'd have been total nonsense.
It would probably never work but if someone is leaving a role, they're probably the best person to write the job description. I used to say a supervisor instead of HR, but then realized that a lot of supervisors (or equivalent) had a limited view of the day-to-day. HR usually has no clue.
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.
Yikes! I just got a new monitor and realized what everyone else in the world was seeing. That WAS terrible. I hope you find the new color scheme less painful.
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.