Module 1: The Market Reality and Your Target Role

8. Project: Your Target Role Brief

Description

You've reached the end of the module with seven loose pieces: you know English is a filter, not a decoration; you know how to read a job posting without translating word by word; you know what a "B2" on a listing actually means; you did your self-assessment; you placed your role on a seniority-and-salary map; and you understood where that role actually exists for someone working from Latin America or Spain. Each piece, on its own, is interesting. Together, though, they're useless until you condense them into a single document you can reread every week and measure every decision against. That document is the target role brief, and building it is this module's project.

A target role brief is one page. Not two. Not a journal of reflections. One page a stranger could read in ninety seconds and, at the end, be able to say out loud: "this person is aiming for this role, in this market, and is a credible candidate because of this and this, even though they're missing that." If a stranger can't say that sentence after reading your brief, the brief isn't ready yet. That's the acceptance criterion, and it's demanding on purpose: the job market is exactly that stranger, reading you fast and deciding in seconds.

Connection to the module: this project is the destination the previous seven lessons were aiming at. It turns the market analysis, the job-posting anatomy, the role map, and the self-assessment into an operating artifact that governs the rest of the guide. Without a brief, there's no resume to tailor in the writing module, no vocabulary to prioritize, no interview to simulate in the oral module. And here we also close something the module has been building toward: your cadenced practice plan and the gate that separates reading-and-writing work from oral work. The brief isn't a pretty summary of what you learned; it's the board you're going to play the next few months from.

What a target role brief is, and what it isn't

Before building it, let's define precisely what we're doing, because the word "brief" can be confusing.

A target role brief is a one-page document that fixes, with evidence and no illusions, the exact role you're training for, which market it exists in for you, how much it pays, and what separates you from getting it today. Think of it as the README of your own job search: just as a good README tells a stranger what a project does and how to run it, your brief tells a stranger what candidate you are, for what role, and which "dependencies" you still need to install.

What it's not:

It's not a resume. A recruiter reads your resume to decide whether to call you. You read your brief to decide what resume to write. One looks outward; the other, inward.
It's not a cover letter. There are no paragraphs about your passion for technology. There's data: role name, salary band, time zones, English gap by skill.
It's not a journal. It doesn't document how you feel. It documents what you're aiming for and what's missing, in a format you update in five minutes every week.
It's not permanent. It's a living document: you review it every two or three weeks and correct it as the market or your level changes. A brief frozen six months ago lies to you.

What to expect: your first version is going to come out too ambitious or too timid. That's normal, and it's actually the point. The brief exists precisely so you see that distortion in writing and adjust it against real data, instead of carrying it in your head as a vague anxiety.

Anatomy of the brief: the seven fields

The brief has seven fields. Not one more. The discipline of fitting it on one page is part of the exercise: if it doesn't fit, you haven't decided yet.

#	Field	Question it answers	Which lesson it came from
1	Target role	What am I applying for, with its exact name in English?	3, 6
2	Claimable seniority	What level can I defend with evidence today?	6
3	Market, geography, and time zones	Where does that role exist for me?	7
4	Salary band	How much does it pay, in an honest range?	6
5	Three reference postings	What does the real role look like, decoded?	3, 4
6	English gap by skill	What separates me, skill by skill?	4, 5
7	Cadenced practice plan	What do I do every week, and what's my gate?	5

Let's go field by field. For each one I'll give you what to write, a real example, and the typical mistake to avoid.

Field 1: the role, with its name in English

Write the role title the way it appears in real postings, in English. This isn't a language quirk: the English name is the keyword you're going to search, filter, and present yourself with. If in your head the role is called "programador backend," but the market calls it something else, you're searching in the wrong language.

Examples of titles the way the market writes them:

Backend Engineer (Python) Data Engineer QA Automation Engineer Site Reliability Engineer (SRE) Full-Stack Developer (React / Node.js)

Notice the nuance: technical English uses Engineer a lot where Spanish says "programador" or "desarrollador." It's not inflating the title; it's the market's convention. Backend Engineer and Backend Developer coexist, but a lot of companies use Engineer as their standard. Use whichever term turns up the most postings in your search.

Below the title, write a single positioning sentence in English. It's the sentence you'd say if someone at an event asked you "So, what do you do?" A template that works:

I'm a [seniority] [role] who builds [what] with [main stack], focused on [domain or strength].

