Learn to write clear, inclusive, and accurate software engineering job descriptions.
0 / 10 completed
1 / 10
What is the difference between 'required' and 'preferred' qualifications in a JD?
Required qualifications are essential for performing the job. Preferred are nice-to-haves. This distinction matters: research shows women and underrepresented groups are less likely to apply if they don't meet all 'required' criteria — so keep required lists short and accurate.
2 / 10
What is 'gender-coded language' in job description vocabulary?
Gender-coded language uses words that studies show subtly deter certain groups from applying. Tools like Textio and Gender Decoder identify and suggest alternatives. Neutral language ('drive results', 'work collaboratively') broadens the applicant pool.
3 / 10
What is 'ninja/rockstar/guru' language in job descriptions?
'We need a rockstar engineer' or '10x ninja coder' are exclusionary — they signal a 'bro culture', are unclear about actual job expectations, and deter experienced engineers who prefer professional language.
4 / 10
What does '10 years of experience required' as a criterion mean — and what is the risk?
Arbitrary years-of-experience requirements may exclude career changers, bootcamp graduates, and candidates from underrepresented groups without assessing actual competency. Skills-based or competency-based criteria are more accurate and inclusive.
5 / 10
What is 'compensation range disclosure' in a job description?
Salary range disclosure in job postings is legally required in California, New York, Colorado, Washington, and elsewhere. It also improves candidate trust, reduces wasted interview time, and helps close gender pay gaps.
6 / 10
Sarah from the QA team just posted this Slack message: 'Need urgent help with the API endpoint /users/create. Seriously, someone needs to fix this ASAP!' What's the most appropriate response considering professional communication standards?
The original message uses strong language ('Seriously, someone needs to fix this ASAP!') which can come across as demanding and unprofessional. The best response acknowledges the urgency but requests more information for effective troubleshooting. Options A and B demonstrate a proactive and collaborative approach, while options C and D are passive and don't address the core issue.
7 / 10
You're drafting a pull request description for a code change that refactors a legacy module. The current description reads: 'This code is super efficient and will make everything faster! You need to be a ninja developer to understand it.' What's the primary issue with this phrasing?
The phrase 'ninja' is a common example of 'rockstar' language used in job descriptions and can be perceived as exclusionary and arrogant. It doesn't offer any substantive information about the change itself and could alienate developers who aren't familiar with the term. Clear, objective descriptions are always preferable for PRs to facilitate review and understanding.
8 / 10
During a standup meeting, David says: 'I'm tackling the new authentication flow. I've got it to a point where I can log in, but I'm still working on the password reset functionality.' What does this statement *primarily* communicate about David's progress?
David's statement clearly outlines his current focus – logging in – and acknowledges ongoing work on the password reset functionality. This provides a concise update on his progress without over-promising or requesting help unnecessarily. The other options present an incomplete or inaccurate picture of David's status.
9 / 10
You are reviewing a code change submitted by Maria and see the following comment in the commit message: 'Fixed bug in the data validation logic.' What is the most valuable addition Maria could make to this comment to improve its clarity for other developers?
While 'This fix ensures data integrity' is a valid outcome, it doesn't explain *how* the bug was fixed. Providing specific technical details (using regular expressions) helps reviewers understand the logic and assess the solution effectively. Including issue #1234 provides context for tracking the problem.
10 / 10
A job description states: 'We are seeking a Senior DevOps Engineer with 8+ years of experience in cloud infrastructure and automation.' What is the *potential* drawback of using this phrasing?
Specifying an exact number of years can inadvertently limit the pool of qualified candidates. While experience is important, it doesn't always correlate directly with skill level or ability. A more inclusive phrasing would focus on demonstrable skills and relevant technologies rather than a rigid numerical requirement.
What does this Technical Interviewing exercise cover?
This exercise, "Job Description Writing — Vocabulary and Language", tests your understanding of technical interviewing vocabulary and phrasing through 10 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Technical Interviewing exercise for?
It's designed for IT professionals and learners who want to sound natural discussing technical interviewing topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Technical Interviewing exercises?
Browse the full Technical Interviewing exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.