この記事は日本語でもお読みいただけます。
Picture the last time you came across an exceptional resume. It wasn’t just a list of jobs—it told a clear story about how the candidate would fit the role. It was well-crafted, and you could sense the personality behind the words.
From the moment you read it, you felt excited to meet them. On the screening call, you were looking to confirm your positive first impression, not searching for reasons to reject them. It was possible they might have landed an interview with a mediocre resume, but it would have been a harder road. That great resume, on the other hand, set them up for success right from the start.
Just as a resume shapes your first impression of a candidate, your job posting does the same for them.
It’s the first thing from your company that they’ll see. Hundreds or even thousands of candidates will use it to evaluate both the position and your business overall. While a lackluster job posting will still get applications, it is not going to make high-quality candidates excited in the same way a great one will.
Over the years of running TokyoDev, I’ve reviewed over 1000 job postings, and provided companies with feedback on how to improve them. As a developer myself, I know what resonates with my peers. By seeing things from both the hiring team and candidate perspective, I’ve developed a clear sense of what makes a posting work.
Building on this experience, I’ll walk you through my approach to creating job postings developers genuinely want to read.
Principles for making a stellar job posting
When I create or review a job description, I keep three key principles in mind. These guidelines make sure the posting is clear, compelling, and attracting the right candidates.
Focus on attracting, not filtering
The candidates you want the most are the ones who are least likely to apply. They’re selective, and will only contact you if they see a strong fit. On the other hand, less-qualified candidates tend to apply broadly, sometimes sending out dozens of generic applications a day.
No matter how you write your post, some mismatched candidates will apply, so trying to eliminate them in advance is a losing battle. What matters more is drawing in those strong candidates. If your job posting doesn’t do that, you’re left with a weak hiring pool.
Highlight what’s unique about the role
Every software engineer writes code and fixes bugs, so that’s not what makes your position interesting. Instead, talk about what makes your role unique. For example:
- The problems they’ll solve: “You’ll help scale our payments pipeline to handle millions of transactions a day.”
- The technologies they’ll use: “You’ll build APIs in Ruby on Rails and design data pipelines with Kafka.”
- The impacts they’ll have: “The pipelines you build will process emissions data from factories worldwide, giving companies the insight they need to cut their carbon footprint.”
You should also consider candidates who may be browsing multiple roles at your company. If every posting repeats the same boilerplate about the company or benefits, that makes it harder for them to spot what’s actually different about each position. Shared information like that is better put on a separate page you can link to. Each individual posting should focus only on what makes it unique.
Avoid advertising overlapping roles
As companies grow, roles tend to get more specific. A startup might hire for two engineering positions:
- Frontend Engineer
- Backend Engineer
This makes it very straightforward for candidates to identify which roles will fit them.
A larger company might list a hundred or more engineering positions. Drilling into them, though, you’ll soon discover that many overlap. For instance, there might be
- Backend Engineer, Banking (Payments Team)
- Backend Engineer, Credit Cards (Fraud Team)
- Backend Engineer, Integration (Payments and Fraud Team)
- And so on…
From a candidate’s perspective, this can be confusing. Which one should they apply for? Would they be considered for all of these, or just one?
Rather than advertise each similar role separately, it’s much more candidate friendly to group similar roles into a single position, even if you maintain different roles internally. If your company is hiring for 10 different backend engineer positions, each with slightly different responsibilities and requirements, see if you can factor out the commonalities between them into one or two positions. By doing so you’ll attract a wider range of candidates, and it allows you, as the recruiter, to decide which team or level is the right match for each applicant.
Implementing this does put more work on you, initially at least. You’ll need to coordinate with different hiring managers, which may mean changing the hiring process. It’s easier to leave candidates to fend for themselves, but doing so will discourage the best candidates from applying.
If you’re not ready to take on this challenge, then let candidates know upfront whether they should apply to multiple positions, or just one. Clarify if applying once means they’ll also be considered for similar roles. Making a statement on this subject reduces uncertainty and helps the process feel more transparent.
Structuring your job posting
On TokyoDev, we standardize postings into the same structure:
- Job title
- Position overview
- Responsibilities
- Requirements
- Nice to haves
- Compensation
- Hiring process
This list covers the basics most candidates expect. Standardizing the format also offers them a consistent experience, making it easy for them to compare multiple positions.
Job title
A good job title is short, clear, and immediately tells the reader what the role is.
If seniority is important, use established labels like “Senior” or “Lead.” Avoid adding confusing qualifiers like “Lead Candidate”—you can explain that in the description instead.
When a specific skill set already implies a broader one, go with the narrower term. “Android Engineer” is better than “Mobile Engineer (Android).”
If you include a product or team name, it should make sense to someone outside your company. If not, swap it for something clearer. For example, if your internal “Plutus Team” handles payments, call it the “Payments Team” in your job description.
In the sections that follow, we’ll use a backend engineer role to illustrate each step, beginning with the job title:
Position overview
The position overview should describe for candidates the actual problems they’ll tackle, the technologies involved, and the impact their work will have. A concise description that’s a paragraph or two is better than a wall of text.
Avoid marketing speak. Talking about your company’s mission to revolutionize businesses through AI-generated, blockchain-verified TPS reports is the fastest way to make engineers tune out.
Instead, write as if someone in the role is explaining it to their peers. For example:
Responsibilities
The responsibilities section should give candidates a clear picture of what makes this role different from similar ones. It should give them some idea of what tasks they’ll do, without spelling out every single detail.
Keep it to seven points at most—any more, and candidates will be overwhelmed. For example:
Requirements
The requirements section is the trickiest one to get right. Its purpose is to help candidates figure out if they’re likely to be qualified, so that someone with no real chance doesn’t waste their time, or yours. But no matter how carefully you word it, some qualified people will rule themselves out, and some unqualified people will still apply. With that in mind, here are some key considerations.
Keep the list short
If your posting has only two requirements, it’s clear to most potential applicants that they’re absolutely necessary. If it has seven, there’s no telling how candidates may respond. Some candidates will apply if they meet a couple. Others won’t apply unless they meet them all.
Because of this, I recommend keeping requirements to only those skills or experiences candidates absolutely must possess to be hired. If your development team is struggling because they’ve inherited a codebase in Ruby, and you’re trying to bring on an expert to guide them through it, requiring Ruby experience is perfectly reasonable. On the other hand, if your product is in the payments space, and you really want someone with that domain experience, but could imagine hiring someone who was talented without it, then don’t make it a requirement.
Beyond that, avoid listing any requirements that are going to be ubiquitous among candidates. For any experienced software engineer you’re hiring, you probably don’t need to list “Git experience.” Almost every candidate that meets your other requirements is going to have that, and introducing extra noise so that the two percent of candidates who don’t will screen themselves out just isn’t worth it.
Make requirements easy to judge
A good requirement is something a candidate can clearly answer “yes” or “no” to.
“Strong Ruby experience” is a subjective requirement. Your definition of “strong experience” and mine are going to be different, so a candidate’s judgement becomes more about how much self-confidence they have, rather than their actual skill level.
Requiring a certain number of years of experience makes it easier for a candidate to judge their own fitness. However, that option also has downsides. Some of the best hires are people who have talent beyond their years of experience, and by putting down a minimum number, you’ll be screening them out.
Instead, the best requirements give concrete examples of what will be expected of candidates. Instead of just saying “strong Ruby experience,” spell out what you mean:
Skip soft skills unless core to the position
Following on from the previous point, soft skill requirements are often the first ones to cut. Phrases like “strong communication skills,” “highly motivated,” and “works well independently and on teams” are so generic that they don’t add much value. No one is going to rule themselves out because they don’t think they’re highly motivated enough.
That said, sometimes soft skills are genuinely central to the role and worth highlighting. For instance, requiring “leadership experience” for an Engineering Manager is reasonable. But don’t just leave it at a vague label—spell out what that looks like in practice. For example:
Nice to haves
The “Nice to haves” section gives candidates a chance to highlight things that aren’t required, but would make them stand out. For instance, if experience with PostgreSQL could be helpful in the role, but is not vital, you could add it here. Then candidates with that experience can be sure to highlight it, and those who don’t have it won’t be discouraged from applying.
Be aware that some candidates will assume they won’t be qualified for the position unless they meet most of the “Nice to haves.” For this reason, I recommend stating explicitly that nice to haves are optional. On TokyoDev, we add a simple line: “While not specifically required, tell us if you have any of the following.”
Just like the requirements section, avoid listing every possible desirable quality. That makes your job description too long and hard to read. Instead keep it short, concrete, and easy to self-assess. For example:
Compensation
If there’s one thing worse than not including a compensation section, it’s saying that the salary is “competitive” or “based on experience.” That comes across as evasive to candidates, like you know you should be listing something, but are trying to get away with not doing so.
I’ve had many in-demand senior candidates tell me they won’t bother applying to a company without a listed salary range, especially if they’ve never heard of it. They assume the company can’t meet their expectations, or see it as a sign they’re trying to hire as cheaply as possible.
A public salary range signals that your pay is fair, and not based on how well someone can negotiate or what they made before. This matters even more for people who’ve been historically underpaid due to factors like gender. Publishing a range shows you’re serious about diversity, not just paying lip service to it.
Keep the range tight. A spread of 5 to 15 million yen might as well be no range at all. If it’s wide because the role spans multiple seniority levels, break it down explicitly:
Hiring process
Many companies skip over the details of their hiring process, but sharing them upfront helps both candidates and employers. For candidates, it shows how much time they’ll need to commit, what kinds of interviews to expect, and how to prepare, which makes the process feel more transparent and respectful. For companies, it sets expectations early, reduces drop-off, and demonstrates a professional, organized approach that attracts stronger candidates.
List each major step in order, and add a short explanation of what it involves. Where possible, include how long each step usually takes. For example:
General tips
Keep technology references up to date
Mentioning current tools and frameworks shows that your team keeps up with modern practices. Outdated references do the opposite, making candidates wonder if your development culture is stagnant.
This sometimes happens when you include a specific version of a tool and forget to update the posting later. Because software versions move quickly, it’s usually better to leave them out unless they’re critical to the role.
Other times, the outdated reference reflects reality—you really are using older tech. If that’s the case, think carefully about whether it is worth highlighting that fact. For instance, jQuery was everywhere in 2010 but is rarely seen in new projects now. If you’re still using it, be aware that mentioning it may put off some candidates, even if you have good reasons for sticking with it.
Be conscious of bias signals
The way you describe a role or your company culture can unintentionally send signals about who belongs. For example, I’ve seen postings describe a position as being “for otaku,” appealing to people who love games, manga, and anime. That might draw in candidates who share those interests, but it could also discourage others. In TokyoDev’s survey, we found that recent arrivals to Japan were more interested in otaku culture than those who had been here longer. As more recent arrivals tend to be younger, this means while a pitch appealing to otakus might attract juniors, it could limit your chances of hiring seniors.
The same goes for benefits. “Free beer Fridays” might make non-drinkers feel excluded. “Game nights” could make people with family obligations wonder if they’ll fit in. That doesn’t mean you should never mention these things, but you should be aware of how they can narrow your applicant pool.
This matters even more in engineering, where teams are often imbalanced by gender. Small signals in a posting can make a big difference in who applies. Our article “A Four-Stage Approach for Hiring Women on Your Engineering Team” is a good resource if you want practical ideas for making your team and postings more welcoming to women in particular, and people in general.
Describe technologies in context, not as a list
Resumes often have a “Skills” section where candidates list every technology they’ve ever touched. To me, this isn’t especially useful. If someone just lists “Python,” I have no idea if they wrote a single throwaway script or have been building production software with it for years.
The same issue comes up with job postings that include a “tech stack” as a list of 10–20 technologies with no clarification on how they’re used. For example, “Backend: Python, Go, and Node.js.” These are usually used independently, so it’s unlikely all three are equally important. As a candidate, I’d be wondering—will I be spending 10 percent of my time in Node.js, or 90 percent?
That’s not to say you shouldn’t list technologies, just be sure to put them into context for the role. If you’re hiring for a backend position, you don’t need to go into detail about how the frontend is built, but you should be clear about how you use your major backend languages or frameworks.
Use standard headings for sections
Some job posts use headings like, “You’d be a great fit if . . .” or “An ideal candidate will have . . .” followed by items such as “5+ years of Ruby experience.” The intent is to sound friendlier than calling it “Requirements,” but this creates ambiguity. Are these hard requirements that I must meet, or nice-to-have qualities I can fall short on and still be considered for the role?
Instead, use clear, standard headings like “Requirements” and “Nice to haves.” These make it much easier for candidates to understand what’s expected and where there’s flexibility.
Tips for Japanese companies
Avoid direct machine translation
When a job posting written in Japanese is run through machine translation, it often sounds awkward or unnatural to fluent English speakers. This can make applicants question the company’s professionalism or suspect that non-Japanese speakers are an afterthought.
On top of that, Japanese job postings follow different conventions than English ones, so even a polished, word-for-word translation can still feel off. Instead of translating directly, rewrite the posting with your English-speaking audience in mind.
For example, here’s an anonymized excerpt from a real job posting that’s clearly machine translated from Japanese:
Postings like this were the inspiration for this article. To begin, the text itself sounds like it was written for marketing purposes rather than hiring: it is verbose and yet manages to say almost nothing. Including something like this is going to drive away more candidates than it attracts, and so would be better cut altogether.
Beyond that, this text sounds quite awkward to a native English speaker, with a number of issues:
- Phrases like “small to big listed companies” and “mid-term vision” aren’t used in English.
- Enclosing product names like “Adsemble Platform Next Gen Delivery” in quotation marks seems common in Japanese but isn’t something that is done in English job posts.
- ※ (komejirushi, reference mark) is a Japanese-specific symbol and therefore strange to see as an English reader. Similarly, ■,【】, and other symbols common in Japanese, but not in English, are off-putting.
Machine translation can be a starting point, but always have a fluent English speaker review the result. Ideally, that person is also an engineer, so they can make the language both natural and relevant to your target audience.
Make Japanese requirements unambiguous
When a position requires Japanese ability, it’s often listed as “Business Japanese” or “JLPT N2.” This can be broadly interpreted and makes it unclear what degree of Japanese a candidate actually needs.
Instead, the best way to convey the required Japanese ability is to be explicit about what is actually expected. You can refer to our language levels. For example:
Avoid mixing Japanese and English in the same posting
When you’re recruiting for a role that’s targeting both Japanese and English speakers, it can be tempting to create a single job posting on your ATS that includes both Japanese and English text. This is convenient for management, but creates a poor candidate experience.
Making two different postings is best. You’re going to be advertising them on different channels anyway, and two postings allows you to create a short, localized title in each language. But if you absolutely need to combine them, I’d suggest starting the posting with something like “English follows,” and then have the complete Japanese version followed by the complete English version.
The worst cases I’ve seen mix the two languages—for example, including a list of responsibilities in Japanese and then one in English, followed by a list of requirements in Japanese and so on. All that duplication makes the post hard to quickly skim.
Be explicit about residency requirements
International developers from around the world want to work in Japan—that’s why TokyoDev exists. Whether your job posting is in English or Japanese, developers outside Japan will see it and wonder if they can apply.
Clearly state whether candidates who aren’t already living in Japan are eligible. It saves time for everyone involved.
Avoid a “Profile of an ideal candidate” or similar sections
When Japanese companies write English job postings, it’s common to see a section labeled “Profile of an ideal candidate,” in addition to “Requirements” and “Nice to haves.” This comes from translating the usual Japanese heading 求める人物像 (motomeru jinbutsuzou, desired profile). While the intent may be obvious in Japanese, in English the meaning is unclear, and most English-language job postings don’t have an equivalent section.
The problem is often made worse by literal translations of the points themselves, which in English usually end up as vaguely positive traits like “balances technical expertise with an awareness of business impact” or “shows curiosity and a drive to build services that truly help users.” As mentioned earlier, soft skills framed this way don’t help. They don’t make a strong candidate more likely to apply, nor do they convince someone to screen themselves out.
Instead of keeping a separate section, either remove it entirely or fold the relevant points into other sections. When you do, make sure to rewrite them with concrete examples tied to the actual work of the role.
Conclusion
A job posting is frequently a developer’s first impression of your company. When it’s clear, specific, and well-structured, it helps the right candidates see themselves in the role and feel confident applying.
That means:
- Focusing on attracting good applicants rather than filtering out bad ones
- Describing the real work instead of generic tasks
- Being transparent and specific about things like compensation and the hiring process
For Japanese companies, it also means writing directly for English-speaking developers, not just translating from Japanese.
Treat the posting as the beginning of your relationship with future teammates, and you’ll draw in strong candidates who are genuinely excited to work with you.
