Unrealistic programming job posts

I have recently started looking at various job posts. I am looking around to see how programming job posts look like nowadays.

You see I am 46 now. I have been away from full time software writing for at least 10 years. Only to return to it during the past year with Supportress.

Most of the job posts out there are great. They often reflect how good a company is. Sometimes it’s only because of how good the hiring manager is or the one that writes the job post.

Some job posts, though, have unrealistic requirements.


Ways a job post can be unrealistic

  1. Too many technologies.
  2. Unrealistic combinations of technologies required.
  3. Number of years working with X, is greater that the debut of X.

Possible reasons

Why do companies post unrealistic expectations? Here are four possible reasons.

1. Combining roles

Companies like to merge two or even three roles into one. For example a backend programmer, a frontend programmer, and a network expert.

This is often to save costs. They would have to hire three different people otherwise.

It can also be a legitimate case. When a company is small, it makes sense to look for a mix of skills in one person. A full stack developer is a legitimate role.

It is not very easy to find someone that knows all areas well.

There are people that start and end entire careers focusing only on one area. Technology evolves in a rapid way. The constant learning curve makes it difficult to call yourself an expert at times.

2. Filtering out the noise

Sometimes that’s the company’s way to filter out the noise. Developers often exaggerate their experience with certain technologies on their resume. A company may try to filter those out by increasing the need of experience in number of years.

This, of course, may leave out legitimate folks. The requirements may intimidate them and they will never apply.

I love job posts that do not do that. Instead they focus on other skills they can test during the interviews or home tests.

3. Ignorance

Some of the folks writing the job posts, are not experts themselves. They may even copy and tweak similar job posts. They find those on the Internet.

That’s when mistakes like, having 6 years experience with Go (first appeared in 2009) in 2012 happen.

You may want to stay clear of such companies.

4. Accumulated technology stack

This case is particularly interesting to me. It is a real problem. You see, a company that is around for a decade or more, may have accumulated legacy technology over the years.

This is usually the case when people come and go. There’s no-one to maintain some consistency. They may have started with .NET and different stacks creeped in. In the end you have a mix of technologies that is unlikely to exist in one person’s skill set as a complete package.

Yet, it’s difficult for them to break their needs into many roles and they have to merge everything into one role.

I love the idea of the the majestic monolith. It’s much easier, for example, to hire a Rails developer. It’s not as easy to hire someone that knows Rails, Node.js, React and DevOps. Oh and micro-services, HTML, and CSS. Oh they should also be great at SQL, GraphQL, REST APIs, Security, and what have you. And they should be experts in all of that.

What can we programmers do?

What can we programmers do? Here are a couple of ways that can help you decide if you should apply or not:

1. When there’s some hope

Some job posts are good but have a few problems. You may know the company and like its culture. Some of the expectations may still be a bit unrealistic.

When I meet 70% of the requirements I may still apply.

If I do, I am very clear about my strengths and weaknesses in my cover letter. I want to be transparent and sincere. But I still do apply. I am not afraid to do so.

The reason I am sincere is to save them and myself from wasting our time. I help them with their filtering process. If they are looking for someone that matches all requirements, they should not waste time on me.

2. When the job post is clearly bad

I steer clear of companies that fall into the trap and don’t have other signs of a healthy culture otherwise.

Especially when they make mistakes. Like asking for a 12 year experience in Kubernetes. Or a 20 year experience in Java when the role is for a junior developer.

What can companies do?

How can you improve your job posts? Here are three ways.

1. Think about what matters

Before listing a dozen of different technologies… think. What does matter for real? What are 3 requirements and 4 nice-to-haves?

What are some skills outside of the technologies? Are you looking for experience with remote work? Do you want the programmer to be good in written communication?

Be very clear and succinct.

Nobody wants to read an essay.

Keep your paragraphs short.

You see what I did there?

2. Be sincere

You can be sincere about the situation with your technology stack. Yes, you may have mixed technologies. Yet, if you have a core one, name it.

Mention that the rest are nice-to-know. You may have even started normalizing things. You may want to hire someone that can help do that. Rewrite some parts into your core technology if that makes sense.

I know that’s a no-no usually. If you want to save yourself from hiring three people, though, a rewrite may not be such a bad idea.

3. Don’t use number of years

To be honest, that’s a bit difficult to do with programming? How does one communicate “Great at writing Java”? Is it 6 years of experience writing Java? Are you confident that 6 years of writing Java full time makes you a great programmer?

What if you have been a C developer for 10 years, and you have recently started writing Java? Could you be great in Java?

There is a way to approach this. You can establish some kind of a scale with ranges. Then you can mention those ranges instead of plain number of years.

Something like:

  • Expert: 5-10 years of programming, 2-5 years in Java
  • Medium: 3-5 years of programming in any language, 2 years in Java
  • Junior: 1-2 years of programming in any language

(Disclaimer, this is just an example, haven’t really thought about the numbers)

Then list a few other traits such as:

  • You know how clean code looks like
  • You know why verbose code is often better
  • You have great written communication skills
  • You know how to do a good code review


Writing great job posts is not an easy job. Many companies merge two or more roles into one. That creates unrealistic expectations. Developers learn to exaggerate their qualifications and experience. Everyone ends up in a vicious cycle.

Folks can break out of that cycle by reducing the number of must have requirements they list. Developers can apply anyway but be very clear about their strengths and weaknesses.

Developers can help simplify and optimize a company’s technology stack. When they go they leave the company in a better state than how it was when they joined.

What are you up to Petros?

Staying calm. Indie 2D retro style game dev wannabe. Check what I am doing now.

Leave a Reply