Filled in as an example:

I'm a mid-level Backend Engineer who builds REST APIs with Python and FastAPI, focused on data-heavy services.

Why this sentence matters: it doesn't describe everything you know; it describes one sharp profile. A sharp profile is hireable; a profile that "does a bit of everything" forces the reader to guess, and whoever has to guess, passes.

Typical mistake: listing two or three roles ("backend, or data, or DevOps, whatever comes up"). That's not a target role brief; it's the absence of a target. Pick one. If you're genuinely torn between two, make two briefs and compare them — but each brief points at a single role.

Field 2: seniority you can claim with evidence

Here you don't write the level you want, but the one you can defend. That difference is the whole point of the brief.

A seniority level is "claimable" when you have concrete evidence backing it up: projects, responsibilities, years, technical decisions you made. The rule is simple: for every level you claim, write the evidence on the same line. No evidence, no claim.

Claim	Evidence backing it	Claimable?
Junior Backend Engineer	1 year in production, 3 APIs maintained, own tests	Yes
Mid-level Backend Engineer	Designed a service's data schema from scratch, mentored a junior	Yes, with nuance
Senior Backend Engineer	"I've been coding for 5 years" (but always executing already-defined tasks)	Not yet

Notice the third case: five years isn't automatically senior. Seniority in technical English is tied to autonomy and decision scope, not tenure. A senior makes design decisions, disambiguates vague requirements, and answers for the outcome. If your five years were spent executing pre-chewed tasks, your honest claimable level might be mid-level, and that's perfectly fine: it's easier to grow from an honest claim than to defend an inflated one in an interview.

Model sentence for writing your claim in the brief, in English, because that's how you'll say it in the interview:

I can credibly claim mid-level: I've owned features end to end, but I haven't yet led the design of a whole system.

The "but I haven't yet" doesn't weaken you. It makes you credible. A candidate who names their own ceiling calmly projects more seniority than one who hides it.

Typical mistake (and why impostor syndrome makes it worse): two opposite errors live here. The inflater claims senior with no evidence. The impostor claims junior while having mid evidence. If your tendency is the second one — and it usually is for people studying technical English — correct upward with the same discipline: if you have the evidence in the column next to it, you have the right to the claim. That's not arrogance; it's reading your own table.

Field 3: market, geography, and time zones

This field comes straight out of the previous lesson. Here it's not enough to say "remote work." As you saw, a lot of "remote" postings aren't remote for you: they're limited to one country, to a band of time zones, or to a hiring arrangement that doesn't apply from where you are.

Write three concrete things:

Markets where that role exists for you. For example: US (remote, LATAM-friendly), EU (Spain-based), LATAM regional. Don't list the entire world; list where you can actually be hired.
Your overlap window. For example, if you're in GMT-6 and targeting the US: Overlap with US Eastern: ~5 hours/day. This is a data point a recruiter values, so have it clear yourself first.
The realistic hiring arrangement. Contractor, EOR, local payroll, staffing. Mark whichever applies to your case, because it changes your net pay and benefits.

Model sentence in English for your brief and, later, for your profile:

Based in Mexico (GMT-6). Available for US and EU remote roles as a contractor, with ~5 hours of daily overlap with US Eastern time.

What to expect: this field usually shrinks your universe of postings, and that's scary. But a smaller, real universe is worth more than a huge, imaginary one. Ten postings you can genuinely apply to beat a thousand that are going to reject you on geography before ever reading your code.

Field 4: expected salary band

Write a range, not a number. An honest range has three marks:

Floor: the minimum you'd accept the role for without resenting it.
Target: what someone with your profile would ask for in that market, based on what you saw in the roles-and-salary lesson.
Realistic ceiling: the top of the band for your claimable seniority — not a senior salary if you're claiming mid.

Anchor the range to data from your target market, not your local one. If you're targeting US postings from Latin America, your reference is the adjusted US band for contractors, not your city's local salary. Mixing up the two bands is one of the most expensive mistakes from the market lesson.

And a useful bit of English for negotiation: in postings you'll see phrases like competitive salary or DOE (depending on experience). Knowing what they mean keeps a DOE from intimidating you: it just means "the number depends on your profile, negotiable."

