Skip to main content

Repost about job descriptions and what they might actually mean in the worst possible cases

I initially posted this as a post on facebook but decided to also add it here.

Warning, it contains bad language. Still, I won't change it because it suits the context really well. I repeat, it contains bad language. Take it as a bit of a joke with some truth to it.

So over the course of the years, I have listened to a lot of actually bad experiences from various developers and reading between the lines I came up with the following conclusions about job descriptions and what they actually mean sometimes. Most of the time the things listed in the descriptions are alright but sometimes there is something really fishy behind the bullet points on a job description. These pretty much point the worst possible meaning behind them in a funny and sarcastic way.

"Dynamic" or "agile" environment = we are disorganized as fuck so we expect you to figure out by yourself what to do, how to do it and what's important to do. Also, you have to constantly adapt yourself to changing requirements and specifications. You need to be prepared to constantly start over again and again and again and again... And again! Or we will force you to use development method that we aren't too sure if it works. Still, we believe blindly in trends more than we believe in thinking about them critically if they are actually good for us in our case.

+5 years experience in some technologies stuff = We lost an important team member because things went wrong and are crap. So we want a new capable developer as soon as possible because we also have a tight or almost impossible deadline that we need to respect. Or we don't give a shit about you and your development as a software developer. We just want people to build stuff, we don't need him to learn new stuff or become better. And we don't support that either. You might decide to leave us for something better if you learn too much. We don't want that!!

Working with new "bleeding edge technologies" = What we make is so simple and lacks any depth that we can afford to rewrite it n-times with various different technologies because we don't have anything better to do. Or we blindly believe in anything new and "cool" that appears around the corner. We don't care if it's been actually tested by the industry in any way. What is new is always betta!!!

"Devoted", "passionate" or "really passionate" about technologies and programming = we need an A-grade asshole to yell and tell everyone what to do because they are too incompetent to make good decisions by themselves. Also, they have to be micromanaged all the time or else everything goes to hell. Also, a bit of paranoia is necessary and highly recommended to keep the masses under control. The more the better!!

Good "problem solver" and "thinker" = we don't really know what we want to do. We need you to figure out what we should do. Or if you figure out how we can actually make money it's even better. Or we have a client that really doesn't know what he wants so we want you to think for him. We pretty much want you to take care of our company with us taking most of the money. Sorry for that!

"Amazing" work environment = we don't really don't have a lot of good things to say about us, so we say these things. We probably have an open office space to be on the current trend but everyone is crammed tightly in there. We actually chose open spaces since they are cheaper. Walls use a lot of extra space and we expect our developers to always be focused even in environments with a lot of noise.

"Good career path" = we hire a lot of junior or incompetent muppets so we give them junk toy projects that don't matter to work on them by themselves. They feel really important like they are their own "bosses". Eventually, we do let work on the real projects once they stop being incompetent and start being just half-incompetent. If they actually make even a couple of semi-decent decisions by themselves we can let them actually design small parts of the application like a dialogue!! If they are actually good then we put them on the real serious projects. Or we don't really invest in you. We will not grind enough so that you might get some free time actually to improve yourself. But if you think we will actually establish a development plan and an actual career path for you, good luck with that!

Able to work in a stressful environment = We don't really need someone that gets stressed easily. Actually, we don't need anyone that gets stressed at all! Honestly, we are looking for someone who doesn't really give a shit about anything and instead is passionate enough to get the job done because it seems "fun" to him lol. Having a screw loose in the head can be a good thing here too! But we also can't write it like this since it will make us look bad and "immoral". So we use this coded description instead. Those who actually get it are the kind of people we are looking for.

Labels:

Comments

Post a Comment

Popular posts from this blog

Some software development common sense ideas

 I haven't really written here in a long time so it's time to write some new things. These are just some random common sense things that seemed to short to write about individually but seem really interesting and useful to me or other people 1. There is nothing fixed in software development, all things vary by circumstances and time Remember the documentation that didn't seem that important when you started the project, well after a couple of years one the application has grown and become really complicated, no one actually knows everything about the application anymore. So now you really need that documentation. What happens if you suddenly need much more people to develop the application because of some explosive growth? Without documentation, new developers will just look at the application like they look at a painting. This actually happened to me. Maybe in the beginning of a project, a technology really helped you a lot but as the project grew, it started making things...
3 comments
Read more

Some things which are often blindly applied and followed by developers which are not always good

This is probably one of the most controversial things that I have written so far but I am just tired of hearing about these things and discussing these things. Other developers that I know share part of my feelings. I would rather hear more about how people built things, overcame challenges or what new interesting ideas and concepts they implemented. Those things are really interesting and innovative, not hearing about the same theoretical things over and over again. I can just read and learn those things from 100 sources on the internet. Firstly, one of the most discussed and promoted things is agile/scrum development. I think I have been through 5-8 workshops about agile development methodology. And each time, some things differed. There is no 100% standard approach to this. Everyone uses their own version of this development methodology and seem to argue a lot that their approach is right and everyone else is doing it wrong. You go to an interview, this will be one of the first 10 t...
1 comment
Read more

Protected variations in software engineering explained and extended beyond the common usages

While digging through some standard programming principles like low coupling and high cohesion I stumbled upon the fact that they are part of a larger series of principles called "GRASP" principles. After reading a bit about them, they seem just as important if not more important than the "SOLID" principles And one particular principle from that series stuck with me: protected variations. According to this principle, variations and changes in parts of the application should be contained only in them and not trigger further changes in the application. In general terms points of inflection should be established between the parts that change and the rest of the application which act like a boundary and stop additional changes from propagating to the rest of the application. For example, one of the most common parts that might change in an application, is the data access and storage methods. For example instead of using direct sql to read and write to a database, an...
1 comment
Read more