Around my 5th or 6th year, I started getting involved in developer hiring, and I've been working as an interviewer at my current company for over 5 years now. The interviews were primarily first-round technical interviews. I've also taken the lead in improving the team's hiring process and creating pre-assignments and live coding problems. During this time, I've met various developers and, luckily, hired many good ones.

Throughout the hiring process, I encountered not only great developers but also many who weren't quite there yet, and some who were simply disappointing. The disappointing ones were often putting in effort but didn't know "how much" or "in what direction" they needed to improve, and many were unprepared for the hiring process itself. I often wanted to offer some advice as a senior developer before the interview ended, but it's a delicate matter during hiring, so I've always expressed it indirectly and minimally. I thought organizing and sharing some key points might be helpful someday, and I'm finally writing it down.

The content of this post has no relation to the intentions or policies of my current workplace. It is purely my personal opinion, 정리 based on my experiences participating in hiring.

Although I primarily participated in hiring front-end developers, I believe this will be helpful for developers regardless of their specialty.

Key Competency Areas

While it can vary slightly by company and team, organizations typically look for the following competencies when hiring developers:

What projects have you experienced?
What tools/frameworks have you used?
What development methodologies have you employed?
What was your role and responsibility in the project (developer or lead)?
What contributions did you make to the team or company beyond the project?
How do you solve technical problems encountered during projects?
Leadership, collaboration, and communication skills.

These competencies are verified through processes like resume screening, pre-assignments, coding tests, and interviews, with the depth of verification increasing as the process progresses. For example, a resume is used to check which technologies were used and determine if the candidate fits the required tech stack. Pre-assignments assess practical skills, and technical interviews delve deeper into understanding and experience with specific technologies. Surprisingly, many developers proceed through the hiring process without adequately organizing (or familiarizing themselves with) their own knowledge, experience, and achievements. Their resumes might reveal very little, or even if the resume looks solid, the competencies inferred from it aren't sufficiently verified during the pre-assignment or technical interview.

Think of each competency area above as a stat in a game. However, unlike games, these stats aren't visible, so you need to demonstrate them at each stage of the hiring process. Through writing in your resume, through code in your pre-assignment, and through words in your interview.

Resume

If you keep getting rejected at the document screening stage, check if your resume effectively highlights your competencies. Since resumes generally follow a similar format, create a standard one and update it periodically. Updating your resume regularly provides an opportunity for periodic self-reflection, which helps with motivation and goal setting. Manage your resume this way, and when the "time comes," adapt it to the format of the company you're applying to.

The core of a resume is the list of companies you've worked for and the projects you've undertaken at each. The project list is even more crucial. You need to showcase the competencies mentioned earlier through your project experiences. You might not be able to highlight every competency in each project, usually just one or two. Aim to showcase at least one competency per project. For developers, demonstrating experience with tools, frameworks, and languages is straightforward. If the environment was nearly identical across projects, rack your brain to highlight different competencies in other projects.

It's not about simply listing experiences lengthily, but about including at least one point that showcases a competency. Put yourself in the reviewer's shoes. Which resume would you favor: one that makes you wonder, "So, what exactly did they do?" or one that allows you to grasp, "They have this experience and these achievements, so they must be good at this"? It sounds obvious, but half the applicants fail to write such an obvious resume.

Achievements

What exactly are the "achievements" you should write on your resume? While it's not always easy for developers to quantify achievements with clear numbers, you must know what your achievements are. Surprisingly many don't. Achievements are your contributions to the project. They include what the company gained because you did well, what the team gained, what your colleagues gained, and what you gained yourself. Simply stating "Developed using A technology" only tells the reviewer "They've used A." Don't just list technologies; squeeze out your achievements. Many people fail to write them not because they lack achievements, but because they don't recognize what constitutes an achievement. Sometimes, significant achievements only surface during the interview stage.

Reviewed and decided on an efficient tech stack, disseminating it to the team.
Experience using or developing complex technologies.
Built development environments or structures.
Ported legacy code or replaced it with new code.
Achieved significant (or considerable) performance improvements.
Persuaded and enlightened the team to switch from a familiar but outdated framework to a new one.
Points of pride regarding modules you developed (performance, code conciseness, structure, readability), etc.

Adding such achievements makes for a more compelling resume. This isn't about fabricating achievements but ensuring you don't fail to recognize your own accomplishments. You shouldn't be unaware, nor do you need to be modest. Strive to embed a "story" of achievement rather than just listing technologies. If you lack such stories, you might not be ready to change jobs yet. Try creating some at your current company first.

Pre-assignment, Coding Test

Pre-assignments and coding tests evaluate practical development skills, problem-solving abilities, etc. Both are assessed through code, but live coding tests, conducted face-to-face, usually place more weight on problem-solving skills compared to pre-assignments.

Efficient structure
Responsibility and role of components or modules
Code consistency, readability, maintainability
Naming of variables, functions, classes, etc.
Understanding of anti-patterns
Understanding of performance
Understanding of modern development environments

There might be more criteria than listed above, but listing further seems unnecessary. These are mostly well-known measures of code quality. Knowing them is meaningless if you can't translate them into code. As stock investors often say, "If you're confident, show your account." Words are cheap; show your skills directly. As developers, we show them through code. What we want to see in a pre-assignment is not just a working result. Functionality is a given.

Some candidates try ambitious things they've always wanted to do in the pre-assignment, neglecting what's truly important. Code incorporating novel attempts is good, but if it's buggy, doesn't work correctly, lacks completeness, or is inefficient, it's worse than stably implementing a standard MVC pattern. For junior developers, depending on the content, there might be some bonus points, but it's better to experiment with things you've wanted to try in personal projects. The pre-assignment is meant to check your usual coding practices. If you absolutely must try something new, add only about 20% of experimentation to what you already do well.