Typical mistake: leaving the field blank "because I don't know what to ask for." Not knowing is exactly the reason to write a tentative range now and correct it once you have more data. A tentative range on paper can be refined; a blank can't.

Field 5: three decoded reference postings

This is where you bring the market's raw reality into the exercise. Find three real postings that match your target role, and decode them using what you learned in the job-posting anatomy and "what B2 or C1 actually means" lessons.

For each one, record a row:

Posting	English level required	Real requirements (must) vs. nice-to-haves	Applicable to me today?
Company A — Backend Engineer	`B2, written and spoken`	Must: Python, SQL. Nice: Kubernetes	Yes, with a speaking gap
Company B — Backend Engineer	`Fluent English` (vague)	Must: 3 yrs, APIs. Nice: AWS	Yes, verify real level
Company C — Backend Engineer	`C1, client-facing`	Must: client communication	Not yet — insufficient speaking

Notice what this field teaches you at a glance: Company C rules you out today not because of your code but because of client-facing spoken English, and that's incredibly valuable information, not a failure. It tells you exactly which skill opens or closes which doors. That's the bridge to field 6.

A couple of posting phrases worth being able to read without translating, because they show up constantly:

Excellent written and verbal communication skills → they want you to write AND speak well; reading isn't enough. You'll work closely with stakeholders → there will be meetings with non-technical people; spoken English carries weight. Async-first team → a lot of written communication (PRs, docs); writing carries more weight than in a meeting-heavy team.

What to expect: decoding three postings takes a while the first time, maybe half an hour. By the tenth, you do it in two minutes without translating. That speed is this module's exit capability.

Field 6: your English gap by skill

This is the heart of the brief, and the one that demands the most honesty. English isn't "one" level; it's four skills that almost never sit at the same level. It's normal for a Spanish-speaking developer to read far above what they speak. Separating them frees you from the paralyzing phrase "I don't know English," which is almost always false.

Assess yourself on each skill against concrete can-do descriptors, not against an abstract grade:

