Have you ever tried to google "full-stack developer skills"? Or have you ever tried to go through job descriptions posted on Linkedin or identical job platforms? Did you recently complete a full-stack development course or Bootcamp? Did you recently give interviews for a full-stack developer position?

Suppose you have tried either of the above. In that case, you will immediately relate to the problem I am about to discuss. The problem statement is the lack of clarity regarding skills expected from a full-stack developer role. Suppose you were to believe the job descriptions posted by companies on LinkedIn (or other job platforms). In that case, this role requires you to possess N number of skills (where 5 < N< 100 ). I once saw a JD hiring a fresher level full-stack developer and asking for "expertise in NoSql databases" and "Experience in AWS/Azure,". If you google "Full-stack developers skills", you will also find thousands of blogs written by various course platforms (and boot camps) to worsen the situation. These blogs give a custom-tailored version of skills required to become a full-stack developer with a convenient button to purchase (or enroll) at the bottom of the blog. If you haven't gone through it yourself, imagine the plight of a job seeker trying to become a full-stack developer. So, what is the problem here? Why are organizations creating such contrasting job descriptions? Why are companies asking for numerous supposedly unrelated skills to enter this role? Why are the interviewers themselves not clear about the questions they have to ask? Let's dig a bit deeper into this.

The problem

Let me start by apologizing to everyone whose sentiments may get hurt after reading this post further. But, I promise that none of the points mentioned below are conjectures. I have been in the tech industry for 10+ years, interacted with 1000+ people, taught over 5k students online myself, and interacted with 250+ companies (to get my students hired). What I am about to share are observations. People usually try to pin the problem to one person/process/practice/organization. But the real culprit, in my opinion, are the underlying decision-making models. Let's try to get a quick overview of these patterns.

Pattern 1 - Trying to save cost as much as possible.

Many of my students applied for jobs where JDs mentioned the requirement as - "proficient in any server-side language like Java/Javascript/PHP/Go/Rust etc." I usually took such JDs as a good sign. In my mind, they painted the picture of a polyglot engineering team that believes in strong fundamentals. But in reality, the majority of those companies were looking for developers proficient in multiple programming languages, frameworks, and cloud technologies. They wanted people skilled enough to maintain and develop their existing products and have the capability to work on future projects in some other technology. The compensation offered is usually peanuts compared to the skillset expected out of the developer. But in their mind, hiring a full stack developer meant a cost-saving developer. Because now, a single developer will be able to accomplish the job of multiple developers with different skill sets. If I sit down to point out the flaws in this thought process, it will take another blog post of 4000+ words.

Pattern 2 - Lack of clarity in terms of product/feature they want to build and how it's going to evolve/scale

If the first thought in your mind after reading this line is "It only happens in startups," you will be surprised by the number of prominent organizations I have spoken to who face similar problems. The word over-engineering is often attributed to a lousy engineering team/lead. But in my experience, it's a failure of an entire organization (or unit). The inability to define proper product roadmaps, go-to-market plans, etc., leaves room for over-engineering and using a "Y" technology/technique (where Y may not be the most prudent choice logically). The result is - less clarity in skills required for that particular product (or future products) and hence the messed up JD and hiring process.

Pattern 3 - Chasing the expanding technology landscape

Let's look at the stats -

• There are 1000+ JS frameworks in circulation (with new ones coming up every month)
• There are hundreds of programming languages created since the year 2000. (Not counting the old ones before that)
• The number of managed services provided by top cloud platforms such as AWS, GCP, and Azure is in the 100s now.
• The number of SaaS/IaaS/PaaS companies is hundreds in number.

But here is the thing, this is not a new phenomenon. It's not just software engineering. Every field in technology has seen rapid evolutions in the last three decades. And I am sure the same trend will continue in the future. But the problem that arises out of this phenomenon is FOMO (fear of missing out). This pattern emerges whenever a new language, framework, architectural design, cloud service, database technology, etc., is launched. Within weeks, You will find thousands of blog posts, youtube videos, and social media posts comparing it with existing technologies from the lens of a single developer or data from a single context. This content gets consumed by millions of developers worldwide. And somehow, it becomes the input data on which they debate the efficacy of that technology over another. Unfortunately, some of these developers happen to be the engineering leads in organizations. They are preparing the job descriptions of the subsequent "Full-stack developers" they want to hire.

There are numerous other reasons why the JDs are unclear about the requirements, but their occurrence is not enough to justify classifying them as a pattern. I hope the practices mentioned above give you substantial insights into the root of the problem. If you are a developer working in a place that follows the above decision-making mental models, you should immediately start seeing the red flags. After that, the choice is yours!

After reading the post, your mind automatically starts asking: Is there a solution to this problem? The answer is both "Yes" and "No." I will write part two of this post to address the possible solutions to this problem. But, till then, I would love to hear your opinion on this piece.

Shameless plug

If you can relate to the problem I described above, do check out cloudeasy.club. To keep the community spam-free, we have kept it invite-only. If you want the invite code, DM me on LinkedIn or Twitter.