Before submitting, clean up your code to some extent. Remove logging code, commented-out unnecessary code, etc. For FE developers: remove node_modules and build artifacts before submission. It might seem trivial, but it's a point where many lose significant points. Submit only package.json, configuration files, and your code. The package.json should indicate how to run the project; if not, that's also an issue.

Interview

This focuses specifically on the technical interview. Interviews delve deeper into the content of your resume through questions.

Scope of involvement and unique aspects of each project
Understanding of technologies listed on the resume
Understanding of the programming languages used
Problem-solving ability
Specific experiences with collaboration and communication
Leadership, influence within the company or organization
Attitude towards work, task processing, and management skills

In the interview, you must be able to answer questions derived from your resume and pre-assignment. If your resume states you used framework A, you need to answer technical questions about framework A. Therefore, it's good practice to prepare answers to anticipated questions beforehand. Explaining concepts and understanding, even for technologies you've used extensively, can be surprisingly difficult without preparation. You should especially be able to explain technologies you are confident in. If you can't explain a technology you handle well, it's no different from not knowing it. It's distressingly common for candidates to fail to verbally explain technologies or concepts they thought they knew well, making it seem like they don't know them. Explaining things you think you know well often proves difficult, so practice explaining thoroughly. You should be able to explain any technology you've experienced, except perhaps monads. If it's monads... the interviewer will likely understand.

Anyway, treat experience and understanding of technology separately. If you can't explain it properly, either don't list it or honestly state that your understanding isn't deep because you only used it lightly. Trying to forcibly explain something you don't know can lead to rambling and derail the entire interview over a single question.

Career

Occasionally during interviews, candidates blame their team (or company) for their lack of growth. Of course, the company situation might genuinely hinder team growth. However, if time passed meaninglessly like that, it's your own fault. If there's a problem with the team, there are three options: adapt, change it, or leave.

Ultimately, if you decide to resign and attempt to switch jobs but keep getting rejected, it means you're still lacking something. You don't yet have the weapons needed for the job change. Before leaving your current company, sharpen at least one blade. A weapon that allows you to showcase your competencies, as explained earlier.

Fundamentally, companies hiring talent want to hire people who demonstrate good roles and capabilities at their current company. No company wants to hire someone who hasn't found their place or demonstrated their abilities at their current job. Before changing jobs, carefully assess whether the problem lies with you or the company, and forge at least a small weapon before leaving.

Organizational immaturity is often cited as a reason for leaving, but if the team culture is poor and colleagues are lacking, I believe it can conversely be a great opportunity to build your career. You could establish a good culture within the team or achieve results worthy of emulation by colleagues, turning it into your weapon. Of course, this isn't easy. But isn't it easier than in a team with an already great culture or among brilliant colleagues who consistently produce good results? Everyone wants to go to a good company, but better companies are often full of highly skilled individuals ("monsters"). While there's the advantage of learning, surviving among these talents isn't easy either.

Tips for Developer Career

People who approach their work with the mindset of building a career, rather than just passively doing assigned tasks, have a different attitude. Here's a work cycle that facilitates career building:

Learn something through work (understanding, realization, solving a problem, adopting something, etc.)
Memo what you learned, big or small.
Write an article based on your memos and share it.
Give a presentation or training based on the written article.
Go to 1

Whether you learn something from work depends on your mindset. Of course, you can't learn every time, but approaching even the same tasks with a career-building attitude allows you to find new challenges within them. Look for anything, however small, that can be improved.

Always take notes, however brief, of things you realize or learn during work. There are moments during routine tasks when fragmented pieces of understanding connect, leading to a "aha!" moment where you grasp a bigger concept or principle, or think of a better way. Never fail to note these down. Such insights will likely be helpful to someone, and if it helps someone, it can become a concrete example of an achievement. Also, note down any problems solved, things learned while adopting technology, or anything you learned that you didn't know before.

Write an article based on your organized memos. Memos serve as excellent writing prompts. They are helpful when you have a topic in mind, but well-organized memos can also be grouped by category to create great writing topics.

Share the written article, and then use it as a basis for a presentation or training. Since the content is already organized and the flow established in writing, you just need to prepare slides and deliver it verbally instead of in writing. Of course, writing and presenting are different skills, but it's much easier than preparing a presentation from scratch. Each step is connected, offering almost a 3-for-1 benefit. Repeating this cycle inevitably leads to building a good career.

Of course, this method might not suit everyone. However, approaching work with the intention of writing or presenting changes your attitude towards the work itself. Based on observations both internally and externally, I've found that people who work following such a cycle are highly likely to grow into recognized, good developers. That's why I always share this with new colleagues, whether they are junior or experienced.

(2022/03/03 Update: Zettelkasten is mentioned as a specific methodology for writing articles based on memos)

Finally

These days, developers are expected to do many things. Good development skills are a given, but experience in training or presenting, blogging, contributing to open source, or participating in communities is also often expected. While having these specs(?) is good, what you experienced and learned through these processes is more important. If you can't properly explain something during an interview that your resume specs suggest you should know thoroughly, it backfires. The resume might be attractive, but you'll ultimately be rejected in the interview.

Hiring requires thorough preparation from both the company and the candidate. If the interviewers' questions are too predictable, like from a cheat sheet, and they seem not to have even read your resume, that company isn't worth joining. Candidates invest significant time resources in the hiring process, just like interviewers, so interviewers must also prepare sufficiently and conduct the process respectfully. If you encounter an interviewer who doesn't, chances are they'd be your superior if you joined, and there's nothing to learn from such a person. How they treat candidates often reflects how they treat subordinates and colleagues.

recruit

Becoming the Developer Everyone Wants