Skill	B1 descriptor (this guide's floor)	B2 descriptor (work target)	Your level today
Reading	I read technical docs and tickets with effort but no translator	I read docs, PRs, and RFCs fluently	___
Writing	I write an understandable standup message with mistakes	I write a clear PR and design doc	___
Listening	I follow a clear talk with subtitles	I follow a meeting with multiple accents without subtitles	___
Speaking	I explain my code for ~2 min with mistakes, and I'm understood	I hold a structured interview and a standup	___

Here's the most important floor statement in the whole module, and why this guide is honest with you:

This guide assumes you're already at B1 reading and B1 speaking. B1 speaking means exactly what's in the table: you can hold about two minutes explaining your code, with mistakes, and the other person understands you. It doesn't ask for elegance. It asks for the message to land.

If your speaking is at A2 — meaning you can't hold two technical minutes without freezing up completely — the honest path isn't forcing this guide. It's doing general English first (a few months of basic oral practice) and coming back here after. It's not a punishment or a judgment: it's the sequence that works. Attempting this guide's oral module from A2 is like trying to run a marathon without walking five kilometers first; it's not your willpower that fails, it's the sequence. And for that same reason, this guide does not promise that you'll improvise a demo fielding open questions from a large audience. That's general conversational fluency, a different league. What it does promise, and deliver, is technical communication for work: standup, code explanation, PR, design document, structured interview. Narrow situations, with predictable vocabulary, that can be prepared for and that are precisely what get you and keep you the role.

In the brief, write one line per skill with your level and the evidence, just like you did with seniority. Example:

Reading: B2 — I read FastAPI docs and GitHub issues without a translator. Writing: B1 — I can write a standup update; my PRs need review for grammar. Listening: B1 — I follow clear talks with subtitles; native fast speech loses me. Speaking: B1 (low) — I can explain my code for two minutes, but I freeze in Q&A.

What to expect: seeing your four levels separately, in writing, usually brings relief, not anguish. You almost always discover your reading is already work-ready and that the real gap is a single skill — usually speaking, sometimes listening. A problem with a first and last name gets tackled. "I don't know English" doesn't get tackled, it just weighs on you.

Field 7: your cadenced practice plan

The gap from field 6 doesn't close by wishing it away. It closes with a plan that says what you do every week between this guide's modules. This is the field that turns your brief from a diagnosis into a machine.

First, the order of attack. Attack in the order the skills block your role, and that order is almost always:

Reading first (if it's not solid) — because it holds up everything else: you can't write a PR or follow a meeting if reading exhausts you.
Writing — because it's the technical skill most practicable solo and the one that carries the most weight on async teams.
Listening — because it's the one most people underestimate and the one that wrecks real meetings.
Speaking last — because it leans on the previous three and it's where the gate we define below lives.

Now the cadence: what you literally do every week. Small and constant wins. This is the table you copy into your brief and adjust to your real available time:

Skill	Concrete weekly practice	Honest minimum dose
Reading	Decode 1 real posting + read 1 technical doc in English with no translator	15 min/day
Writing	Write your daily standup in English; 1 PR description per week	5 min/day + 1 PR
Listening	Step method (below)	10–15 min/day
Speaking	Explain your code out loud for 2 min, recording yourself, then relisten	2 min/day

On listening, which deserves its own method rather than a footnote, because it's the skill that most silently sabotages you in a real meeting. Practice it in steps, deliberately raising the difficulty:

Step 1 — clean audio, clear accent: recorded technical talks (conference talks, for example) with English subtitles. Goal: get your ear used to spoken technical vocabulary.
Step 2 — drop the subtitles: the same talk, no text. Goal: stop reading and start hearing.
Step 3 — non-native accents: your real team doesn't talk like a newscaster. Listen to speakers with Indian, Eastern European, Southeast Asian, Brazilian accents. Work English is, for the most part, non-native English spoken to other non-natives.
Step 4 — bad audio: video-call meeting recordings, with compression, cutouts, and people talking over each other. This is the step that actually resembles a Monday-morning standup.

Don't jump from step 1 to step 4. Move up one at a time, and only once the previous one feels comfortable. Listening trains like a muscle, with progressive overload.

And finally, the gate (the rule that protects your time):

Don't move into the guide's oral part without the B1 speaking floor. That is: holding two minutes explaining your code, with mistakes, and being understood.

If by the end of this module your speaking is below that floor, your practice plan is extended module 1: weeks of the cadence above, focused on speaking and listening, until you cross the gate. Crossing it isn't optional, and skipping it isn't a shortcut: the oral module is built assuming that floor, and without it you'll get frustrated with material that isn't for your level yet. The gate doesn't hold you back; it saves you from crashing.

What to expect: the cadence feels ridiculously small — fifteen minutes, two minutes — and that's exactly why it works. Daily consistency in minimum doses always beats the heroic weekend marathon you never repeat. In six weeks of minimum doses, most people who already read technical English cross the gate.

The rubric: can a stranger understand what you're applying for?

Your brief is done when it passes this test, and not before. Hand it to someone who doesn't know your situation — a colleague, a friend, even someone outside tech — and ask them to answer, without you explaining anything:

Criterion	The concrete test	Passes?
Clear role	Can they name the exact role you're applying for?	☐
Credible seniority	Can they state your level and why it's credible?	☐
Real market	Do they know where you can be hired and in what time-zone window?	☐
Anchored salary	Do they see a range, not a number pulled from thin air?	☐
Named gap	Can they say which skill you still need to close?	☐
Visible plan	Do they see what you'll do each week to close it?	☐

The acceptance criterion, in one sentence: if a stranger finishes reading your brief and can say what role you're applying for and why you're a credible candidate — including, calmly, what's missing — the brief is ready. If they have to ask you "but what are you actually aiming for?", go back to field 1.

An important note for the impostor voice you're carrying: "credible candidate" doesn't mean "candidate with no gaps." It means a candidate who knows their gaps and has a plan for them. Naming what's missing, with a plan next to it, is what makes you credible. Hiding it is what makes you suspicious.

Full template to copy

Copy this, fill it in, and trim it until it fits on one page. The fields go in English on purpose: they're the ones you'll reuse afterward in your profile, your resume, and your interview.

TARGET ROLE BRIEF — [your name] — [date, to know when to update]

1. TARGET ROLE
   Title: [Backend Engineer (Python)]
   Positioning: "I'm a [mid-level] [role] who builds [what]
                 with [stack], focused on [strength]."

2. CLAIMABLE SENIORITY
   Level: [mid-level]
   Evidence: [owned 2 services end to end; mentored 1 junior]
   Honest ceiling: "I haven't yet led a full system design."

3. MARKET / GEOGRAPHY / TIME ZONES
   Markets: [US remote (LATAM-friendly), EU (Spain-based)]
   Overlap: [~5h/day with US Eastern]
   Hiring model: [contractor]

4. SALARY BAND (target market, not local)
   Floor: [$___]  Target: [$___]  Realistic ceiling: [$___]

5. THREE REFERENCE JOBS (decoded)
   A) [company] — English: [B2] — Must: [__] — Applicable: [yes/gap]
   B) ...
   C) ...

