What I Felt While Reviewing So Many Resumes

This post was translated by Hermes Agent.

Recently, as we started hiring a new teammate, I had a chance to review several resumes.

At first, I thought it would simply be a matter of going through applications one by one. But once I actually started reading them, I realized there were more things to think about than I expected.
I naturally started asking myself what criteria would be fair, what I should prioritize within a limited amount of time, and how I would write my own resume if I were on the other side.

This post is a summary of what I felt during that process.

This is a very subjective post. It is absolutely not the correct answer.
It is only one perspective among many, and every company, team, and reviewer may look at resumes differently depending on their own situation.

So Many Applications

While receiving applications this time, I really felt how many resumes can come in.

To briefly explain the job posting:

• Backend developer with 0 to 5 years of experience
• Work related to image processing and AI domains
• Always-open position

That was the rough shape of the posting.

If you are interested, you can refer to the link below. (It may no longer exist once the hiring process is complete.)
[MIRIDIH] Backend Developer - Image Processing

Because the role targeted relatively junior developers and covered a wide range of experience levels, we received more applications than I expected in a short period of time.
Some were filtered out through basic requirement checks or preliminary screening steps, but there were still quite a few documents that had to be read directly.

Even after that, more applications continued to arrive, and I started reviewing the resumes that were passed to me one by one.

Starting the Resume Review

When I first received the resumes, I thought I should read each one carefully and look at everything.
As a result, each resume took about 20 to 30 minutes.

The things I needed to check included:

• self-introduction
• GitHub link
• blog link
• work experience and projects
• activities
• portfolio

It is hard to estimate exactly how much time each item takes.

“I go into the GitHub project and read the README or code.”
“I look for interesting posts on the blog.”
“I search through the project descriptions and resume content.”

By the time I finished one resume, about four more had been added to the pile. ☠️
Since I also had regular work to do, I started feeling rushed.

The biggest issue was that backend developer resumes are mostly made of text.
As the amount of reading increased, fatigue built up, and I could feel that the care and consistency of my review criteria might start to waver.

Trying to look at too many materials for a single resume also made me feel that the evaluation criteria could become less clear.

Even when a resume or portfolio did not explain something sufficiently, I tried to visit the blog and look for more context.
But this could lead to situations where I read one person's blog post by post, while I could not do the same for someone else's blog because I was already tired.

Criteria for Reviewing Resumes

Based on those problems, I decided that I needed to create clearer and more objective standards for myself.

These criteria are also very subjective, based on my current situation and thoughts.

Focus Mainly on the Resume and Portfolio, Within Limits

I decided not to review every possible piece of content from the applicant, but to focus on the materials that were given.

• self-introduction
• project README
• provided links
• parts that matched between the resume and portfolio

Even if a blog link was included, I only looked at the post list and opened one piece that seemed genuinely interesting.
If I read one person's blog all the way through but could not do the same for another because I was exhausted, that also felt unfair.

So I set the standard of reviewing everyone in the same way: “based on the given materials, within a limited amount of time.”

Aligning with the JD and the Company's Direction

Requirements and preferred qualifications in a job description are not written casually.
They are organized according to the goals and expectations of the team or organization.

They are either written after careful thought by the people who will actually work with the new teammate, or shaped to match the direction of the organization and company.
So I decided to align my evaluation criteria as much as possible with those points.

DFS Rather Than BFS?

Breadth matters, but I think it is also good to have a certain amount of depth.

Even if there are many technologies, projects, or pieces of content listed,
I start wondering whether they really belong to the applicant. Did they truly understand and use those technologies? Did they make decisions based on their own thinking?

With AI, the scope of knowledge we can access and the difficulty of learning things have changed dramatically.
But I still think the knowledge, judgment, and deep understanding that fit oneself and one's team must ultimately come from the person themself.

When technologies like Redis, Kafka, Outbox, Kubernetes, MSA, and Spring Cloud all appear in a single project, I naturally become curious.
The resume becomes more convincing when it also explains “why they were needed,” “what problem they were chosen to solve,” and “how far the applicant personally thought through the decision.”

How I Would Improve a Resume

Polish the Blog

Including a blog link in a resume means you are asking the reviewer to look at it.

But when I actually opened some blogs, I often found things like:

• a blog that had stopped updating a year ago
• posts that were only algorithm code or summaries from books, with no connection to the resume
• posts that simply followed setup tutorials almost exactly
• posts where the writer's own problem awareness and experience were not very visible

In these cases, the blog could actually become a minus.

Personally, I think a good blog post to share in a resume is one that shows:

• what problem you faced or needed to solve
• what alternatives existed, and why you chose a particular approach
• how you solved it (actual code or diagrams are best, if possible!)
• what thoughts and feelings you had while going through it

Those are the kinds of things I would want to see.

Of course, even as I say this, my own blog lately has mostly been about simple knowledge notes or setup posts lol..

On top of that, it would be even better if the blog list itself had a few posts that looked interesting.

Do Not Miss UI and UX

It is difficult to spend a lot of time on a single resume.
If I feel inconvenienced the moment I try to read it, my motivation and interest can drop very quickly.

Things like:

• whether the layout and font are comfortable
• whether links are actually clickable
• whether links are broken because the URL changed, the repository is private, the Notion page is inaccessible, and so on
• whether the GitHub project's README is organized

In addition,
it is helpful to provide a GitHub link next to each project, or a service link next to a running service.

Do Not Force Everything into One Format

This is something I also used to do wrong.
I tried to force every item into formats like Problem - Solution - Result or the STAR method.

But sometimes you need to write about your thoughts or reasoning, and sometimes trying too hard to attach numbers can make the content look weaker instead.
Each experience should be woven into the resume in a way that fits that experience.

A Portfolio Can Complement the Resume

Writing a portfolio is more annoying than it sounds.
Unlike a resume, it does not have a very formal shape, and in many cases it is not required.

But it can add readability and depth to the things you wrote.

1. It is often faster to understand something through diagrams than through text alone.
2. A resume may only allow two lines for a project, but a portfolio gives you more room. (It is flexible, but it should not become too long.)

From the reviewer's perspective, having explanations in a blog or portfolio in addition to the resume can make the content feel more trustworthy.

However, there is a trap in portfolios!!

The most important thing is this: get the resume right first.
If the resume itself does not create interest, it is difficult for the reviewer to continue on to the portfolio.

Once the resume is reasonably polished, then it is worth considering a portfolio.

I really mean this. ⭐
No matter how much content you prepare, if you cannot capture the first 10 seconds of attention, it becomes hard for the next part to be read.

Closing

There are definitely parts of hiring outcomes that I cannot control.
The result can change depending on who reads the resume, what kind of person the team needs at that moment, and what the other applicants are like.

But I do not want to simply say that everything is luck.
What we can do is refine the parts that are under our control as much as possible.

[Woowahan Tech Seminar] Three Tech Leaders Talk About “Developer Principles”

Like Dongwook's topic in that presentation:

Let us try not to depend on things we cannot control.
If resume reviews are mostly done and I end up interviewing some of the applicants who moved forward,
I may come back with another post about what I felt and thought during the interview process.

Good luck to everyone!