Module 6: Your Professional Materials in English

7. Your English Elevator Pitch

Next →

Description

Almost every interview, every call with a recruiter, and every networking conversation opens with the same line: "Tell me about yourself." It sounds harmless, but it's the question most people ruin, because they read it as "tell me your life story" and launch into a five-minute autobiography that starts in college. What's actually being asked of you is a short, organized summary relevant to the role: who you are today, what part of your background matters here, proof that you can do what you say, and why this posting. That's the elevator pitch: the ninety-second answer you can give in the time an elevator ride takes.

And here's the good news, especially if English scares you. A pitch doesn't get improvised: it gets written, rehearsed, and memorized as a structure. You don't need conversational fluency to nail ninety prepared seconds. You need a roughly two-hundred-word script that you said out loud twenty times until it came out on its own. That's the difference between "speaking fluent English" (hard, long) and "delivering my pitch in English without freezing up" (achievable this week). If you carry impostor syndrome about the language, start here: the pitch is the piece of spoken English that gives you the most control, because you write every word ahead of time.

Connection to the module: this is the module where you package your evidence into the artifacts the market reviews. The résumé (lessons 2 through 4), the LinkedIn profile (lesson 5), and the portfolio (lesson 6) are the written pieces; the pitch is the spoken version of all of them. In fact, your pitch comes out of material you've already built: module 1's target role brief tells you which role you're speaking for, module 3's impact bullets are the evidence you cite, and module 5's speaking work is the muscle you put to use here. The previous lesson closed out your portfolio as evidence; this one turns that evidence into something you can say out loud. The next lesson brings everything together into a complete application kit, so here we stay focused on one single piece: the pitch, written, spoken, timed, and adapted.

Before you record anything: the honest floor

A ninety-second pitch is memorized text. That makes it accessible even if your spoken English still stumbles: you're not conversing, you're reciting something you rehearsed. But let's be clear about what comes after the pitch, because that's where a lot of people crash.

When you finish saying your pitch, the other person doesn't clap and change the subject. They follow up. "You mentioned a rate limiter — how did you decide on the token-bucket approach?" And there's no script there anymore. There you need this guide's floor: reading technical English with ease and holding about two minutes of speech, with mistakes, about your own work. If that floor isn't there yet — if talking about your code in English leaves you blank after the second sentence — the memorized pitch will get you to the door, but the conversation that follows will overwhelm you.

That's why this lesson doesn't promise that a good pitch will let you improvise a fluent technical talk in front of a panel. It promises something concrete and real: a solid, controlled opening that buys you the first ninety seconds and gives you confidence for what comes next. If you've been practicing module 5's speaking work with the weekly cadence we set in module 1, the pitch is your reward: the first time your spoken English sounds professional from start to finish. If your speaking is still at A2 — loose sentences, a lot of silence — record the pitch anyway as an exercise, but don't show up to oral interviews yet. That's module 1's gate: you don't cross into live oral situations without the speaking floor.

The structure: four beats, not an autobiography

Every good pitch has the same four beats, in this order. Think of it like a song with four measures: if you know the structure, you only change the lyrics depending on the posting.

BeatWhat it answersHow longCommon mistake
1. PresentWho are you today, in one line?~10 secStarting from childhood or college
2. Relevant trajectoryWhat from your past matters for this role?~25 secTelling everything in chronological order
3. EvidenceWhat concrete proof do you have that you can do it?~30 secAdjectives ("I'm very dedicated") instead of a result
4. Why this postingWhy you, and why here?~25 secA generic close that fits any company

The key is in the words "relevant" and "concrete." You don't tell your entire trajectory: you choose the two or three pieces that connect with the role and drop the rest without guilt. And you don't describe yourself with adjectives, you show a measurable result. It's exactly the same discipline as module 3's impact bullets, now said out loud.

Here's the skeleton in English, with the blanks you fill in:

"Hi, I'm [name]. I'm a [role] with [X years / a background in Y]. Right now I [current focus — what you build or maintain]. Before that, [one relevant piece of trajectory that connects to this role]. The project I'm most proud of is [one concrete piece of evidence — a result or a shipped project]. I'm looking for [target role], and I'm interested in this one because [a specific reason tied to THIS vacancy]."

Notice the mentally-bolded connectors: Right now…, Before that…, The project I'm most proud of is…, I'm interested in this one because…. These are signals that tell the listener which beat you're on. In spoken English these connectors (signposting) are worth their weight in gold, because they give the listener — and you — a clear structure even if your accent or grammar aren't perfect.

A complete, assembled example

Ana is a backend developer. Here's how she fills the skeleton for a FastAPI posting:

