English Technical Interview Preparation

The Three Parts of a Technical Interview

English technical interviews typically include:

1. Self-Introduction (2-3 minutes) — Quickly explain who you are and what you’ve done
2. Technical Discussion (30-45 minutes) — Problem-solving or design discussion
3. Behavioral Questions (10-15 minutes) — Past experiences and work style

Tip

Each part has standard expressions and frameworks. It’s not about creativity — it’s about preparation and practice.

Part 1: Self-Introduction

The purpose of the self-introduction isn’t to cover your entire career, but to set the context for the conversation that follows.

Basic Framework (2-3 minutes)

Hello, I'm [name]. I'm a [role] from [location] with [X years]
of experience in [domain].

Most recently, I [major accomplishment or current work].

Before that, I worked on [relevant experience].

I'm particularly interested in [relevant area to this role].

Full Example

Hi, I'm Alex Chen. I'm a full-stack engineer from Shanghai with
4 years of experience building scalable web applications.

Most recently, I led the migration of our monolithic API to microservices
at ByteDance, which reduced latency by 40% and improved our deployment
frequency from weekly to daily.

Before that, I worked at Alibaba on the payment platform, where I
implemented distributed transaction handling for high-frequency trading.

I'm particularly interested in backend systems and cloud architecture,
which is why I'm excited about this infrastructure role.

Key Elements

Element	Example	Why It Matters
Clear identity	”Full-stack engineer”	Lets the interviewer quickly place your background
Numbers and results	”4 years,” “40% latency reduction”	Shows real accomplishments, not vague claims
Company/project names	”ByteDance,” “payment platform”	Proves your experience is verifiable
Relevance	”…which is why I’m excited about this role”	Shows you want this specific position

Caution

Don’t say:

• “I’m a hardworking and dedicated engineer” (too vague)
• “I know many programming languages” (no results)
• “I’ve been doing software development for a long time” (too vague)

Practicing Self-Introduction with Express Mode

Draft your self-introduction in your native language, then polish it with Express Mode:

Draft:
"My name is Alex, I'm a backend engineer at ByteDance with 4 years
of experience. Recently working on microservice architecture migration
that reduced latency."

Paste into Express Mode:

Basic (Direct):
  "My name is Alex. I work as a backend engineer at ByteDance
   with 4 years of experience. Recently I've been working on
   microservices migration that reduced latency."

Intermediate (Natural):
  "Hi, I'm Alex. I'm a backend engineer at ByteDance with 4 years
   of experience. I've recently led a microservices migration that
   improved our system latency."

Native (Idiomatic):
  "Hi, I'm Alex. I'm a backend engineer at ByteDance where I've
   spent 4 years building scalable systems. Most recently, I led
   a microservices migration that reduced latency by 40%."

Choose the Native version, memorize it, and practice several times.

Part 2: Technical Discussion

Coding Interview

When the interviewer gives you an algorithm or system design problem, follow this flow:

1. Clarify

Don’t start coding immediately. Ask questions first to make sure you understand the requirements.

Interviewer: "Design a URL shortener service"

You:
"Thanks for the problem. Let me clarify a few things:
  - How many URLs do we expect to shorten per day?
  - Should the shortened URLs expire after a certain time?
  - Do we need to support custom short links?
  - Should we track analytics (click count, etc)?"

Common phrases:

• “Let me clarify…”
• “Could you provide more context on…?”
• “Are we optimizing for X or Y?”
• “What’s the scale we’re targeting?“

2. Walk Through Your Approach

Approach:
"Here's my approach: First, I'll use a hash function to convert
long URLs to short codes. Then store the mapping in a database.
For lookups, I'll query the database by short code and redirect.

For scale, I'm thinking about:
  - Using a NoSQL database (like DynamoDB) for fast lookups
  - Adding a cache layer (Redis) for hot URLs
  - Sharding by short code prefix to distribute load"

Key expressions:

• “I’m thinking about…” — stating your idea
• “The trade-off here is…” — explaining trade-offs
• “For scale, we could…” — explaining optimization plans

3. Implement

"Now let me code this. I'll start with the basic structure,
then we can optimize if needed.

[start coding]

For error handling, I'm assuming the short URL already exists
should return an error, right?"