6. ENGLISH GAP BY SKILL (level + evidence)
   Reading:   [B2 — ______]
   Writing:   [B1 — ______]
   Listening: [B1 — ______]
   Speaking:  [B1 low — ______]

7. WEEKLY PRACTICE PLAN + GATE
   Order of attack: [reading > writing > listening > speaking]
   Cadence: [15m reading/day · standup in English/day · listening
             ladder 10m/day · 2m recorded speaking/day]
   GATE: no oral module until I can explain my code 2 min, B1.

Common mistakes when building the brief

A two-page brief. If it doesn't fit on one, you haven't decided — you've described. Trim until it hurts.
Claims with no evidence. Every level — seniority and English — carries its proof on the line next to it, or it doesn't go in.
Wrong-market salary. Anchoring it to your local band when you're targeting a different one is the most expensive mistake. Use the target market's.
A gap as one lump. "I'm missing English" isn't a gap; it's a weight. The gap is per skill, with a level and evidence.
A plan with no cadence. "I'm going to practice more" isn't a plan. "15 minutes of reading a day and 2 of recorded speaking" is.
A frozen brief. Date it and reread it every two or three weeks. An old brief lies about who you are today.

Exercises

These exercises make you operate the brief, field by field, before you write your own. Do each one with a pencil before opening the solution: the value is in deciding for yourself first, not in reading the answer.

Exercise 1 — Field 1: title and positioning sentence

A developer has two years building REST APIs with Node.js and Express, and their strongest area is payment integrations (Stripe). Write for them: (a) the role title the way the market writes it in English, and (b) the positioning sentence using the template I'm a [seniority] [role] who builds [what] with [main stack], focused on [domain or strength].

See solution

Title: Backend Engineer (Node.js)
Positioning: I'm a mid-level Backend Engineer who builds REST APIs with Node.js and Express, focused on payment integrations.

Why this works: the title is in English and uses the market's term (Engineer), so it's the keyword they'll search and show up under; the sentence describes one sharp profile (not "does a bit of everything"), and the focus on payment integrations makes it memorable instead of generic. It already works as-is to answer "So, what do you do?"

Exercise 2 — Field 2: claimable or not?

For each claim, decide whether it's claimable today and explain why in one line:

a) Senior Backend Engineer — six years at the same company executing tickets already defined by the tech lead. b) Mid-level Backend Engineer — designed a service's data schema from scratch and took it to production; mentored an intern. c) Junior Data Engineer — eight months on a production pipeline, writes their own tests.

See solution

a) Not senior yet. Seniority is autonomy and decision scope, not tenure. Six years executing pre-chewed tasks supports, at most, a mid-level claim.
b) Yes, mid-level. There's evidence of end-to-end ownership (designed and shipped to production) plus mentoring; the claim has its proof on the same line.
c) Yes, junior. Real production plus own tests is concrete evidence backing the junior level without inflating it.

Why this works: every claim is validated by the evidence next to it, not by wishing or by years accumulated. If the evidence column is empty, there's no claim; if it's full, you've earned the right to it.

Exercise 3 — Fields 4 and 5: decoding posting phrases

Translate what these phrases actually demand (without translating word for word) and say which skill carries weight:

a) Excellent written and verbal communication skills b) Async-first team c) Compensation: DOE

See solution

a) They want you to write and speak well, not just read. Writing and speaking carry weight.
b) The team coordinates mostly in writing (PRs, docs) and has few synchronous meetings: writing carries weight, and a speaking gap matters less.
c) DOE = depending on experience: the number depends on your profile and is negotiable. It's not a rejection or a fixed, closed salary.

Why this works: reading the posting for its real intent — not word for word — tells you which skill opens or closes which doors, and keeps an acronym like DOE from intimidating you when it actually works in your favor.

