About Software Engineers and Technology Users
After being away from hiring software engineers for 10 years, I came back last year to find the market in chaos. The trend of software "eating the world" seems to have now reached its peak, revealing a basic problem in how we label jobs in the industry.
The Current Situation
If you've ever tried to hire a software engineer, you've likely been flooded with resumes. About 99% of these describe the candidate's skill in Technologies X, Y, and Z, along with how many years they've worked. Candidates often explain how they helped businesses by using Technology X and fixing problems with Technology Y.
While this sounds impressive, most of these claims suggest that the candidates are mainly users of existing technologies rather than their creators. It's as if they're describing how they've mastered tools made by an advanced civilization, rather than building those tools themselves.
Of course, these candidates have some basic understanding of how the technology works. However, when asked deeper questions, many are surprised or even dismissive, arguing that such knowledge isn't needed for their job. This reaction raises an important question: what exactly are we looking for in a "software engineer"?
Most of these candidates have never built basic data structures like hash tables. If they've worked with complex algorithms, it was likely during college or on websites like LeetCode, just to get a job interview.
The Main Problem
There's now a clear difference between two types of jobs in our industry: technology creators and technology users. These roles need very different skills, knowledge, training, and ways of thinking.
The problem—and it's a big one—is that these two different jobs are mixed together under the single title of "software engineer." This mixing is causing many issues, starting with a broken hiring process.
Think about the car industry as an example. There are two different jobs: engineers who design cars and drivers who use them. Both jobs need different skills and knowledge. A car engineer might be a bad driver, while most drivers can't design cars. In software engineering, however, both roles are often called "software engineers."
This situation causes many problems:
- Companies needing software engineers (those who design the technologies) struggle to find them among the many "technology users" applying for jobs.
- To solve this, big tech companies have created tough technical interviews focused on algorithms and system design. While this helps them find engineers, it creates a new problem.
- Companies that actually need "technology users" often copy these practices without understanding why, effectively asking drivers to design car engines as part of their hiring process. As a result, they end up filtering out good drivers (whom they really need) and hiring mediocre engineers (whom they don't need at all).
- Many "technology users" feel they have to study advanced algorithms just to get jobs that don't need this knowledge, leading to frustration and wasted effort.
- Creators often end up in "technology user" roles, leading to disappointment or a move away from engineering.
- "Technology users" who get jobs at big tech companies often find themselves in roles they didn't expect or want.
It's crucial to understand that the vast majority of businesses actually need "technology users" (or "Drivers" in our car analogy), and this is entirely appropriate. Most companies require professionals who can effectively apply existing technologies to solve business problems, rather than those who create new technologies from scratch. This role is not only valuable and necessary but often more demanding in the industry, as it requires a broad understanding of both technology and business needs.
A Possible Solution
To fix these issues, the industry needs to officially recognize and separate these two types of roles. By clearly distinguishing between "technology creators" (those who create new technologies) and "technology implementers" (those who apply existing technologies to solve business problems), we can bring much-needed clarity to the hiring process and career paths in the industry.
Putting this distinction into practice would require changes in job descriptions, interview processes, and even education programs. However, the benefits could be significant:
- More efficient hiring processes tailored to what each role actually needs.
- Clearer career paths for both engineers and technology implementers.
- Better matching between candidates' skills and job requirements.
- Less frustration and more job satisfaction for both groups.
While this separation isn't always clear-cut, and there will always be some overlap between the roles, acknowledging the difference could go a long way toward fixing the current problems in the software job market.