Talk while you code to let the interviewer follow your thought process.

4. Test

"Let me test this with a few cases:
  - Normal case: valid long URL -> should return short code
  - Edge case: very long URL (10KB)
  - Edge case: duplicate submission (same long URL twice)
  - Error case: invalid input (empty string)"

Tip

Say your thoughts out loud. Staying silent for 30 minutes and then explaining the code will make the interviewer nervous.

System Design Interview

System design questions are typically “design a large system,” such as “Design Twitter” or “Design Uber.”

Standard framework (within one hour):

1. Functional Requirements (5 minutes)

"Let me clarify the requirements:
  Must-have: Users can post tweets, see their timeline
  Nice-to-have: Recommendations, trending topics"

2. Non-Functional Requirements (5 minutes)

"I'm assuming:
  - 300 million monthly users
  - 100K concurrent users during peak hours
  - Latency < 200ms for timeline requests
  - Should be highly available"

3. API Design (5 minutes)

POST /tweets - Create tweet
GET /tweets/{tweet_id} - Get tweet
GET /timeline - Get user's timeline

4. Database Design (10 minutes)

"For user data, I'd use:
  - SQL database for user profiles (high consistency needed)
  - NoSQL for tweets (high write volume, eventual consistency OK)
  - Cache layer (Redis) for hot timelines"

5. Architecture (15 minutes)

"Architecture:
  - Load balancer to distribute traffic
  - API servers stateless
  - Database sharded by user_id
  - Cache layer for frequently accessed data
  - Message queue for async tasks (notifications, analytics)"

6. Trade-off Discussion (10 minutes)

"For timeline generation, we have two approaches:

  Approach A: Push model (precompute on write)
    - Pros: Fast reads
    - Cons: Expensive for users with many followers

  Approach B: Pull model (compute on read)
    - Pros: Simpler, handles followers dynamically
    - Cons: Slower reads, might exceed latency budget

  I'd go with a hybrid: push for normal users, pull for power users."

Key expressions:

• “I would design it like this…”
• “The trade-off is…”
• “For scalability, we could…”
• “Let me walk you through…”

Part 3: Behavioral Questions (STAR Method)

Behavioral questions assess your work style, teamwork, and problem-solving ability. The standard answer framework is STAR:

S (Situation) — Background T (Task) — Your responsibility A (Action) — What you did R (Result) — The outcome

Common Questions and Frameworks

”Tell me about a time you had a disagreement with a teammate"

Situation:
"In my previous role at ByteDance, I was working on a cache layer
optimization. My teammate suggested using Memcached, but I thought
Redis would be better for our use case."

Task:
"We needed to decide which tool to use, and this decision would affect
several other teams."

Action:
"Instead of arguing, I suggested we run a benchmark. We tested both
on our actual workload: 10K concurrent connections, 500MB data set.
Redis was 20% faster and had better persistence options.

I presented the data to my teammate and our tech lead. I also listened
to his concerns about Memcached's simpler operation model."

Result:
"We went with Redis. A month later, it was handling 50K concurrent
requests without issue. My teammate later told me he appreciated how
I approached it with data instead of opinion."

"Describe a technical challenge you solved"

Situation:
"At Alibaba, we had a critical issue: during Singles' Day (our Black Friday),
the payment system was hitting 30-second latencies."

Task:
"As the on-call engineer, I needed to diagnose and fix this without
taking down the system."

Action:
"I did the following:
  1. Checked the metrics dashboard - found that database queries were slow
  2. Profiled a sample of queries - most were table scans on the transactions table
  3. Added missing indexes on the user_id and created_at columns
  4. Also implemented query result caching for recent transactions

I tested the changes in staging first with a load test to simulate
Singles' Day traffic."

Result:
"Latencies dropped to under 200ms. We handled 10x the usual traffic
that day with zero outages. The caching layer prevented 70% of redundant
database hits."

"Tell me about a time you failed”

This question is the easiest to get wrong. The key is showing what you learned from the failure.