"Hi, I'm Ana. I'm a backend developer with three years of experience building APIs in Python. Right now I maintain the payments service at a fintech startup — it handles around ten thousand transactions a day. Before that, I came from a support engineering role, so I'm used to turning vague problems into tickets the team can actually work on. The project I'm most proud of is a rate limiter I built for our API gateway: we were going down during traffic spikes, so I added a token-bucket limiter backed by Redis, and it cut our error rate during peaks from eight percent to under one. I'm looking for a remote backend role where I can grow toward senior, and this one caught my eye because you work with FastAPI and event-driven systems — that's exactly what I've been focused on this year."

Say it out loud and you'll see it fits into about ninety seconds flat. Notice what's not there: no college, no irrelevant first job, no "I'm a very proactive person eager to learn." There's a present, a filtered trajectory, a result with a number, and a close that only works for this company.

The same pitch, three audiences

An expensive mistake is giving the same pitch to everyone. The four-beat structure doesn't change, but the technical level, tone, and close adjust depending on who's listening. Here are the three audiences you're going to run into:

RecruiterTechnical managerNetworking
What they're looking forFit, level, availabilityWhat you can actually buildGetting to know you, no posting involved
Technical levelLow — avoid jargonHigh — goes into detailMedium — depends who you're talking to
The evidence beatThe what and the resultThe how: technical decisionsA shared curiosity
CloseWhat role you're looking forWhy you fit the teamA question, not a "hire me"
Duration60–90 sec90 sec, with more depth30–45 sec, informal

With the recruiter you lower the technical level. You don't say "token-bucket," you say the result in plain language:

"I built a system that kept our API stable during traffic spikes — it brought our error rate way down."

With the technical manager you do exactly the opposite: you go into the how, because that's where they're evaluating you.

"We were getting hit by bursts of traffic that took the gateway down, so I implemented a token-bucket rate limiter backed by Redis. I chose token-bucket over a fixed window because it handles short bursts more gracefully. It's been in production for six months."

At networking events there's no posting, so you don't close by selling yourself: you close with a question that opens up conversation.

"Hi, I'm Ana — nice to meet you. I'm a backend developer, mostly Python these days. I came to this meetup because I've been getting into event-driven systems and I wanted to hear how other people run them in production. What are you working on?"

That final turn — ending by asking — is what separates someone who "networks" from someone who interrogates. It leaves the ball in the other person's court.

Written and spoken aren't the same text

You're going to have your pitch in two formats: written (your LinkedIn "About," an email intro, an application's cover note) and spoken (the interview, the call, the event). A lot of people make the mistake of memorizing the written text and reciting it as-is. It sounds like a robot reading, and it shows.

The reason is that written and spoken English have different rhythms. These are the differences that matter:

WrittenSpoken
Longer sentences, with subordinate clausesShort sentences, one idea per sentence
Full forms: I am, I haveContractions: I'm, I've, that's
Can be reread if the reader gets lostThe listener only hears it once → more signals needed
No fillerNatural pauses to breathe
Dense, makes the most of every wordLeaves room; a bit of repetition is fine

Compare the same idea in the two registers:

Written (LinkedIn About): "Backend developer with three years of experience designing and maintaining Python APIs in production-critical financial systems."

Spoken (interview): "I'm a backend developer. I've spent about three years building Python APIs — mostly in fintech, so systems that can't go down."

Same person, same information, two rhythms. The written one is dense and can be reread; the spoken one breathes, uses contractions, and splits the long sentence into two. When you prepare your spoken pitch, write it the way you'd say it, not the way you'd draft it. A trick: say it out loud first, transcribe it, and that's your script. Not the other way around.

Talking about a career change or a gap without apologizing

This is where impostor syndrome does the most damage. If you're coming from a different profession, if your experience is bootcamp and personal projects, or if there's a months-long gap on your résumé, the temptation is to open with an apology. Don't apologize. An apology tells the listener "there's a problem here" before they'd even noticed one.

The rule is simple: a career change isn't a weakness to confess, it's a story to frame. You name the fact naturally, say what you bring from that past, and move on to the evidence. No "unfortunately," no "just," no "barely."

Situation❌ With apology (avoid it)✅ Framed (use it)
Career change"I don't really have professional experience, I just did a bootcamp, so…""I moved into software from accounting. That means I read financial requirements the way the business does — and I've spent the last year building projects to back it up."
Résumé gap"Sorry, there's a gap because I was unemployed for a while.""I took a year out to care for family. I kept my skills current with [X], and I'm now fully focused on getting back into backend work."
Little formal experience"I've only worked on personal projects, nothing real.""Most of my work so far has been project-based — you can clone the latest one from my GitHub and run it in two commands."

