How to Answer 'Tell Me About Yourself' in a Tech Interview (With Examples)

How to Answer "Tell Me About Yourself" in a Tech Interview (With Examples)

You've prepared for algorithmic problems. You've reviewed system design. You have your GitHub ready. And then the interviewer opens with: *"So — tell me about yourself."*

Most developers freeze. Or they recite their LinkedIn like a robot. Or they go on for six minutes and watch the interviewer's eyes glaze over.

This question is not small talk. It is the first filter. The interviewer is deciding, in the next two minutes, whether they want to spend the rest of the hour with you. Your answer sets the tone for everything that follows — it can prime them to trust your judgment, or it can make them skeptical before you've written a single line of pseudocode.

This guide gives you the complete playbook: the structure, the psychology, 40 specific Q&A pairs (many with code or concrete scripts), and the most common mistakes developers from LATAM make when answering in English.

Why This Question Is Harder for LATAM Developers

If you grew up in Argentina, Mexico, Colombia, or anywhere in Latin America, there is a cultural friction here that nobody warns you about.

In most of LATAM, talking about yourself at length — listing your accomplishments, stating your value directly — feels uncomfortable. It reads as arrogant. The culture rewards modesty and collective credit ("we did X"). North American and European interview culture rewards the opposite: direct ownership, specific numbers, clear narrative arc.

That friction, combined with conducting the interview in your second language, means your brain has to do two jobs at once: generate content AND translate it in real time. Under pressure, your retrieval fails. You forget your own best projects. You use filler phrases: *"I worked on many things," "I have experience in many areas."*

The answer to both problems is the same: build and rehearse a structured 90-second script so thoroughly that retrieval is automatic. The content comes out right even when your verbal processor is running at 60%.

The Structure That Works: Present → Past → Future

The formula every interview coach teaches is PPF: Present, Past, Future. It works because it mirrors how humans process narrative — where are you, how did you get there, where are you going.

[Present]   My current role and what I actually do there (2-3 sentences)
[Past]      The 1-2 experiences that built the skills relevant to THIS role (2-3 sentences)
[Future]    Why THIS company and THIS role is the next logical step (1-2 sentences)

Total time: 90 seconds to 2 minutes. Not one word longer unless they follow up.

The Template

"I'm a [role] with [X] years of experience, currently [what you actually do day-to-day at current/last job, with one concrete outcome].

>

