Entrevista técnica en inglés: frases, estrategias y cómo practicar
Si conseguiste una entrevista en inglés para un trabajo remoto que paga en dólares, lo primero que sentís no es alegría: es pánico. Sabés la respuesta. Te la sabés de memoria. Pero en inglés, bajo presión, el retrieval falla — se te va el vocabulario, usás muletillas en castellano ("como que", "digamos"), y cuando querés explicar algo técnico te quedás en blanco.
Este artículo no es un glosario de frases bonitas. Es una guía práctica para alguien que tiene nivel intermedio de inglés (B1/B2) y necesita clavar una entrevista técnica real, con ejemplos de código, frases que suenan naturales, y un sistema de práctica que funciona.
Por qué el inglés técnico de entrevista es diferente al inglés "del trabajo"
Hay una diferencia enorme entre escribir en inglés (Slack, emails, pull requests) y hablar en inglés bajo presión. En la escritura tenés tiempo. En la entrevista no.
El cerebro opera distinto en el segundo idioma: la generación de palabras consume ciclos de CPU que en tu idioma nativo van a pensar la respuesta. El resultado: silencios largos, respuestas cortas, o peor, respuestas confusas porque usaste la primera palabra que te vino en lugar de la correcta.
La solución no es estudiar más vocabulario. Es practicar las respuestas en voz alta, en inglés, repetidamente, hasta que el chunk correcto se recupere solo.
Las 5 frases de apertura que comprás tiempo sin sonar raro
El silencio incómodo después de una pregunta es peor que una pausa breve con una frase puente. Estos son los conectores que usan los nativos para ganar 3-5 segundos:
- "That's a great question — let me think for a second." (No abuses, máx 1 vez por entrevista)
- "Sure, so the way I think about this is…" (Excelente para arrancar cualquier respuesta técnica)
- "Good point. In my experience…" (Para preguntas de comportamiento)
- "Yeah, so at a high level…" (Para diseño de sistemas o arquitectura)
- "Let me walk you through my approach." (Para coding live o take-homes)
Estas frases tienen dos funciones: te dan tiempo para pensar Y señalizan al entrevistador que estás procesando con propósito, no que te perdiste.
Frases técnicas esenciales por categoría
Para explicar decisiones de diseño
- "I went with X because it gives us better Y in the long run."
- "The trade-off here is Z, but for this use case it made sense."
- "I considered X but ruled it out because of Y."
- "The bottleneck in this approach would be…"
- "If I had more time, I'd also look into…"
Para código y algoritmos
- "Let me start with a brute-force approach and then optimize."
- "The time complexity here is O(n log n) because of the sort."
- "I'm going to use a hash map to bring this down to O(n)."
- "This edge case would break the naive solution, so I'll handle it by…"
- "Let me trace through an example to make sure this is correct."
Para preguntas de comportamiento (STAR en inglés)
- "So the situation was…"
- "My task was to…"
- "What I did was…"
- "The result was…, and the takeaway for me was…"
Para pedir aclaraciones (sin sonar inseguro)
- "Just to make sure I understand — are you asking about X or Y?"
- "Can I ask one quick clarifying question before I dive in?"
- "Is this a latency-sensitive system, or are we optimizing for cost?"
- "Should I consider the mobile client as well, or just the backend?"
40 preguntas numeradas con respuestas detalladas y código real
SECCIÓN 1: Behavioral (comportamiento) — en inglés con STAR
1. Tell me about yourself.
Esta pregunta no es un CV en voz alta. Es un pitch de 60-90 segundos que conecta tu pasado con el rol actual.
*Estructura:* Presente → Pasado → Por qué esta empresa.
*Ejemplo:*
"I'm a full-stack developer based in Buenos Aires, currently working at [empresa], where I focus mainly on our API layer — Node.js, PostgreSQL, some Redis for caching. Before that I spent two years doing frontend work with React, which gives me context on both sides of the stack. The reason I'm excited about this role specifically is [razón concreta relacionada con la empresa]."
*Error frecuente de LATAM:* empezar con "I am originally from…" — al entrevistador no le importa tu historia personal, le importa tu fit técnico.
2. Why do you want to leave your current job?
Nunca hables mal de tu empresa actual. Las respuestas que funcionan se enfocan en crecimiento:
"I've learned a lot at [empresa actual], especially around [skill específico]. I'm at a point where I want to work on problems at a larger scale / in a distributed team / with [tecnología del nuevo rol], and this position offers exactly that."
*Frase que matar:* "My current company doesn't appreciate me." — aunque sea verdad, jamás.
3. Describe a time you had a disagreement with a coworker.
El entrevistador quiere saber si podés manejar conflicto sin drama. Usá STAR y terminá con el learning.
*Ejemplo:*
"Situation: We were deciding between two database schemas for a new feature. My tech lead wanted a single denormalized table for simplicity; I thought normalization would save us pain down the road. Task: We needed to reach a decision fast — the sprint was already in progress. Action: I put together a short doc with both approaches, estimated the migration cost if we had to change later, and proposed we run a quick prototype on each. Result: We went with the normalized schema; six months later we needed exactly the kind of query that would've been painful the other way. The takeaway for me was that a short written comparison is faster than a long verbal debate."
4. Tell me about a time you failed.
La trampa: hablar de algo menor ("I was 5 minutes late once"). El entrevistador quiere ver autoconciencia real.
"We shipped a feature without adequate load testing. Under normal traffic it was fine, but during a promotional event it caused a 20-minute outage. I was the engineer on call and had to roll back while under pressure. After that I personally set up load tests in our CI pipeline and wrote a post-mortem that the whole team used as a template for future incidents."
5. How do you prioritize when you have multiple deadlines?
"I use a simple framework: impact vs. effort. High-impact, low-effort things go first. Then I communicate early — if something is going to be late, I'd rather flag it three days in advance than the day before. I also break large tasks into daily checkpoints so I can spot blockers before they become emergencies."
6. Where do you see yourself in 5 years?
No inventés un plan falso. Respondé con honestidad sobre la dirección, no el destino exacto:
"Honestly, I don't have a rigid 5-year plan, but the direction is clear: I want to get deeper into distributed systems and eventually lead a small team technically — not managing people, but being the person who makes architectural calls and mentors junior engineers. I think a role like this one is a good next step toward that."
7. What's your biggest weakness?
La respuesta buena tiene tres partes: el problema real + qué hiciste + evidencia de mejora.
"I used to take on too much and underestimate timelines. I got burned on a project that was late because I agreed to three parallel workstreams. Since then I default to saying 'let me check my current load before I commit' before adding anything to my plate. It's changed how my team sees me — more predictable, less last-minute fire drills."
8. Why do you want to work here specifically?
Investigá la empresa 20 minutos antes. Mencioná algo concreto:
"I saw that your team recently open-sourced [proyecto] — I spent an afternoon reading through the code and was impressed by how you handled [aspecto técnico]. That kind of thoughtfulness in public work usually reflects the internal culture too."
SECCIÓN 2: Algoritmos y estructuras de datos
9. What's the difference between a stack and a queue?
"A stack is LIFO — last in, first out. Think of a call stack: the last function you called is the first to return. A queue is FIFO — first in, first out. Think of a job queue: tasks get processed in order of arrival."
*Código:*
# Stack — usá una lista en Python
stack = []
stack.append(1) # push
stack.append(2)
top = stack.pop() # pop → 2
# Queue — usá collections.deque para O(1) en ambos extremos
from collections import deque
queue = deque()
queue.append(1) # enqueue
queue.append(2)
first = queue.popleft() # dequeue → 110. How would you detect a cycle in a linked list?
La respuesta esperada es Floyd's algorithm (two pointers):
"I'd use two pointers — a slow one that moves one step at a time and a fast one that moves two. If there's a cycle, they'll eventually meet. If fast reaches null, there's no cycle. Time O(n), space O(1)."
def has_cycle(head):
slow, fast = head, head
while fast and fast.next:
slow = slow.next
fast = fast.next.next
if slow is fast:
return True
return False11. Explain Big O notation in simple terms.
"Big O describes how an algorithm's performance scales with input size. O(1) means constant — doesn't matter if you have 10 or 10 million items, it takes the same time. O(n) means linear — twice the input, twice the time. O(n²) means quadratic — common with nested loops over the same array, which is why you want to spot those in code review."
12. What's the difference between BFS and DFS?
"BFS — breadth-first search — explores layer by layer using a queue. It finds the shortest path in unweighted graphs. DFS — depth-first search — goes as deep as possible before backtracking, using a stack (or recursion). DFS is simpler to implement and uses less memory for deep trees; BFS is better when you want the shortest path."
from collections import deque
def bfs(graph, start):
visited = set()
queue = deque([start])
while queue:
node = queue.popleft()
if node not in visited:
visited.add(node)
queue.extend(graph[node])
return visited
def dfs(graph, start, visited=None):
if visited is None:
visited = set()
visited.add(start)
for neighbor in graph[start]:
if neighbor not in visited:
dfs(graph, neighbor, visited)
return visited13. How do you find the two numbers in an array that sum to a target?
La respuesta naive es O(n²). La buena es O(n) con hash:
def two_sum(nums, target):
seen = {}
for i, num in enumerate(nums):
complement = target - num
if complement in seen:
return [seen[complement], i]
seen[num] = i
return []"I store each number and its index in a hash map as I iterate. For each number I check if its complement is already in the map. One pass, O(n) time, O(n) space."
14. What is dynamic programming? Give a real example.
"DP is about breaking a problem into overlapping subproblems and storing the results so you don't recompute them. The classic example is Fibonacci: the naive recursive version recomputes the same values over and over. With memoization you store each result once."
# O(2^n) naive
def fib_naive(n):
if n <= 1: return n
return fib_naive(n-1) + fib_naive(n-2)
# O(n) with memoization
from functools import lru_cache
@lru_cache(maxsize=None)
def fib(n):
if n <= 1: return n
return fib(n-1) + fib(n-2)15. How would you reverse a string in place?
def reverse_string(s: list) -> None:
left, right = 0, len(s) - 1
while left < right:
s[left], s[right] = s[right], s[left]
left += 1
right -= 1"I use two pointers from each end, swapping until they meet in the middle. O(n) time, O(1) space since I'm modifying in place."
SECCIÓN 3: JavaScript / TypeScript
16. What's the difference between var, let, and const?
"varis function-scoped and gets hoisted — this causes subtle bugs.letandconstare block-scoped, which is what you almost always want.constdoesn't mean immutable for objects — it means the reference can't be reassigned, but the object's properties can still change."
var x = 1;
if (true) { var x = 2; }
console.log(x); // 2 — same variable!
let y = 1;
if (true) { let y = 2; }
console.log(y); // 1 — different variable
const obj = { a: 1 };
obj.a = 2; // OK — mutating the object
obj = {}; // TypeError — can't reassign the reference17. Explain event delegation.
"Event delegation means attaching one listener to a parent instead of individual listeners to each child. When an event fires on a child, it bubbles up to the parent. This is more efficient (fewer listeners) and works for dynamically added elements."
// Instead of this (n listeners):
document.querySelectorAll('.btn').forEach(btn =>
btn.addEventListener('click', handleClick)
);
// Do this (1 listener):
document.getElementById('container').addEventListener('click', (e) => {
if (e.target.classList.contains('btn')) {
handleClick(e);
}
});18. What is a closure?
"A closure is a function that remembers the variables from its outer scope, even after that outer function has returned."
function makeCounter() {
let count = 0; // lives in the outer scope
return function() { // this function closes over `count`
return ++count;
};
}
const counter = makeCounter();
console.log(counter()); // 1
console.log(counter()); // 2
// `count` is still alive, held by the closure19. What's the difference between == and ===?
"==does type coercion — it converts the operands to the same type before comparing.===is strict — no coercion. Always use===unless you have a specific reason for the coercion."
0 == false // true (type coercion)
0 === false // false (different types)
'' == false // true
'' === false // false
null == undefined // true
null === undefined // false20. Explain async/await versus Promises.
"async/awaitis syntactic sugar over Promises. A function markedasyncalways returns a Promise.awaitpauses execution inside that function until the Promise resolves. It makes asynchronous code read like synchronous code, which is much easier to reason about."
// Promise chain
fetch('/api/user')
.then(r => r.json())
.then(user => console.log(user))
.catch(err => console.error(err));
// async/await — same thing, more readable
async function getUser() {
try {
const r = await fetch('/api/user');
const user = await r.json();
console.log(user);
} catch (err) {
console.error(err);
}
}SECCIÓN 4: React / Frontend
21. What's the difference between useEffect and useLayoutEffect?
"useEffectruns asynchronously after the browser has painted.useLayoutEffectruns synchronously after the DOM mutation but before the browser paints. UseuseLayoutEffectonly when you need to read layout (like measuring a DOM node) to avoid a visual flash — for everything else,useEffect."
22. Explain React's reconciliation algorithm.
"React builds a virtual DOM — a lightweight in-memory representation of the actual DOM. When state or props change, it creates a new virtual DOM and diffs it against the previous one (reconciliation). Only the actual changes get applied to the real DOM, which is expensive. Key props help React identify list items across renders without tearing down and rebuilding them."
23. What is prop drilling and how do you solve it?
"Prop drilling is when you pass data through multiple layers of components just to get it to a deeply nested child. The solutions: React Context for read-often data like theme or auth; a state manager like Zustand for complex shared state; or component composition (render props, children) to avoid the intermediate layers altogether."
24. When would you use useMemo and useCallback?
"useMemomemoizes the result of an expensive computation.useCallbackmemoizes a function reference. Use them when you can measure a performance problem — not preemptively. The common case:useCallbackto stabilize a callback passed to aReact.memo-wrapped child component so it doesn't re-render unnecessarily."
const sortedList = useMemo(
() => items.sort((a, b) => a.name.localeCompare(b.name)),
[items] // only re-sort when items changes
);
const handleClick = useCallback(() => {
onSelect(item.id);
}, [item.id, onSelect]);SECCIÓN 5: Backend, APIs y bases de datos
25. What's the difference between SQL and NoSQL? When would you use each?
"SQL databases are relational — data is structured in tables with defined schemas, and they support complex queries and ACID transactions. Good for financial data, user accounts, anything where consistency is critical. NoSQL covers many models — document (MongoDB), key-value (Redis), column-family (Cassandra). They trade consistency guarantees for flexibility and horizontal scale. I'd use NoSQL for high-write, schema-flexible data like analytics events or session storage; SQL for anything where the relationships between entities matter."
26. Explain the N+1 query problem.
"N+1 happens when you fetch N records and then fire one additional query per record. Example: fetch 100 users, then loop and query each user's profile separately — that's 101 queries instead of 2."
// N+1 — bad
const users = await db.query('SELECT * FROM users');
for (const user of users) {
user.profile = await db.query(
'SELECT * FROM profiles WHERE user_id = $1', [user.id]
);
}
// Fix with a JOIN — 1 query
const users = await db.query(`
SELECT u.*, p.bio, p.avatar
FROM users u
LEFT JOIN profiles p ON p.user_id = u.id
`);27. What is an index in a database and when would you add one?
"An index is a data structure (usually a B-tree) that lets the database find rows without scanning the whole table. Add an index on columns you filter or sort by frequently — foreign keys, email lookups, date ranges. The cost: indexes slow down writes because they need to be updated, and they use disk space. Don't index every column — profile first with EXPLAIN ANALYZE."
28. Explain REST vs GraphQL trade-offs.
"REST is resource-based — each endpoint maps to a resource. It's simple, cacheable (HTTP caching works naturally), and well-understood. The downside: over-fetching (you get the whole user object when you only needed the name) or under-fetching (N+1 at the HTTP level for related data). GraphQL lets clients request exactly the data they need in one round trip. The cost: more complex caching, server-side N+1 if you don't use DataLoader, and a learning curve for teams used to REST."
29. What happens between the browser and server in an HTTPS request?
"The browser does a DNS lookup to get the IP. Then it opens a TCP connection (3-way handshake). For HTTPS, it does a TLS handshake — the server sends its certificate, the client verifies it against a CA, they agree on a cipher and exchange keys. Then the encrypted HTTP request is sent. The server processes it and sends back a response. For subsequent requests to the same origin, TLS resumption skips most of the handshake."
30. Explain database transactions and ACID.
"A transaction is a unit of work that either completes fully or not at all. ACID: Atomicity — all or nothing; Consistency — each transaction takes the DB from one valid state to another; Isolation — concurrent transactions don't interfere with each other; Durability — once committed, data survives a crash. These are guaranteed by SQL databases; most NoSQL systems relax one or more (usually isolation) for performance."
SECCIÓN 6: Sistema, arquitectura y DevOps
31. What is a load balancer and when do you need one?
"A load balancer distributes incoming traffic across multiple server instances. You need one when a single server can't handle the request volume, or for redundancy — if one instance goes down, traffic goes to the rest. Common algorithms: round-robin (simple), least connections (smarter), consistent hashing (for stateful services or caches)."
32. Explain horizontal vs vertical scaling.
"Vertical scaling is making the same machine bigger — more CPU, more RAM. It has a ceiling and there's downtime for the upgrade. Horizontal scaling is adding more machines. It's effectively unlimited and gives you fault tolerance, but it requires your application to be stateless (or use distributed state management). Most modern architectures prefer horizontal."
33. What is a message queue and when would you use one?
"A message queue decouples services — the producer sends a message and moves on; the consumer processes it at its own pace. Use cases: background jobs (sending emails, processing images), smoothing traffic spikes, communication between microservices where you don't need a synchronous response. Common options: SQS (AWS), RabbitMQ, Kafka (for high-throughput event streaming)."
34. What is Docker and why do developers use it?
"Docker packages an application with all its dependencies — runtime, libraries, config — into a container. The container runs the same way on any machine. This eliminates 'works on my machine' problems and makes deployments predictable. Kubernetes orchestrates containers at scale — scheduling them, restarting them if they crash, scaling them up and down."
35. Explain CI/CD.
"CI — Continuous Integration — means every code push automatically runs tests and builds the project. You catch broken builds in minutes, not days. CD — Continuous Deployment — means a passing build automatically deploys to an environment. For production deployments, most teams add a manual approval step (that's Continuous Delivery vs Deployment). The goal is to make releases boring — small, frequent, and reversible."
SECCIÓN 7: Preguntas de system design
36. Design a URL shortener (like bit.ly).
Esta es una pregunta de diseño abierto. El entrevistador espera que guiés la conversación.
*Tu apertura:*
"Before I dive in, can I ask a few clarifying questions? What's the expected QPS? Do we need analytics on each link? Does the shortened URL need to be human-readable or is random fine?"
*Estructura de respuesta:*
"At a high level: the user POSTs a long URL, we generate a short code (6 chars base62 gives us 56 billion combinations), store the mapping in a database, and redirect on GET. For scale: reads vastly outnumber writes, so we cache the most popular redirects in Redis. For generation I'd use a counter in the DB plus base62 encoding — avoids collisions without UUIDs. The main table is simple: id, short_code, long_url, created_at, user_id."37. Design a notification system.
"I'd start by separating sending from tracking. A producer service accepts notification requests and pushes them to a queue (SQS or Kafka). Consumer workers pull from the queue, route to the right channel (email, push, SMS) via the appropriate provider (Resend, FCM, Twilio), and write the result to anotificationstable. Failed deliveries go to a dead-letter queue for retry with backoff. For scale: consumers are stateless and horizontally scalable. For preference management: auser_notification_preferencestable that consumers check before sending."
38. How would you design a rate limiter?
"The classic approach is a sliding window or token bucket in Redis. For token bucket: each user key has a counter and a timestamp. On each request, refill tokens based on elapsed time, then check if there's a token to spend. Redis is the right backend because it's fast and supports atomic Lua scripts — you need atomicity to avoid race conditions between the check and the decrement."
import redis
import time
r = redis.Redis()
def is_allowed(user_id: str, limit: int = 100, window: int = 60) -> bool:
key = f"rate:{user_id}"
now = time.time()
pipe = r.pipeline()
pipe.zremrangebyscore(key, 0, now - window) # remove old entries
pipe.zadd(key, {str(now): now}) # add current request
pipe.zcard(key) # count requests in window
pipe.expire(key, window)
results = pipe.execute()
return results[2] <= limitSECCIÓN 8: Preguntas de fit cultural y situacionales
39. How do you handle feedback you disagree with?
"I try to separate the emotional reaction from the content. My first move is to ask clarifying questions — 'Can you help me understand what specifically didn't land?' Sometimes the feedback is correct and I was too close to the work to see it. If after understanding I still disagree, I'll state my perspective once, clearly, with data if I have it. Then I defer to whoever owns the decision — disagreement doesn't mean you have to obstruct."
40. Tell me about a project you're proud of and why.
*Estructura:* contexto técnico + decisión no obvia + resultado medible + aprendizaje.
"I built a pipeline that synced inventory in real time between a legacy ERP and a new e-commerce platform. The tricky part was the ERP only supported polling, not webhooks, and it was slow — a full sync took 40 minutes. I implemented a delta-based approach: instead of fetching everything, I tracked change timestamps and fetched only modified records. Sync time dropped to under 2 minutes, which meant the catalog was actually fresh by the time a customer searched. The lesson: before you optimize the algorithm, understand the data access pattern."
41. How do you stay up to date with technology?
Una respuesta honesta, no una lista de recursos famosos:
"I follow a small number of high-signal sources rather than trying to read everything — [Hacker News](https://news.ycombinator.com/) for what the industry is talking about, the changelog of the tools I actually use day-to-day, and a couple of people on Twitter whose judgment I trust. When something new comes up in a project, I go deep on that specific thing. I find that building something small with a new technology is worth more than reading five articles about it."
42. What do you do when you're stuck on a bug for too long?
"After about 30 minutes of no progress, I force myself to explain the problem out loud — rubber duck debugging. If that doesn't work, I step away for 10-15 minutes. Fresh eyes catch things a tired brain misses. After an hour I ask a colleague, but I prepare: I describe what I tried, what I expected, and what actually happened — that framing usually surfaces the answer before I even finish explaining."
43. How do you approach code review — as an author and as a reviewer?
*Como autor:*
"I review my own diff before requesting review — I catch 30% of the issues myself. I add comments explaining non-obvious decisions so reviewers don't have to guess."
*Como reviewer:*
"I separate blocking issues (bugs, security problems, broken contracts) from suggestions (style, alternatives). I ask questions more than I make demands — 'Have you considered X?' rather than 'You should do X'. And I approve when it's good enough, not when it's exactly how I'd write it."
44. Describe your ideal team and working environment.
"I work best in teams where there's a clear separation between what's decided and what's still open — so I know when to execute and when to push back. I like async-first communication with synchronous time reserved for decisions that actually need discussion. And I value a culture where it's safe to say 'I don't know' — that's the fastest path to actually knowing."
45. What questions do you have for us?
Esta pregunta es obligatoria. Tener cero preguntas es una señal de bajo interés. Tres preguntas que suenan senior:
- 1"What does success look like in the first 90 days for this role?"
- 2"What's the biggest technical challenge the team is facing right now?"
- 3"How does the team handle on-call and incident response?"
Evitá preguntas cuya respuesta está en la web de la empresa — eso muestra que no hiciste research.
SECCIÓN 9: Preguntas de TypeScript y tipado
46. What's the difference between interface and type in TypeScript?
"In practice, they're interchangeable for most use cases. Key differences:interfaceis extendable via declaration merging (useful for library augmentation);typecan express union and intersection types, conditional types, and mapped types thatinterfacecan't. My default istypefor application code;interfacewhen designing public APIs that consumers might extend."
// Only type can do this:
type Result<T> = { ok: true; value: T } | { ok: false; error: string };
type Keys = keyof { a: 1; b: 2 }; // "a" | "b"
// Only interface can do this:
interface Window { myPlugin: Plugin } // augments the existing Window type47. What are generics and why are they useful?
"Generics let you write code that works with any type while still being type-safe. Without generics you'd either use any (losing type safety) or write the same function ten times for different types."// Without generics — loses type information
function first(arr: any[]): any { return arr[0]; }
// With generics — type-safe and reusable
function first<T>(arr: T[]): T | undefined { return arr[0]; }
const n = first([1, 2, 3]); // n is number
const s = first(['a', 'b']); // s is string48. Explain the unknown type vs any.
"anyturns off type checking — you can do anything with ananyvalue and TypeScript won't complain.unknownis the type-safe alternative: you can assign anything tounknown, but you have to narrow it (with typeof, instanceof, or a type guard) before you use it. Useunknownfor values from external sources like API responses — it forces you to validate before you use."
function processInput(input: unknown) {
if (typeof input === 'string') {
console.log(input.toUpperCase()); // OK — narrowed to string
}
// input.toUpperCase(); // Error — can't call method on unknown
}SECCIÓN 10: Preguntas de salario y cierre
49. What are your salary expectations?
Esta es la pregunta más temida. La mejor estrategia: dejar que ellos anclen primero si podés.
*Intento de reversión:*
"I want to make sure it's a mutual fit before we get to numbers — do you have a budget range for the role that you can share?"
Si insisten:
"Based on my research for this role and geography, I'm targeting somewhere in the $X–$Y range. That said, I'm flexible depending on the full package — equity, time off, learning budget."
Nunca digas un número único. Un rango te protege. Que el número bajo de tu rango sea lo mínimo aceptable.
50. Do you have any other offers?
Sé honesto sin revelar detalles innecesarios:
"I'm in conversations with a couple of other companies, but I haven't received formal offers yet. I want to give this process the attention it deserves."
Si tenés una oferta real: usarla como leverage está bien. Hacelo directo y sin drama:
"I do have an offer from another company, with a deadline of [fecha]. I'd love to move forward here if the timing works."
El problema de retrieval: por qué el vocabulario se te va bajo presión
Hay un fenómeno bien documentado en psicolingüística: el estrés reduce la fluidez en el segundo idioma más que en el primero. Tu cerebro corre un proceso que los investigadores llaman "lexical retrieval" — buscar la palabra correcta en el diccionario mental. En tu idioma nativo es automático. En inglés, el estrés lo lentifica.
La solución no es memorizar más palabras. Es practicar las respuestas en voz alta, repetidamente, hasta que los chunks completos — frases enteras, no palabras sueltas — se automaticen.
El error más común: preparar en silencio. Leer respuestas en tu cabeza no construye el canal motor que necesitás para hablarlas. Tenés que decirlas.
El segundo error: practicar solo las respuestas perfectas. También practicá los silencios, los errores y la recuperación. "Let me rephrase that" es una frase útil que vale tenerla automatizada.
Interferencias del español en el inglés técnico — las 10 más frecuentes
Estos son los errores que los entrevistadores escuchan de candidatos LATAM todo el tiempo. Identificarlos en tu propio habla es el primer paso.
| Error | Por qué pasa | Corrección |
|---|---|---|
| "I am agree" | "Estoy de acuerdo" → agree parece adjetivo | "I agree" |
| "Is difficult to me" | calco del español | "It's difficult for me" |
| "I have X years" | calco de "tengo años" | "I've been doing X for 3 years" |
| "I make the deploy" | calco de "hacer" | "I deployed / I ran the deployment" |
| "The system makes a call" | calco | "The system makes a call" ✓ — este sí funciona |
| "Actually" como "actualmente" | falso cognado | "Currently" para "actualmente"; "Actually" = "en realidad" |
| Omitir el sujeto | "Hice X" → "Did X" | Siempre explicitá el sujeto: "I did X" |
| "We are 5 in the team" | calco de "somos" | "We have a team of 5" / "There are 5 of us" |
| "I work there since 2020" | calco del presente simple | "I've been working there since 2020" |
| Pronunciar la "h" | "hacer", "hablar" → aspirar la h | En inglés la h de "have" y "help" sí suena, pero suave |
Un sistema de práctica en 4 semanas
Semana 1 — Grabate respondiendo
Respondé las 10 preguntas de comportamiento en voz alta y grabá el audio. No el video — el audio. Escuchate una vez. Anotá:
- ¿Cuántas veces dijiste "like" o "you know"?
- ¿Cuántos silencios de más de 3 segundos?
- ¿Terminaste la respuesta con una conclusión o la dejaste abierta?
No te corrijas en el momento. Primero hacé el inventario.
Semana 2 — Drills técnicos
Tomá 5 preguntas técnicas del área que más probable que te caigan. Respondelas en voz alta como si el entrevistador estuviera en el otro lado: "Sure, so the way I think about this is…". Después codificá. No codifiques en silencio — verbalizá cada decisión: "I'm using a hash map here because I need O(1) lookup."
Semana 3 — Mock interview completa
Una semana antes de la entrevista real hacé una mock completa de 45 minutos. Puede ser con un compañero, con un servicio como Pramp, o con InterviewHack usando tus propias respuestas ancladas en tu CV. La regla: ninguna pausa, ningún "pause, let me think" — simulás las condiciones reales.
Semana 4 (día antes) — Repasar, no estudiar
La noche anterior no aprendas nada nuevo. Revisá tus frases de apertura. Revisá las respuestas de tu STAR. Dormí bien. El sistema nervioso necesita estar calmado para que el retrieval funcione.
Lo que diferencia al candidato que pasa del que no
Después de ver cientos de entrevistas técnicas, la diferencia entre quien pasa y quien no rara vez es de conocimiento. Es de comunicación:
- 1Verbalizán su proceso de pensamiento. No llegan a la respuesta en silencio. El entrevistador ve cómo piensan.
- 2Piden clarificación antes de responder. No asumen. Una pregunta al inicio muestra madurez de ingeniería.
- 3Saben cuándo no saben. "I'm not sure of the exact API, but the approach I'd take is…" es infinitamente mejor que inventar.
- 4Hacen preguntas al final. Tres preguntas concretas sobre el equipo y el trabajo real. No sobre salario en este punto.
- 5Cierran con energía. Los últimos 5 minutos importan. "I'm genuinely excited about this role — the [detalle concreto] is exactly the kind of problem I want to be working on."
El inglés perfecto no existe. Un candidato que piensa en voz alta, estructura sus respuestas y comunica con claridad va a ganarle a alguien con mejor acento pero respuestas vagas.
Herramientas para practicar hoy
- [InterviewHack.ai](https://www.interviewhack.ai) — práctica en voz alta con coach IA que detecta tus errores del español y los convierte en flashcards de recuperación. Funciona con tu CV real.
- Pramp — mock interviews con otros candidatos reales, gratis.
- Speechling — corrección de pronunciación con feedback humano.
- Youglish — buscás una palabra o frase y ves cómo suenan nativos usándola en contexto real.
- Grammarly — para los textos (follow-up emails, thank-you notes post entrevista).
*Un producto de [IA-PTY](https://www.ia-pty.com/)*