This content originally appeared on DEV Community and was authored by Sergey Bolshchikov
Experience plays a tremendous role in any professional career and at the end of the day, every employer is looking for the best, usually the most experienced, people. A common way to measure experience is in years. However, I would argue that such an approach might be misleading.
Here I want to offer an alternative approach to evaluating experience and provide some practical questions that you can use to aid your understanding of what experience truly is.
Part 1. The definition.
Let’s start by looking at the definition. According to Merriam-Webster, the experience can be defined as:
a: direct observation of or participation in events as a basis of knowledge
b: the fact or state of having been affected by or gained knowledge through direct observation or participation
Simply, experience is gained from direct observation and/or participation. Therefore, the more we encounter different types of problems and their solutions, the more our experience grows.
Part 2. Real-life.
But what happens in real life? Most of the actions in our daily jobs are so abstract that we just repeat them over and over again. They are usually simplistic tasks, for example, workers at an assembly line, each one doing one part of an overall product but not able to act on the bigger picture. By dividing work into repetitive tasks, the overall business is efficient, but it may hinder attempts to gain broader experience.
What is true for those on industrial assembly lines is true for many software engineers. We are surrounded by infrastructure, libraries, and frameworks that assist us in carrying out complex tasks. This allows us to produce code quickly, and all we are left to do is technical design and its implementation.
Solving new problems and implementing innovative features can be extremely rewarding and stimulate our intellect. Encountering and dealing with the same time of problems can also create a depth of understanding and expertise. However, there is a threshold, that when crossed, means that repeated tasks become mind-numbing and fail to stimulate our creativity. At these times, we need to switch to new challenges. The problem is that many of us are stuck at that repetitive point and count this as additional experience. So while experience measured in time may be growing, experience measured in intellectual growth may have stalled.
Part 3. The valid alternative.
True experience comes from solving different types of problems in a variety of ways.
For example in a set of two candidates, from one perspective you could say that one who has worked for five years has more experience than the other who has worked for three years. However, if we assessed them more qualitatively, we might find that the candidate who has worked for three years has been exposed in that time to a wider diversity of problems.
This is the reason why software engineers who join startups in the early stages are more likely to gain significantly more familiarity with diverse areas while perhaps compromising on knowledge depth as a result.
Part 4. The practical way
I believe it’s fair to say that every position has a finite set of types of problems that one can encounter. For example, one way, but certainly not the only one, to categorize the problems of software engineering would be in the following way, in order of complexity:
- Investigating and solving a bug
- Implementing a feature within given specifications
- Designing and implementing a feature according to a product specification
- Architecting the solution across different boundaries (e.g. front-end, back-end, devops)
Thus, if we were evaluating experience in terms of diversity of experience rather than simply quantity of time, we might wish to understand the level of complexity a potential employee has been exposed to. This can be achieved by probing candidates more about the nature of their work experience. From my own experience, I have found that the majority of full-stack developers have experience working with the first and second categories above, while the best candidates have experience in three or more of the categories.
I also make sure to ask candidates a more subjective question, asking them to tell me what the most challenging problem they had to face in their career was or the problem-solving process that they are the most proud of. The answers to this question are a good indicator of the edge of a candidate’s experience and in ideal situations, their answers would fall in the third of the fourth category of problem-solving.
Part 5. Conclusion
If you are looking to optimize your professional growth, then seeking out work environments with fast-growth rates can help give you the space to gain a wider diversity of experience. Such places, for example, a startup that grows from hundreds to thousands of users within a short timeframe, is likely to experience many new and complex constraints and problems to solve. Thus, within these environments, you’ll be able to gain not just quantity of experience, but a true depth and range of experience too, which will make you a valuable asset for any company.
This content originally appeared on DEV Community and was authored by Sergey Bolshchikov
Sergey Bolshchikov | Sciencx (2023-05-01T14:14:55+00:00) Why measuring experience in years is not good enough. Retrieved from https://www.scien.cx/2023/05/01/why-measuring-experience-in-years-is-not-good-enough/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.