The idea commonly associated with Socrates, “I know that I know nothing”, is often used as a lesson in humility.
In a professional context, I find it interesting for a different reason.
A strong senior candidate does not believe they know nothing. Quite the opposite. They usually know very well what they can do.
But they can also explain what they have not done, where their experience is still limited and what they would need to develop before taking on the next level of responsibility.
That ability to assess oneself accurately is one of the signals that often separates very strong candidates from people who may look equally senior on paper.
One of the problems I frequently see in interviews is not that a candidate does not know enough.
The bigger problem is when they do not accurately know how much they know.
A complex product does not automatically mean a complex individual scope.
The complexity of a company or product also does not automatically tell us how broad one developer’s responsibility was. In large organisations, the overall system may be extremely complex while an individual engineer owns a very narrow and clearly defined part of it.
On the other hand, a candidate can work on a highly complex product and describe their contribution very precisely:
“I had ownership of my part of the system. I proposed changes, made decisions within that scope and was accountable for the outcome. But I was not independently making decisions that affected the architecture of the whole product.”
That answer often tells me more about seniority than an attempt to make every experience sound bigger than it was.
Because seniority is not only about how much experience someone has.
It is also about how accurately they can locate themselves within that experience.
The Complexity of the Product Is Not the Complexity of Your Role
When candidates describe a project, it is easy to be impressed by the domain.
Supply chain.
Fintech.
Energy.
Telecommunications.
Machine learning.
Critical infrastructure.
But the industry or the complexity of the overall product still tells us very little about what the candidate personally did.
In one system, a developer may have a relatively narrow scope. Requirements are already defined, the architecture is established and the candidate is mainly responsible for implementation within that structure.
Another role with a similar title may require a much broader understanding of cloud infrastructure, data pipelines, databases, integrations, dependencies between systems, production behaviour and architectural decisions.
Those are not the same developmental positions.
And it is not enough for a candidate to say:
“I worked on a very serious product.”
We need to understand what part of that product was actually theirs, how complex that part was and how that level of complexity compares with the product and responsibilities of the role they are now applying for.
A candidate may come from a large and technically demanding product while having a significantly narrower scope than the new role requires.
At the same time, someone from a smaller system may have carried much broader individual responsibility.
There is another dimension that matters: what happens when the system is wrong.
In one product, an output may be used as additional business information and some level of inaccuracy may be acceptable.
In another, an incorrect calculation, unreliable data or system failure may create an immediate financial, operational or technical consequence.
Both products can solve important problems.
But they do not necessarily demand the same level of reliability, precision, technical risk management or developer responsibility.
This is why candidates should not evaluate their experience only by asking:
“How big was the product I worked on?”
The more useful questions are:
How complex was my actual part of it?
Which decisions were genuinely mine?
How much of the wider system did I need to understand?
What were the consequences when something went wrong?
What was already defined for me, and what did I have to design or initiate myself?
Only then do we begin to understand the real level of experience.
The Most Complex Project Is Not Always the Latest One
One of the questions I often use in interviews is:
“What was the most complex project you worked on?”
The way candidates answer is often very revealing.
Some automatically choose their current or most recent project.
It is bigger, newer, uses more technologies and therefore becomes “the most complex”.
But candidates who understand their own development well often answer differently.
They may say:
“Objectively, the system I work on today is more complex. But for me personally, an earlier project was much more difficult because that was the first time I faced that type of problem. Today I work on more complex things, but I already know how to approach them and where to find the information I need.”
That is a very important answer.
The candidate is demonstrating two different forms of understanding at the same time.
They recognise the objective complexity of the current work.
But they can also recognise their own developmental complexity at a particular moment in their career.
Something that once required enormous effort may no longer feel particularly difficult.
Not because the problem became simpler.
Because the candidate became more competent.
That tells us much more about development than simply listing the technologies someone has used over the years.
A senior candidate should increasingly be able to distinguish between:
“This is a complex system.”
and:
“This was complex for me.”
Those two things may overlap.
But they do not have to.
The ability to distinguish between them is one of the clearest signs that a candidate is actually tracking their own professional development.
Strong Candidates Know the Limits of Their Current Scope
Another interesting signal often appears before the interview has even gone very far.
A candidate reads a highly complex job description, sees several areas they have never worked with and quickly says:
“I have not done all of this, but I can learn it easily.”
Maybe they can.
The ability to learn is important.
But then an experienced Architect reads the same or a similar description and says:
“This is a very complex product.”
That difference is interesting.
The Architect is not necessarily less confident.
Often, they are more cautious precisely because they understand how much is hidden behind a few short lines in a job description.
Cloud is not simply another technology to learn.
Data pipelines are not just another library.
Architecture ownership is not simply the freedom to suggest a solution.
Behind those terms are trade-offs, failure scenarios, performance considerations, scaling, maintainability, production issues, dependencies between systems and decisions whose consequences may only become visible much later.
That is why the ease with which a candidate evaluates something they have never done can sometimes tell us more than the fact that they do not yet have that experience.
There is a significant difference between:
“I have not done it, but I am sure I can learn it quickly.”
and:
“I have not owned that area yet. I understand what it involves and I can already see where my gaps would be. I believe I can develop that capability, but I would not say I am fully independent in it today.”
The formal gap may be the same.
But the second candidate gives the company a much clearer picture of the risk.
This is something we often see with genuinely strong senior professionals:
The more they know about an area, the more clearly they can often see its complexity.
The same principle applies to ownership.
“I worked completely independently” does not tell me enough.
Someone can independently implement something that another person has already designed.
I want to understand what happened before the implementation.
Did the candidate notice the problem?
Did they propose the change?
Did they evaluate different options?
Which decisions could they make themselves?
Which decisions required an Architect, Tech Lead or CTO?
What did they remain accountable for afterwards?
Ownership is not simply the absence of supervision.
It includes initiative, judgement and an understanding of the boundaries of your own responsibility.
A well-calibrated candidate does not minimise what they have done.
If they had ownership, they should say so.
If they were the most senior engineer in the team, that is relevant.
If they solved a genuinely difficult problem, there is no reason to make it sound smaller than it was.
But they can still define the boundary accurately.
There is a difference between:
“I was the most senior person in the team, so certain decisions naturally came to me.”
and:
“I was the only person who could solve this. Nobody else in the company knew how.”
The second statement is not impossible.
One person may genuinely hold highly specific knowledge or solve a problem that others could not solve at that moment.
But particularly in an organisation of several hundred people, claims like this require much deeper exploration.
There is a difference between accurately describing an exceptional contribution and exaggerating your individual importance within the system.
A strong senior candidate understands that they worked within a system.
They know what was theirs.
They know what belonged to the team.
They understand where decisions were made.
They understand the position of their team within the organisation.
And increasingly, they understand the business their work supports and how their experience compares with what other companies and teams are solving.
Ambition Needs a Real Starting Point and an Action Plan
I expect senior candidates to be ambitious.
But healthy ambition usually has structure.
“My next goal is to become an Architect.”
“To genuinely take on that role, I still need deeper experience in these areas.”
“This part I already do independently.”
“Here I still need more exposure.”
“This is something I have not done yet.”
“And these are the steps I need to take to get there.”
That candidate is not thinking only about the next title.
They understand the distance between their current developmental point and the next one.
But just as importantly, they understand what action they need to take to close that distance.
Maybe they need more architecture exposure.
Maybe they need to take responsibility for decisions across several services rather than one.
Maybe they need to become more involved in business discussions.
Maybe they need to lead a technical initiative from problem definition through implementation and production.
Maybe they need an environment with stronger Architects or senior peers from whom they can learn.
A realistic career goal therefore has three parts:
Where am I now?
Where do I want to go?
What specifically do I need to do to get there?
That clarity is important for the company as well.
A company does not necessarily need to hire someone who already knows everything required for the role.
Very often, a client will be willing to give a strong candidate an opportunity even when part of the required experience is missing, if the gap is clear and realistically developable.
The company can say:
“They have not owned this area yet, but our CTO can support them.”
“They need more experience here, but the foundation is strong.”
“They should not take this responsibility completely independently from day one, but there is a realistic path towards it.”
That is a development plan.
It becomes much more difficult when a candidate believes they already operate at a level that the interview does not confirm.
Then the problem is no longer only the missing knowledge.
The problem is that the candidate does not recognise the gap.
And that is why a client may sometimes be more comfortable taking a chance on someone who says:
“I do not know this well enough yet.”
than on someone who describes every new responsibility as something they will “easily learn”.
The first candidate gives us a visible starting point.
From there, both the candidate and the company can decide whether the next step is realistic.
This brings us back to the idea:
“I know that I know nothing.”
Professional maturity is not about underestimating what you know.
A strong senior professional should understand their value very clearly.
But they should understand the limits of their current knowledge just as clearly.
Seniority is not knowing everything.
It is knowing what you genuinely know, what you have not yet done, what you can already own independently, where you still need support and what actions you need to take to become ready for the next level of responsibility.
Knowing the limits of your knowledge is not the opposite of seniority.
Very often, it is one of its clearest signals.
Key Takeaways
• The complexity of a company or product does not automatically describe the complexity of an individual candidate’s scope.
• Strong candidates can separate the objective complexity of a project from what was personally difficult for them at a particular stage of their development.
• A candidate who accurately identifies the limits of their experience can often be easier to develop than someone who does not recognise their own gaps.
• Ownership is not the same as independent execution. It includes initiative, judgement, decision-making and accountability within a clearly understood scope.
• Healthy career ambition includes not only knowing the next desired role, but understanding the concrete experience and actions required to become ready for it.
Frequently Asked Questions
What does self-assessment mean for a senior candidate?
Candidate self-assessment is the ability to evaluate accurately what someone can already do independently, where their experience is limited and what they still need to develop before taking on greater responsibility. It is not false modesty or lack of confidence.
Why is self-assessment important in senior tech hiring?
Senior roles often include autonomy, judgement and responsibility beyond pure implementation. A company needs to understand not only what a candidate has done, but whether the candidate understands the boundaries of their own experience and can realistically judge what they are ready to own next.
Does working on a complex product make someone a senior engineer?
Not automatically. A highly complex product can contain very narrow individual roles. The more relevant questions are what the candidate personally owned, which decisions they made, how much of the wider system they needed to understand and what consequences their work carried.
Is it a weakness for a senior candidate to admit they have not done something?
No. In many cases, a precise explanation of what the candidate has not yet done, together with an understanding of the gap and a realistic development path, can be a stronger seniority signal than claiming confidence in an area without sufficient experience.
How can interviewers assess whether a candidate understands their own level?
Ask about the candidate’s most complex project, the boundaries of their decision-making, situations where they initiated change, areas where they needed support and what they believe they still need to learn for their next career step. The goal is to compare the candidate’s self-assessment with the evidence in their actual experience.
If you are hiring for a senior technical role, assessing what a candidate knows is only part of the decision.
Understanding whether they know the limits of that experience can be equally important.
At FindIT, we look beyond titles and technology lists to understand the actual scope, decision-making responsibility, development level and role fit behind a candidate’s experience.