Exercise 4 — Fields 6 and 7: gap, order of attack, and the gate

A developer self-assesses as: Reading B2, Writing B1, Listening A2, Speaking A2 (can't hold two technical minutes without freezing up completely). Answer: (a) what's their real order of attack?, (b) do they cross the gate into the oral module today?, (c) what does this guide recommend?

See solution

a) Their reading is already work-ready, so it's not the target. The real order is writing (raising it from B1) but with urgent focus on listening and speaking, which are at A2 and are what's blocking the role: writing → listening → speaking.
b) No. The gate requires a B1 speaking floor (holding ~2 min explaining their code, with mistakes, and being understood). At A2, they don't cross it.
c) Do general English first — a few months of basic oral practice to raise speaking and listening from A2 to B1 — applying the minimum-dose cadence, and come back to the oral module once they cross the gate.

Why this works: separating the four skills turns "I don't know English" into a problem with a name (speaking and listening at A2) and respects the sequence the guide promises to honor: forcing the oral module from A2 frustrates without teaching anything.

Closing

If you made it here still carrying the feeling that "your English isn't good enough" to work abroad, look at what you just did: you broke that feeling down into four measurable skills, discovered that at least one — almost certainly your reading — is already work-ready, put a name on the one that's missing, and gave it a fifteen-minutes-a-day plan. That's not what someone who "isn't good enough" does. That's what someone already inside the process does, who just had a messy diagnosis.

Linguistic impostor syndrome feeds on vagueness: it thrives when "my English" is one gray cloud you know nothing concrete about. Your brief is the exact antidote, because it swaps the cloud for a table. A table isn't scary: you work it row by row, and every row you close is a door that opens.

Keep your brief somewhere you'll see it often. It's the map you're going to walk the next few modules with: the writing module will sharpen your field 6 on writing, the oral module will get you across your field 7 gate, and the real job-search module will turn your three decoded postings into real applications. You didn't start this module knowing English; you finished it knowing exactly which English you're missing and how to get it. That clarity, not a certificate, is what separates the person who lands the role from the one who's still feeling like they're not good enough. You've already taken the first step. Keep going.

Summary and next step

In this lesson you condensed the module's seven pieces into a single operating artifact — the target role brief — and learned to fill its seven fields with evidence and no illusions: role in English, claimable seniority, market and time zones, salary band anchored to the target market, three decoded postings, English gap by skill, and a cadenced practice plan plus its B1 speaking gate.

Before moving on to the next module, you should be able to:

Name your target role in English and say your positioning sentence without hesitating.
Claim your seniority with the evidence written on the line next to it, neither inflated nor shrunk.
Point to which markets and time-zone windows you can be hired in, and under what hiring arrangement.
Show a salary range (floor, target, ceiling) anchored to the target market, not the local one.
State your level in each of the four skills with one piece of evidence per line.
Have your weekly cadenced plan and your B1 speaking gate written down.

If any of these points still makes you hesitate, go back to the corresponding field before moving on: the brief is the board for the modules ahead, and an empty box here gets paid for later.

The bridge: with the brief in hand, the next module — the writing one — takes your field 6 on writing and your field 5 of decoded postings and turns them into a resume and an English profile that speak the exact language of those postings. There, your brief stops being a diagnosis and starts producing the documents you actually apply with.

Resources

Europass — CEFR self-assessment grid — the official self-assessment grid by skill (reading, listening, spoken interaction, spoken production, writing) from A1 to C2. Use it to fill your field 6 with concrete can-do descriptors instead of an abstract grade.
Cambridge English — The CEFR — a clear explanation of what each A1–C2 level is and how it maps to real ability, with examples of spoken performance per level. Good backing for calibrating your "B1 speaking" against a recognized standard.
Levels.fyi — software engineering compensation data by level and location, with a calculator and percentiles. A reference for anchoring your field 4 to the target market, not the local one.
We Work Remotely — a board of remote postings with backend, frontend, and full-stack categories, and filters by contract type and geographic restriction. A source for the three reference postings in field 5.
Stack Overflow Developer Survey — an annual survey of tens of thousands of developers with data on roles, technologies, and pay by country. Useful for contrasting your salary band and stack against the global market.

← Previous7. Where the Role Actually Exists: Geography, Time Zones, and Remote Hiring Next →1. Introduction: The English You Already Know and Don't Use