Live data from Hacker News

Job Descriptions Should Be Better

blog.professorbeekums.com

11–20 of 67 posts

Re: Job Descriptions Should Be Better

#11
post #6
post #3

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 worki…

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…

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.

Re: Job Descriptions Should Be Better

#12
post #5

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.

Re: Job Descriptions Should Be Better

#13
post #8
post #6

Earlier quoted context omitted.

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…

> 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…

How many people does an engineer making 400k have to manage?

Re: Job Descriptions Should Be Better

#14
post #13
post #8

Earlier quoted context omitted.

> 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…

How many people does an engineer making 400k have to manage?

None? Some companies have individual contributor tracks that end up as positions like "senior architect".

Re: Job Descriptions Should Be Better

#15
post #13
post #8

Earlier quoted context omitted.

> 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…

How many people does an engineer making 400k have to manage?

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.

Re: Job Descriptions Should Be Better

#16
post #13
post #8

Earlier quoted context omitted.

> 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…

How many people does an engineer making 400k have to manage?

The first had a small team (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.

Re: Job Descriptions Should Be Better

#17
post #10

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 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.

Re: Job Descriptions Should Be Better

#18
post #5

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.

Most companies that actually pay a competitive salary should have no issues posting that in their job advertisements.

Re: Job Descriptions Should Be Better

#19

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.

In Germany is even worse, they expect you to tell them how much you want, thus making it yet another selection bullet.

Re: Job Descriptions Should Be Better

#20
My rule of thumb for writing things like job descriptions is that it doesn't mean anything unless someone else might write the opposite.

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.

Post reply on HN