Notice the pattern in the right column: neutral fact → what you bring → concrete evidence. The word "only" is the one that betrays you most in English: "I only did a bootcamp," "I've only built personal projects." Every time you say it, you're shrinking your own work. Erase it from the pitch. A project that clones and runs is a real project, with no "only" attached to it.

Record, time, trim

A pitch isn't ready when you write it: it's ready once you've said it out loud until it came out naturally and fit the time. This is the cycle, and it's short:

  1. Write the script following the four beats, in spoken register.
  2. Count the words. At a normal speaking pace (about 130–150 words per minute), ninety seconds is between 190 and 220 words. If your script has 350, it doesn't fit: trim before you record.
  3. Record yourself with your phone. Audio alone is enough.
  4. Listen to it all the way through. Yes, it's uncomfortable. Do it anyway.
  5. Flag three things: where you ran over time, where you dropped in filler words (um, like, you know, basically, actually, kind of), and where it sounded like read text instead of a person talking.
  6. Trim and re-record. Repeat until it fits the time and sounds like you.

What to trim when it doesn't fit, in this order: first the adjectives ("a really interesting and challenging project" → "a project"); then the extra context ("Before that, back in 2019, when I was still…" → "Before that…"); then the excess evidence (one strong piece of proof beats three half-there ones — the same logic as module 6's single project). The last thing you touch is the four-beat structure: those beats always stay.

What to expect from the recordings. Your first take is going to run twice as long as you think and sound stiff. That's completely normal, it happens to everyone. By around the third or fourth take the text starts loosening up; by the fifth or sixth it sounds like someone telling something, not reciting it. Don't chase the perfect take on attempt one. Aim to do six bad takes fast, because the good one comes from having repeated it, not from having thought about it more.

A detail about accent that reassures a lot of people: you don't need to sound native. Evaluators in tech are used to accents from all over the world; what they need is to understand you. Prioritize in this order: (1) that every word gets understood, (2) rhythm and pauses, (3) accent, way at the end. A clear pitch with a heavy accent always beats a pitch "with a good accent" that goes so fast nobody can follow it.

How this fits into your weekly practice

In module 1 we set a cadence: every week, between modules, you practice one concrete piece instead of "studying English" in the abstract. The pitch is one of the best pieces for that routine, because it's short, measurable, and the improvement shows fast.

A realistic cadence for this week:

  • Day 1: write the script (four beats, ~200 words) and count the words.
  • Day 2: first batch of recordings. Listen to yourself, flag filler words and timing.
  • Day 3: trim and re-record until it fits ninety seconds and sounds natural.
  • Day 4: make the recruiter variant (less technical) and the manager variant (more technical).
  • Day 5: record the networking version, the short one, ending in a question.
  • Close: one clean take of each version, saved. That's your pitch bank.

And remember module 1's gate: recording the pitch is an exercise you can do at any level, because it's controlled text. But showing up to a live oral interview — where the pitch is followed by unscripted follow-up questions — only makes sense once your speaking floor is in place. If it isn't yet, keep at module 5's listening and speaking practice for a few more weeks, with the pitch as your daily warm-up. It's not a delay: it's arriving at the interview with the muscle ready, instead of praying nobody asks you anything.

Listening gets practiced here too

The pitch looks like a purely speaking exercise, but half of the real encounter is listening: the question the recruiter asks before you even start, and above all the follow-up questions that come after. And those don't arrive in the clean English of a course recording. They arrive with an Indian, Nigerian, German, or Southern US accent, sometimes over a call with an echo or a bad microphone.

So while you rehearse the pitch, train your listening with method, not by chance:

  • Steps: start listening to material at 0.75x speed, move up to 1x, and once you've mastered it, set it to 1.25x. Once 1.25x feels comfortable, a real interview's actual speed will sound slow to you.
  • Non-native accents: look for technical talks (conference presentations in your stack, for example) given by non-native speakers. That's the English you're actually going to hear on a distributed team.
  • Bad audio on purpose: listen to a technical podcast with no subtitles, on the bus or while walking, with background noise. Training your ear under imperfect conditions is what saves you on the day of a call with bad signal.

A couple of phrases to have ready for when you don't understand a follow-up question — and you're going to need them, asking for a repeat isn't failure:

"Sorry, could you say that again?" "Just to make sure I understood — you're asking about [X], right?"

Asking for clarification in English, calmly, looks more professional than guessing and answering something else. An engineer who confirms before acting is exactly what a team wants.

Exercises

Exercise 1 — Write your four-beat script