Situation:
"I deployed a major refactor on a Friday afternoon (mistake #1).
Didn't get full code review (mistake #2). Assumed the old API
compatibility was maintained (mistake #3)."

Task:
"Users reported errors on Monday morning. I had to roll back and
figure out what went wrong."

Action:
"I:
  - Rolled back immediately (5 min, minimized damage)
  - Did a detailed code review of my changes (found 3 breaking changes)
  - Fixed and tested thoroughly in staging
  - Re-deployed on Tuesday with confidence"

Result:
"We didn't lose any data, but we had 2 hours of downtime. More importantly,
I learned: never deploy major changes on Friday, always get thorough review,
test backward compatibility explicitly.

I later created a pre-deployment checklist for the team."

Caution

Don’t say:

• “I never failed” (unbelievable)
• “It was someone else’s fault” (shifting blame)
• “I don’t remember” (unprepared)

Do say:

• An honest failure story
• Your responsibility
• What you learned

Pre-Interview Preparation Checklist

Technical Preparation (1-2 weeks)

• Review data structures and algorithms (LeetCode medium difficulty)
• Practice 2-3 system design problems (Design Twitter, Design Uber, Design Zoom, etc.)
• Do 3-5 mock interviews (with friends or using Pramp)
• Prepare 5 STAR stories

English Preparation (1 week)

• Record your self-introduction and listen back (check pronunciation and fluency)
• Save common interview expressions to the “interview-prep” tag in DevGlish
• Practice technical term pronunciation (make sure you can clearly say “distributed,” “latency,” etc.)
• Prepare 3-5 “questions for the interviewer”

Common Interview Expression Library

Build a Word Book tag containing these:

Interview Expressions (30+ entries)
  └─ Self introduction
     ├─ "I'm a X engineer with Y years of experience"
     └─ "Most recently, I..."

  └─ Clarification
     ├─ "Let me clarify..."
     ├─ "Could you provide more context on...?"
     └─ "Are we optimizing for X or Y?"

  └─ Technical discussion
     ├─ "I'm thinking about..."
     ├─ "The trade-off is..."
     ├─ "Let me walk you through my approach"
     └─ "Here's why I chose this approach..."

  └─ STAR answers
     ├─ "In my previous role..."
     ├─ "My responsibility was..."
     ├─ "What I learned..."
     └─ "The outcome was..."

  └─ Closing
     ├─ "Do you have any questions for me?"
     ├─ "I'm excited about this opportunity"
     └─ "Thank you for your time"

Mock Interview Flow

Find a friend or use Pramp (free online mock interviews).

Mock interview flow:

1. Self-introduction (3 minutes) — uninterrupted, listen to the full introduction
2. Technical question (45 minutes) — interviewer asks, you answer and code
3. Behavioral questions (10 minutes) — STAR format answers
4. Your questions (5 minutes) — you ask the interviewer questions
5. Feedback (10 minutes) — discuss what went well and areas for improvement

After 3-5 rounds of mock interviews, you’ll feel much more confident.

Interview Day Tips

Language-Related

• Speak slowly — non-native developers tend to speak too fast (nerves). Slow down; clarity is priority
• Think out loud — don’t think silently for 5 minutes. Say “Let me think for a moment…” then share your thoughts
• Perfection isn’t required — accent and minor grammar errors are fine, as long as you’re clear and logical
• Practice pronunciation — pronounce technical terms clearly (distributed ≠ distrubuted)

Mindset

• Nervousness is normal — interviewers know English isn’t your first language and won’t demand perfection
• Ask questions — clarifying what you don’t understand is smart, not a weakness
• Be honest — if you don’t know, say “I’m not sure, but I would…” Don’t make things up

Common Language Mistakes

Mistake	Better
”I think I could do this"	"I can do this"
"The system can be designed like this"	"I would design the system like this"
"There is a database for storing data"	"We store data in a database"
"One approach could be…"	"My approach is…”

After the Interview

• Send a thank-you email (within 24 hours)
• Briefly mention something that impressed you
• Don’t over-explain (the email isn’t for changing the outcome)

Subject: Thank you for the interview

Hi [Name],

Thank you for taking the time to interview me today. I really enjoyed
discussing the system design challenge and learning more about your
backend architecture. The conversation about trade-offs between
consistency and availability was particularly insightful.

I'm excited about the opportunity to contribute to your team.

Best regards,
[Your name]

Tip

Keep practicing. Your 10th interview will be many times more confident than your 1st.