What Matters More Than Experience

Recently, I posted a senior developer job opening. More applicants came in than expected, and as I conducted interviews, I felt a strange sensation. Resumes listed 10 or 15 years of experience, but as I had conversations, the word "experience" suddenly felt unfamiliar.

Colleague: How's the senior hiring going?
Me: It's harder than I thought. Finding someone within the compensation our company can offer, with experience in the tech stack we want, who resonates with our team culture and vision, who isn't cynical about the company direction, and who has good work habits... I didn't know finding someone who satisfies all of this would be this difficult.

As I was speaking, I realized something. What I was looking for wasn't simply "someone with a lot of experience" described by multiple lines on a resume.

What Are We Really Looking For?

While interviewing, I discovered an interesting pattern. There was no real correlation between the numbers on the experience section and the feeling of "I want to work with this person" during actual conversations.

In fact, I was more drawn to a 3-year candidate who honestly acknowledged what they didn't know, saying "I don't have experience in this area yet, but I'd like to learn." On the other hand, when a 10-year candidate kept talking about only one technology and showed defensive attitudes toward other approaches, it was hard to continue the conversation.

"Ambition, character and brains have little to do with experience."

I'd seen this quote somewhere, and it kept coming to mind during interviews. It's really true. Having worked for 10 years doesn't mean you've developed a good attitude. Experience is an accumulation of time, but attitude and communication ability are entirely different dimensions.

The Small Moments We Face Daily

These thoughts didn't come only from hiring. I face similar questions every day working with team members.

During a one-on-one, a junior team member opened up that work felt overwhelming. They were learning a lot, but often didn't know why their work was needed or how it helped the team. They said not finding meaning was harder than technical difficulties.

My one-on-one style varies between formal format and free-flowing conversation on various topics, so exchanges often happen spontaneously. Organizing my thoughts from then, I realized that for some people, these values are very important and worth sharing. As a tech lead, giving problem-solving methods and proper technical guidance is important. But what might be more important is helping this person find meaning in their work—as a colleague who works with them, before being a tech lead.

That's why I try to make time, not just use spare time, to have many conversations with team members. I do one-on-ones, have coffee while asking how they're doing, listen to what they like and what's hard for them. Everyone has their own strengths, and finding those strengths sometimes creates much bigger changes than technical guidance.

This approach might not match current trends. But since the processes that make most organizations work aren't that cutting-edge, I think you need blurry eyes and appropriate adaptation.

That said, there's also a sad truth. No matter how hard colleagues try, if they can't find that person's strengths, they'll eventually be pushed out of the organization. The leader is the first to notice such moments. That's probably why I care more. And leaders themselves aren't exempt from this case. Leaders must be most aware that they're in a position where they need to check themselves and work harder so they don't run out of value or mission to contribute to the organization.

A Place to Safely Make Mistakes

Recently, a junior team member accidentally brought down the dev server. They reported to me with a pale face, and I asked:

Me: What were you thinking when you ran that command?
Team member: I was trying to improve deployment speed... but I misunderstood an option.
Me: So what do you think you should do next time?
Team member: Test thoroughly in local first, and if I'm uncertain, ask someone.

That team member became the most meticulous person on the team when it comes to deployment processes 3 months later. What if I had interrogated them with "Why on earth did you do that?" They probably would have shrunk back and never tried anything new again.

The feeling of being safe to say anything within an organization—they call this "psychological safety." Organizations that respond to a junior cautiously sharing an opinion with "That's an interesting idea, how specifically would we do it?" versus organizations that start with "That won't work, because..." look completely different 6 months later.

In the former, juniors start actively sharing opinions. In the latter, only silence fills meetings. Ultimately, those small reactions one by one are what create organizational culture, aren't they?

People Before Process

I was confused when the team grew from 5 to 20 people. It became hard for me to talk with every team member directly, and difficult to understand in detail who was doing what.

'The team should run well even without me...'

So I created code review processes, built deployment automation, and organized documentation systems. These were definitely necessary and actually helpful. But about 6 months in, I received unexpected feedback from team members. They said code reviews felt formalistic. It felt like just checking a checklist and getting approval. Before, they used to learn things and have conversations during reviews, but now it just felt like a procedure.

I realized then: processes and systems are just tools. No matter how good a process you create, if the people using it don't feel meaning, it's just a checklist.

So I changed the code review process. Not "seniors check junior code" but "we learn from each other's code." Seniors can learn new approaches from junior code, and juniors grow from senior feedback. More importantly, conversations happen in that process. The "1 emoji per day" campaign also came from that process.

The Question That Keeps Coming Back

The concerns that started with posting a job opening have now become daily questions.

'How can this person grow in our team?'
'How can this person discover and demonstrate their strengths?'
'Is our team psychologically safe for this person?'

When you look at people, what do you consider most important? The numbers on the resume's experience section, or their attitude and potential?

I now know this: a 2-year person with a good attitude can create much bigger change in a team than a 10-year veteran. And recognizing such people and creating an environment where they can safely grow—that's what leaders should do.

Of course, it's not easy. Looking past the numbers on the experience section to see attitude sometimes feels like a risky choice. But teams built from those accumulated choices are definitely different. They become teams that respect each other, view mistakes as learning opportunities, and respect good ideas regardless of experience level.

In your next interview or team member evaluation, why not try this once? Before looking at the experience section, look first at their attitude and communication style. Imagine how much they could grow in a psychologically safe environment.

That small change might completely transform your team and organization. I'm still learning every day too, but of this I'm certain: the eye for seeing people starts not from the numbers on the experience section, but from their attitude and potential.

I hope relationships where we believe in each other's potential grow, one person at a time. Why not look for potential that's not on the resume in someone you meet today?