Before that, [brief past: what you built or did that's directly relevant to what they need].

>

I'm looking to [what you want next: specific, tied to this company or role], which is why [this company/this role] caught my attention — [one specific, honest reason]."

40 Questions, Detailed Answers, and Real Scripts

PART 1: The Core Answer

Q1. What is the single most important thing to communicate in "tell me about yourself"?

The most important thing is relevance. The interviewer does not need your life story — they need to know that your background connects to their specific problem. Every sentence in your answer should answer the implicit question: *"Why should we keep talking to you?"*

If you are interviewing for a backend role at a fintech startup, your answer should make it obvious that you have built backend systems, that you have worked under constraints that matter to them (latency, consistency, compliance), and that you are genuinely motivated to work in fintech. A sentence about your first WordPress blog from 2014 does not pass that test.

Q2. How long should the answer be?

90 seconds is the target. 2 minutes is the upper limit. Under 60 seconds and you seem unprepared. Over 2 minutes and you are burning time they wanted to use for technical questions — which signals poor communication instincts, a key soft skill for senior roles.

Time yourself when you practice. Out loud, not in your head. Your mental rehearsal runs 30% faster than your spoken delivery.

Q3. Should I start with my name?

No. They know your name — you both just introduced yourselves. Starting with "My name is..." wastes the first sentence, which is the highest-attention moment of your answer.

Start with your role or your most relevant credential:

• "I'm a backend engineer with five years building payment systems..."
• "I've spent the last four years working on data pipelines for e-commerce platforms..."
• "I'm a frontend developer focused on React and performance optimization..."

Q4. What if I am a junior developer with no professional experience?

Your structure shifts from Present → Past → Future to: What you've built → Why you built it → What you want to build next.

Projects replace job history. The key is specificity — not "I built a full-stack app" but "I built a job board with Next.js and Supabase, handling authentication, real-time notifications, and a cron-based job scraper that ingests from 12 ATS sources."

That level of detail signals engineering thinking even without a job title.

Q5. How do I answer this question if I am switching from a different field?

Lead with the transferable value, not the career gap:

"I spent five years as a systems analyst in logistics before moving full-time into engineering. That background means I understand both the technical side and the operational constraints — I've built ETL pipelines for the same systems I used to configure manually. For this role, that means I can work closely with ops and data teams without the translation overhead."

The switch is not the story. What you gained from it is the story.

Q6. Can you give me a complete example for a mid-level backend engineer?

"I'm a backend engineer with four years of experience, currently at a fintech startup in Buenos Aires where I own the payment processing service — we handle about 40,000 transactions a day through a microservices architecture on AWS. I reduced our payment failure rate by 18% last year by rebuilding our retry logic and adding circuit breakers with proper exponential backoff.

>

Before that, I was at an e-commerce company where I built their first event-driven inventory system using Kafka and PostgreSQL. That's where I got serious about distributed systems and observability.

>

I'm looking to work on infrastructure that operates at higher scale and serves a global market. When I saw this role at [Company], the focus on real-time data pipelines and the engineering blog post about your migration to Temporal — that's exactly the kind of problem I want to work on next."

This answer is 2 minutes spoken. It has a concrete outcome, a technical signal, and a specific, honest reason for wanting *this* company.

Q7. What makes an answer sound "junior" even if the candidate is not?

Three things:

1. 1Vague technology lists — "I know Python, JavaScript, React, SQL, AWS, Docker" without any context about what you *built* with them. Listing is weak. Building is strong.

1. 2Passive constructions — "I was part of a team that worked on..." vs. "I built X, which did Y." Own your contributions.

1. 3Ending with uncertainty — "...so yeah, that's basically me." vs. a clear, forward-looking sentence that connects to the role. The last sentence of your answer is what they remember.

Q8. How specific should the technical details be in this answer?

Concrete enough to be credible, not so deep that you lose a non-technical interviewer. The rule: mention one real technical decision or outcome per experience, not a full architecture description.

Good: "I migrated our image processing service from a monolith to Lambda and cut our infrastructure costs by 40%."

Too vague: "I worked on serverless."

Too deep for an intro: "I used Lambda@Edge with CloudFront, configured the regional endpoint routing via Route53 health checks, and wrote a custom CDK construct to manage the deployment pipeline with blue/green rollouts..."

Save the architecture discussion for when they ask follow-up questions. And they will ask, if your intro lands well.

PART 2: Language and Delivery in English

Q9. What are the most common English mistakes LATAM developers make in this answer?

The top five:

1. 1"I have experience in..." — Used correctly but overused. Vary it: "I've spent three years building...", "My background is in...", "I've focused on..."

1. 2"I worked in [Company name]" — Should be "I worked *at* [Company]" or "I worked *for* [Company]." *In* is for locations, not organizations (though you do work *in* a team or *in* a specific area).

1. 3"Actually" as a filler — "Actually, I have experience in React" when you mean "I have experience in React." Remove it.

1. 4Translating "trabajé en muchas cosas" literally as "I worked in many things" or "I have experience in many areas." This signals you can't identify what matters most. Instead, name the one most relevant thing.

1. 5Rising intonation at the end of statements — common in Spanish-influenced English, makes declarative sentences sound like questions. Practice with confidence: "I built the payments service" stated flat, not "I built the payments service?"

Q10. How do I practice the English delivery so it sounds natural, not recited?

Three-step practice protocol:

1. 1Write it out — Draft the exact script in English. Read it ten times silently, fixing anything that feels unnatural.

1. 2Record yourself speaking it — Not typing it, not thinking it. Out loud. Listen back and note where you hedge, trail off, or stumble on specific words.

1. 3Practice recovery, not perfection — Intentionally forget part of your script mid-sentence and keep going. The goal is not to recite without mistakes; it is to stay composed when a mistake happens. Interviewers don't count stumbles. They notice panic.

The tool [InterviewHack](https://interviewhack.ai) has a "Tu historia" drill that does exactly this: it generates your story from your real CV and lets you practice it out loud, with word-by-word feedback on fillers and English interference patterns. It surfaces the exact phrases where your retrieval fails — so you fix those three phrases, not the whole thing.

Q11. How do I handle the transition from Spanish thinking to English output under pressure?

The brain under stress defaults to its stronger language. You cannot prevent that. You can train your English retrieval to be strong enough that it does not collapse under load.

The technique: anchor phrases. Instead of memorizing a full paragraph, memorize your four key anchors — the most important sentence of each section — and improvise the connective tissue around them.

Example anchors for a backend developer:

• *"I'm a backend engineer with four years in fintech."*
• *"My most recent project was a payment retry system that reduced failures by 18%."*
• *"Before that, I rebuilt an inventory system on Kafka."*
• *"I'm here because your work on Temporal caught my attention."*

If you blank out on everything else, those four sentences get you through. The interview can continue from any of them.

Q12. How do I avoid sounding like I'm reading from a script?

The paradox: the more you practice, the more natural it sounds, not less. What sounds rehearsed is when someone *stops mid-sentence*, *backtracks*, or uses unnatural formal register ("I am currently employed as a software development professional").

Practice until the content is automatic, then focus entirely on delivery — eye contact (look at the camera, not the screen), pace (slow down 10% from your instinct), and pauses (a one-second pause after an important sentence sounds confident, not lost).

Q13. Should I use technical jargon in this answer?

Yes, but calibrate to your audience. If you are talking to an engineering manager or a technical recruiter, you can use precise technical terms — they signal you know what you are talking about. If you are in a first HR screen, the terms should be high-level and immediately followed by a plain-English explanation.

Calibration rule: If you say a technical term and get a blank expression, define it in the next sentence without making it awkward: "...we use Kafka — a message broker that handles high-throughput event streams — to..."

PART 3: Tailoring the Answer

Q14. Do I need a different answer for every interview?

Not a completely different answer — a tailored ending. The Present and Past sections stay roughly the same (your history does not change). The Future section, specifically the "why this company" sentence, should be customized for every interview.

This requires thirty seconds of research. Find one specific, genuine thing about the company: a product decision you respect, a technical blog post, a problem in their domain you find interesting. Generic answers ("I'm interested in the growth opportunity") sound unprepared.

Q15. How do I answer "tell me about yourself" for a startup vs. a large company?

Startup: Emphasize ownership, breadth, and speed. Show that you have worked without perfect specifications, shipped things under constraint, worn multiple hats. Use words like "owned," "shipped," "built from scratch."

"I've owned the data pipeline end-to-end at a 15-person startup — ingestion, transformation, dashboards, alerting. There was no data team; there was just me and a lot of ambiguity."

Large company (Google, Meta, Amazon, etc.): Emphasize depth, scale, process, and cross-team impact. Show that you can work within complex systems and influence without authority.

"At [Company], I was on the payments infra team, responsible for the retry framework that served 200M users. I worked closely with three other teams and led the migration from our legacy system with zero downtime."

The same candidate might need both versions in the same job search.

Q16. How do I tailor the answer for a product-focused company vs. a pure engineering one?

Product-focused (consumer apps, B2C): Show that you think about users, not just systems. Include a metric that reflects user impact: "reduced load time from 4s to 1.1s, which improved conversion by 12%."

Engineering-focused (infrastructure, developer tools, platform): Show that you think about systems, reliability, and developer experience. Technical depth matters more here: "we maintained 99.97% uptime across 40 microservices with a 3-engineer SRE team."

Q17. How do I answer this if the role is a step up (I want to get promoted through a new company)?

Name your current level honestly, then bridge to evidence that you are already operating at the next level:

"I'm currently a mid-level engineer, but in the last year I've taken on the tech lead role for our team's biggest migration project — I scoped it, broke it into milestones, unblocked three other engineers, and shipped it three weeks ahead of schedule. I'm looking for a role where that scope of ownership is the expectation, not the exception."

The mistake is claiming the title you want without the evidence. Give the evidence and let them draw the conclusion.

Q18. What if the job description asks for a technology I only know partially?

Be honest and frame it as progression, not deficiency:

"I've been working primarily in Node.js, and I've been building in Go for side projects over the last eight months — I find the concurrency model genuinely interesting. I'm not at production depth in Go yet, but I learn by building real things and I've been intentional about closing that gap."

Do not pretend. Senior engineers can tell within three questions, and the trust damage is worse than the initial gap.

PART 4: Common Mistakes

Q19. What is the most damaging mistake people make answering this question?

Starting with their education history and working forward chronologically. This is the resume read-aloud, and it is the most common mistake.

The interviewer already has your resume. They do not need a summary of it. They need a curated argument for why you are the right person for this specific role. Chronological recitation does not make that argument — it dumps data and asks the interviewer to do the work of connecting it to their needs. Do that work yourself.

Q20. Is it wrong to mention I'm based in LATAM and looking for a remote role?

No. Most companies posting remote roles expect distributed candidates. You do not need to flag it unless it's directly relevant to why you're excited about the company.

What you should avoid: pre-emptively defending your location ("I know I'm in Argentina, but I can work US hours..."). This signals insecurity. If they want to discuss time zones, they will ask. Your value is your work, not your timezone compliance.

Q21. Should I mention why I'm leaving my current job?

Not unless asked. "Tell me about yourself" is about who you are and what you bring, not about why you are leaving somewhere else. If they ask "why are you looking?" as a follow-up, answer it directly and without bitterness. Never criticize your current employer.

Q22. What if I have a gap in my work history?

Do not hide it, but do not lead with it. If the gap is relevant (you built a product, freelanced, did a bootcamp, took care of a family member), mention it briefly in the Past section. If it is not relevant, the answer is the same as always — lead with what you did, not what you did not do.

If they ask directly: "I took eight months off to [reason]. During that time I [what you actually did that is relevant]. I'm ready to be back at full capacity and specifically looking for [X]."

Q23. How do I avoid the "I'm a hard worker and fast learner" trap?

These phrases are so common they have lost all meaning. "I'm a fast learner" signals nothing because every candidate says it. The only replacement is evidence:

Weak: "I'm a fast learner with strong problem-solving skills."

Strong: "When I joined my last company, I had three days to get familiar with a Go codebase before shipping a critical bug fix. I shipped it on day four. Since then, Go has been my primary language."

The story makes the claim. The claim does not make the claim.

Q24. How do I handle the question when I have 10+ years of experience and don't want to ramble?

The problem with senior candidates is usually too much history, not too little. The discipline is ruthless selection: which two experiences are most relevant to this role, and everything else gets one sentence or nothing.

"I've been in engineering for twelve years, most recently as a principal engineer at [Company] where I owned the developer platform serving 300 internal engineers. Before that, I spent six years building payment infrastructure at two different fintechs. For this role, the combination of platform thinking and financial systems experience is what I think I bring that's distinctive."

Twelve years in three sentences. The depth comes out in the questions.

PART 5: Advanced Techniques

Q25. How do I use this answer to steer the rest of the interview toward my strengths?

This is the most underused technique. Your answer seeds the conversation. If you mention a specific project, the interviewer will often ask about it. If you mention a metric, they will probe how you got there. If you mention a technical decision, they will ask you to defend it.

This means you can strategically mention the experiences you are most prepared to discuss in depth.

If you have a great story about rebuilding a legacy system (strong architecture discussion, clear technical decisions, measurable outcome), mention it in your intro. If you have a weak spot in, say, database optimization, do not bring databases up in your intro — there will be time for that if they choose to probe it.

This is not manipulation. It is good communication: lead with your strongest material.

Q26. How does the answer change for a coding-heavy interview vs. a system design interview?

Coding-heavy: Emphasize your problem-solving approach and concrete examples of shipping production code. You can briefly mention an algorithmic challenge you enjoyed solving — it signals you are not dreading what is coming.

System design: Emphasize systems you have built at scale, architectural decisions you have made, and your ability to think about tradeoffs. The words that matter: scale, reliability, tradeoffs, constraints, teams.

The core answer does not change — the technical signal in each experience description shifts emphasis.

Q27. How do I answer "tell me about yourself" in a panel interview with multiple interviewers?

Make eye contact with the person who asked the question for the first sentence, then distribute eye contact across the panel as you continue. Finish the answer looking at the original asker.

Do not tailor different parts to different panelists mid-answer — it reads as performative. Give one coherent answer. They will each ask the follow-ups relevant to their area.

Q28. What if my most impressive work is under NDA?

You can describe the nature of the problem and your approach without naming the client or revealing proprietary details:

"I worked on a data pipeline for a major US bank — I can't name them — processing about 80 million events per day. The challenge was..."

Interviewers understand NDAs. They will not push for the client name if you are honest about the constraint. What matters is the technical substance.

Q29. How do I answer this question for an internal transfer?

Internal interviews are not the same as external ones. You have context they do not have to infer. Use it:

"In my current role on the platform team, I've been the main driver behind [X]. What I've learned from two years working with the infra team is that [specific insight]. I'm applying for this role because [specific reason tied to the team's current roadmap]."

Show that you have done your homework on the other team's problems, not just your own accomplishments.

Q30. What if I genuinely don't know what to say — my experience feels unremarkable to me?

The Ikea effect: you undervalue your own work because you were inside it while it was happening. The things that felt ordinary to you — learning a new stack under deadline, debugging a production incident at 2am, mentoring a junior engineer — are specific, concrete experiences that most candidates cannot describe as clearly.

The fix: write down your last three projects and answer these three questions for each:

1. 1What was the hardest technical decision I made?
2. 2What broke, and how did I fix it?
3. 3What is different about the system now compared to when I found it?

One of those answers will become the core of your "tell me about yourself."

PART 6: Full Example Scripts by Persona

Q31. Full script: Junior developer, first job, CS degree, portfolio projects

"I recently finished my computer science degree, and over the last year I've been building projects to apply what I studied. My most substantial one is a recipe recommendation app — I built the backend in FastAPI with a PostgreSQL database, deployed it on a VPS, and added a recommendation engine using collaborative filtering. About 200 people use it weekly.

>

Before that project, I interned for four months at a small SaaS company, where I worked on their test suite and fixed a long-standing N+1 query problem that was slowing down their dashboard.

>

I'm looking for a junior backend role where I can work on real production systems with mentorship. I applied here because I've followed your engineering blog and the depth of your technical writing tells me the team takes engineering quality seriously."

Q32. Full script: 3 years experience, frontend, React specialist

"I'm a frontend engineer with three years focused on React and performance optimization. Currently at a B2B SaaS company, where I rebuilt our dashboard from a class-components React 16 codebase to modern React with hooks, React Query, and TypeScript — we cut initial load time by 55% and the team's developer velocity improved noticeably because the new architecture is much easier to test.

>

Before that, I was at an agency building client-facing applications, which taught me to move fast and communicate technical constraints to non-technical stakeholders.

>

I want to go deeper on complex product surfaces and work with a design-engineering collaboration that takes UI seriously. The demo I saw of your product's custom visualization layer made me genuinely curious about how you built it."

Q33. Full script: 6 years, backend/infrastructure, wants to move to a US company

"I'm a backend engineer with six years of experience, currently leading a team of three at a fintech in Bogotá. We handle payment reconciliation for about 150 partner banks, and the system I designed processes about 2 million transactions daily across multiple currencies.

>

Before this role, I spent three years at an e-commerce company where I led the migration from a monolithic PHP codebase to a microservices architecture on AWS — that project ran 18 months and is probably where I learned the most about distributed systems tradeoffs, because we got some of them wrong the first time.

>

I'm specifically looking for a US or European remote role now. The engineering scale and the team standards are what pull me — and from what I've seen of [Company]'s technical challenges, the complexity of the problem matches the level I want to be working at."

Q34. Full script: Senior engineer applying for a staff/principal role

"I'm a senior engineer with eight years of experience, most recently at [Company] as a tech lead for the search infrastructure team — we served 40 million queries per day and I led the team through a re-architecture that improved p99 latency from 340ms to 90ms.

>

My background before that was mostly in data systems — I built and maintained real-time analytics pipelines at two startups, which gave me the habit of thinking about systems end-to-end, not just at the component level.

>

I'm looking for a staff-level role where the expectation is cross-team technical influence, not just deep technical execution. I want to work on problems where the architecture decisions have multi-year consequences. What draws me to [Company] is that the scale of your data infrastructure is genuinely hard — I've read three of your eng blog posts and I have opinions about two of them."

Q35. Full script: Career changer — former data analyst, now backend engineer

"I spent four years as a data analyst before moving fully into engineering. That means I spent years writing complex SQL, building ETL pipelines, and understanding what the data layer looks like from the consumer side before I knew how to build the systems feeding it.

>

For the last two years, I've been a backend engineer at a data platform company, building the ingest and transformation APIs that our analyst customers use. That hybrid background is genuinely useful — I understand what analysts need from a system because I used to be one, and I don't build APIs that look good technically but are painful to query.

>

I'm looking for a role on a data-adjacent platform team. The intersection of engineering quality and data usability is where I do my best work."

PART 7: Practicing With Code

The following section is unconventional for a soft-skills guide, but LATAM developers often want to apply engineering discipline to interview prep. Here is how to do that.

Q36. How do I build a structured practice system for this answer?

Treat it like debugging. You have a function (your answer) and you want to find where it fails under load.

// Conceptual model of what you are building
type AnswerScript = {
  present: string;   // 2-3 sentences, current role + outcome
  past: string;      // 2-3 sentences, most relevant prior experience
  future: string;    // 1-2 sentences, why this company/role
};

type PracticeSession = {
  script: AnswerScript;
  targetCompany: string;
  interviewerType: "technical" | "hr" | "hiring-manager" | "panel";
  recordedDurationSeconds: number;
  fillerWordCount: number;
  notes: string;
};

Run at least five recorded practice sessions before any real interview. Review the recording for:

• Duration (target: 90-120 seconds)
• Filler words ("um," "like," "basically," "actually," "you know")
• Sentences that trail off without a clear ending
• Monotone delivery — vary your pace on the key outcome sentences

Q37. Can you show a Python script to help time and structure practice sessions?

Yes. This is a minimal CLI tool to pace yourself:

import time
import sys

def run_practice_timer(sections: list[str], seconds_each: int = 30):
    """
    Walk through your answer sections with a timer.
    sections: list of your key sentences/anchors
    seconds_each: target time per section
    """
    print("\n=== TELL ME ABOUT YOURSELF — PRACTICE TIMER ===\n")
    for i, section in enumerate(sections, 1):
        print(f"SECTION {i}: {section}")
        print(f"You have {seconds_each} seconds. Press ENTER when done.\n")
        start = time.time()
        input()
        elapsed = time.time() - start
        if elapsed < seconds_each * 0.7:
            print(f"  Too fast ({elapsed:.0f}s). Slow down and add detail.\n")
        elif elapsed > seconds_each * 1.4:
            print(f"  Too long ({elapsed:.0f}s). Cut the least important sentence.\n")
        else:
            print(f"  Good ({elapsed:.0f}s).\n")
    print("=== SESSION COMPLETE ===")

# Your actual anchors — customize these
anchors = [
    "[Present] Current role + one concrete outcome",
    "[Past] Most relevant prior experience + what you learned",
    "[Future] Why this company + one specific reason",
]

run_practice_timer(anchors, seconds_each=35)

Run this daily for a week before interviews. You will internalize the pacing without needing to count in your head during the real thing.

Q38. How do I use the interviewhack.ai "Tu historia" feature to practice this specific answer?

The "Tu historia" feature builds your story directly from your CV or LinkedIn profile — so every detail it generates is grounded in your actual experience, not generic filler. This matters because the most common failure mode is forgetting your own best material under pressure.

The workflow:

1. 1Upload your CV or connect LinkedIn in /dashboard/cv
2. 2Open "Tu historia" (pinned first in your interview list on the dashboard)
3. 3The system generates your structured narrative from your real experience
4. 4Practice it out loud using the voice drill — it runs timed rounds with decreasing support (full text → hints → blank)
5. 5After each round, review the feedback: which filler words came up, which transitions felt weak, which sections ran long

The drill uses the same 4-3-2 fluency methodology from language acquisition research: you speak the full answer with support in 4 minutes, then compress it to 3 minutes with less support, then 2 minutes with minimal cues. By the third pass, retrieval is significantly faster.

Q39. What is the "retrieval failure" problem and how does practice fix it?

When you prepare an answer by reading and rereading it, you are building recognition memory — you can recognize the answer when you see it. But interviews test recall memory — you need to produce the answer from nothing, under stress, in a second language.

The fix is retrieval practice: forcing yourself to recall the answer without looking at it, repeatedly, with feedback. Every time you successfully retrieve a piece of information, the memory trace gets stronger. Every time you fail to retrieve it and then see the correct answer, the trace also strengthens (more than if you had not failed).

This is why reading your notes ten times before an interview is less effective than practicing retrieval three times.

# Simplified spaced repetition model for interview anchors
import random
from datetime import datetime, timedelta

class AnchorCard:
    def __init__(self, anchor: str, example: str):
        self.anchor = anchor
        self.example = example
        self.due = datetime.now()
        self.interval_days = 1
        self.ease = 2.5

    def review(self, quality: int):
        """
        quality: 0 (failed) to 5 (perfect)
        Updates interval using SM-2 algorithm variant
        """
        if quality < 3:
            self.interval_days = 1
            self.ease = max(1.3, self.ease - 0.2)
        else:
            self.interval_days = round(self.interval_days * self.ease)
            self.ease = self.ease + 0.1 - (5 - quality) * 0.08
        self.due = datetime.now() + timedelta(days=self.interval_days)

# Your actual cards — replace with your real anchors and examples
cards = [
    AnchorCard(
        anchor="Current role + outcome",
        example="Backend engineer at Fintech Co, rebuilt payment retry logic, reduced failures 18%"
    ),
    AnchorCard(
        anchor="Key past experience",
        example="Built Kafka-based inventory system at e-commerce company, owned it end-to-end"
    ),
    AnchorCard(
        anchor="Why this company",
        example="Read your Temporal migration post — want to work on that class of problem"
    ),
]

Q40. What is the one thing I should do tonight if my interview is tomorrow?

One thing: record yourself giving the answer out loud, watch it back once, fix the one weakest sentence, then stop. Do not over-rehearse the night before. Over-rehearsal creates a different problem — you start monitoring your own delivery while speaking, which consumes working memory and makes you sound more robotic, not less.

The goal by interview day is for the content to be on autopilot so your conscious attention can focus on reading the room, adjusting your pace to the interviewer's reactions, and listening carefully to their follow-up questions.

The answer is not your performance. It is the beginning of a conversation. Treat it that way.

Quick Reference Checklist

Use this before every interview:

• The answer is 90-120 seconds, timed
• It starts with your current role or strongest credential, not your name or education
• Each section (Present / Past / Future) is one to three sentences
• At least one section contains a concrete outcome with a number or a named technical decision
• The "why this company" sentence is specific to this company, written for this interview
• You have practiced it out loud at least three times in the last 48 hours
• You know which project you want them to ask about, and you mentioned it

What Comes Next

"Tell me about yourself" is not the hardest question in a tech interview. But it is the one that determines whether the interviewer is rooting for you or neutral toward you for the next hour. Get it right and every subsequent question feels like a conversation. Get it wrong and you spend the rest of the interview recovering.

The path is straightforward: build the script from your real experience, practice retrieval (not recognition), calibrate the technical signal to the role, and customize the ending for every company.

If you want to build this from your actual CV — not a generic template — and drill it in voice until it comes out automatically under pressure, [try InterviewHack](https://interviewhack.ai). The "Tu historia" feature generates your structured story from your real experience and runs timed voice drills with feedback on filler words and English interference patterns. It's free, no card required.