Write your own elevator pitch in English following the four-beat structure (Present → Relevant trajectory → Evidence → Why this posting) for a real or hypothetical role that interests you. Count the words when you're done: does it fall between 190 and 220?

See solution

There's no single correct answer — your pitch depends on your real story — but here's a complete example within range:

"Hi, I'm Marcos. I'm a frontend developer with two years of experience building React applications. Right now I work on the checkout flow for an e-commerce platform, focused on performance and accessibility. Before that, I spent a year as a QA analyst, which is why I catch edge cases most developers miss. The project I'm most proud of is a checkout redesign that cut our page load time from four seconds to under one and reduced cart abandonment by twelve percent. I'm looking for a frontend role where performance actually matters, and this one caught my eye because your team ships to millions of users on slow connections — that's exactly the kind of problem I want to keep solving."

Why this works: it respects the four-beat order, filters the trajectory (only the QA year that explains a current strength, not the rest of the history), replaces adjectives with a result carrying two measurable numbers, and closes with a reason that only applies to that company. At 130-150 words per minute, this text fits right into ninety seconds.

Exercise 2 — Adapt the same fact to two audiences

Take this technical evidence sentence: "I chose token-bucket over a fixed window because it handles short bursts more gracefully." Rewrite it twice: (a) for a recruiter, with no technical jargon, and (b) for a networking conversation, closing with a question instead of selling yourself.

See solution

(a) Recruiter: "I built a system that kept our API stable during traffic spikes without slowing things down for regular users."

(b) Networking: "I spent a few months last year figuring out the best way to handle sudden traffic spikes without the whole system falling over — have you run into that on your end?"

Why this works: version (a) translates the technical decision ("token-bucket vs. fixed window") into its plain-language result, because the recruiter evaluates fit, not architecture. Version (b) lowers the technical level even further and ends with an open question, because in networking there's no posting to sell — there's a conversation to open.

Exercise 3 — Reframe without apologizing

Rewrite this sentence using the pattern neutral fact → what you bring → evidence, with no apology and no word "only": "Sorry, I don't have a CS degree, I just taught myself to code from online courses, so my experience is kind of limited."

See solution

"I'm self-taught — I learned to code through project-based online courses instead of a CS degree. That means everything I know, I've already applied to a real project: you can clone my latest one from GitHub and run it in two commands."

Why this works: it removes "sorry," "just," and "kind of limited" — the three words that shrink the achievement before the listener even judges it — names the fact (self-taught) naturally, and turns it into a strength (learning applied to real projects) backed by verifiable evidence.

Exercise 4 — Trim for time

This script fragment is too long for ninety seconds. Trim it applying the lesson's priority order (adjectives first, then extra context, then excess evidence, never the structure):

"Before that, back in twenty-nineteen, when I was still working in a completely different and honestly pretty unrelated field doing customer support, I actually learned a huge amount about how to take a really vague and confusing problem from a frustrated customer and turn it into something clear and actionable that an engineering team could actually work with and prioritize properly."

See solution

"Before that, I worked in customer support, which taught me how to turn a vague, frustrating problem into something an engineering team can actually act on."

Why this works: it cuts from sixty to twenty-five words without losing the point: it removes the redundant adjectives ("completely different and honestly pretty unrelated", "really vague and confusing"), removes the extra context (the exact year, "actually learned a huge amount"), and keeps the "relevant trajectory" beat intact — the same fact, said in a third of the time.

Summary and next step

The pitch is the piece of spoken English you have the most control over, and that's why it's the best place to start feeling like you actually can do this. You don't improvise it: you write it in four beats — present, relevant trajectory, evidence, why this posting — you adapt it to the three audiences you're going to encounter, you say it out loud until it sounds like yours and fits ninety seconds, and you talk about your path with no "only" attached. It's the spoken version of all the evidence you've already packaged in this module.

Before moving on, you should be able to:

  • Write a 190-to-220-word script that respects the four beats, in spoken register (contractions, short sentences).
  • Adapt that same pitch for a recruiter, a technical manager, and a networking conversation, adjusting the technical level and the close.
  • Record yourself, time yourself, and trim without ever touching the four-beat structure.
  • Talk about a career change, a résumé gap, or limited formal experience without apologizing and without the word "only."

You now have the seven pieces: target, comprehension, writing, documentation, speaking, written materials, and this pitch. The next lesson brings them together into a single complete application kit, ready to send to a real posting. There you'll see how the résumé, the profile, the portfolio, and the pitch stop being separate artifacts and become a coherent candidacy.

Resources

← Previous6. GitHub and Portfolio as EvidenceNext →8. Project: Complete Application Kit