"How many years of experience with this technology?"
I know which projects I worked on, which problems I solved and what I was responsible for. Yet when it comes to giving a number, I hesitate.
Should I count from when I first used it, include only certain assignments, or leave out the gaps?
My answer depends on a rule the question doesn't state.
When did I start, and how much time did I spend on it?
I started with PHP in 1999. That doesn't mean twenty-seven years of exclusive practice.
My work included projects on a LAMP stack: Linux, Apache, MySQL and PHP. Development, database work and deployment all contributed to the same outcome. One year on that stack is neither a full-time year on each component, nor four equal shares.
I can explain my projects and my responsibilities. Reconstructing my PHP hours after the fact would only be an estimate.
The problem applies to frameworks too: using Symfony or Spring Boot occasionally for three years doesn't describe the same activity as using it daily.
Counting from first use gives a different answer from counting only certain assignments. Without a clear rule, a cautious candidate may report fewer years than someone with similar experience.
What do employers look for when they ask for years of experience?
Before deciding how to count, we need to understand what the number is supposed to indicate. I see three possible reasons, which I'd want to check with recruiters:
- Ability to work independently: handling certain tasks with the level of guidance the role allows.
- Situations already faced: maintenance, migrations, incidents or supporting a system after release.
- A screening criterion: reducing the number of applications or meeting a client's requirement.
These expectations can overlap. Duration still matters: maintaining a system over time lets you see the consequences of your decisions. But it doesn't automatically describe what you can take on.
To clarify what is expected of the candidate, one question seems useful:
When you ask for three years of experience, which skills are you actually looking for?
AI makes the scope even more important
This question applies to AI as well, a field that covers very different activities.
A SQLI job posting for a Generative AI Data Scientist (in French), viewed on 6 November 2026, asks for at least three years of experience in generative AI. It is one example, not a picture of the whole market.
Yet using an assistant, integrating a model into an application and training one require different skills. Grouping them under "three years of AI" doesn't make them equivalent.
In AI-assisted development, getting code back doesn't show that you can evaluate it. GitHub points out that Copilot suggestions must be reviewed and validated by the user.
So duration only makes sense once the activity has been defined.
Showing what you've done without tracking every hour
I can say when I used the technology, describe the tasks I handled and point to a specific project. Design and troubleshooting count too, when they genuinely draw on the technology in question.
Activity-tracking tools such as WakaTime provide complementary evidence. As the WakaTime documentation explains, the totals depend on the activity recorded and the settings used to account for idle time.
These logs capture only part of the work. They offer limited evidence of proficiency.
Even without a tracking tool, deliverables, a record of contributions or letters confirming past assignments can support your account of the work.
Changing technology doesn't reset your experience
This evidence doesn't yet tell us how to account for skills acquired elsewhere.
I started working seriously with Spring Boot at the end of 2024. I fall short if a role requires three years with this Java framework.
Yet my experience in design, databases and troubleshooting can support my learning. It doesn't prove expertise in Spring Boot: both my knowledge of the framework and the skills I bring from other work matter.
This distinction also applies to seniority. I would describe each level in terms of the work someone can handle:
- Junior: needs regular guidance within this scope.
- Mid-level: handles common situations autonomously and knows when to ask for help.
- Senior: also takes on complex situations, justifies trade-offs and helps others grow.
These descriptions are meant as general guidance.
The professional skills framework SFIA also distinguishes autonomy, influence, complexity and knowledge to indicate a level of responsibility. The benchmarks proposed here don't map directly to its levels, however.
Assessing the skills a role needs
How do we assess this autonomy in an interview? Asking "Are you comfortable with this technology?" remains subjective. A technical test brings other evidence, provided it covers what the role requires.
A question about a specific technical detail can be relevant for a specialist role. It tells us less about the ability to deliver a solution if the detail being tested plays no part in the expected work.
For a generalist like me, the risk is being assessed as a specialist in every technology I combine to deliver a solution.
I do understand that a company wants to reduce hiring risk. When I worked at a professional federation, I had to identify people who could help me work with a particular technology.
I asked fairly broad questions and relied largely on my judgement to assess how well they knew the technology. I was also looking for foundations to build on and a willingness to learn.
This flexible approach led to successful collaborations. It doesn't make my intuition infallible: motivation doesn't replace every necessary skill, especially when someone needs to work independently from day one.
Involving several people can bring complementary perspectives. They still need to agree on what each one is assessing. Knowing a tool in depth doesn't, on its own, guarantee that the criteria are relevant.
I'd start by discussing a project the candidate worked on:
- What problem were they trying to solve?
- What was the candidate's role?
- What choices did they make?
- How did they verify the result?
Technical questions can then shed light on their decisions and limits, at a depth suited to the role.
Checking the right things
My difficulty putting a number on my experience leads to a hiring question. Which skills do we actually want to assess?
Years and tests provide clues. We still need to define what the person will do and how independently they'll need to work.
On the candidate's side, I can say when I started using the technology, what I used it for and what I delivered. I can explain what I know about the technology, which skills I bring from other work and what I still need to learn.
If a form requires a number, I give an estimate I can explain and, where possible, I add its context.
On the hiring side, which skills are essential from day one, which can be learned and which would complement the team? Is a gap in a particular framework feature really a deal-breaker for the assignment?
A generalist should be able to show their contribution without being assumed to be a specialist in every component. A specialist should be able to demonstrate the depth expected. Limits deserve to be stated as clearly as strengths.
The aim is to assess the skills the role actually calls for.
When an application is turned down, those criteria should also be made explicit. Without concrete feedback, how can I know whether my skills, my experience or some other constraint weighed on the decision?