Practice a technical interview in English
This mock interview in English is for developers who know their stack but don't get many chances to talk about it in English. Pick your technologies or upload your resume or a job description, choose your level and set the interview language to English, then answer up to 50 questions by voice. You get a report scored on technical accuracy, completeness and clarity, so you can see whether your answers land before the real English interview for developers.
What a technical interview in English usually includes
Self-introduction
A one-to-two-minute story: your role, your stack, years of experience and what you want next. Interviewers use it to judge how clearly you speak about yourself.
Walking through a project
Describing a real project: the problem, the architecture, your part in it and the result. Saying "I" for your own work and "we" for the team matters here.
Explaining technical concepts simply
Explaining things like caching, indexes or async code in short, plain sentences, often with an example, instead of reciting a definition word for word.
Thinking aloud
Talking through your reasoning while you solve a problem, so the interviewer can follow your logic even before you reach the answer.
Asking clarifying questions
Checking the requirements before answering: scale, constraints, edge cases. In English interviews this is expected, not a sign of weakness.
Discussing trade-offs
Comparing options and explaining why you would pick one: speed vs simplicity, consistency vs availability, build vs buy.
Handling "I don’t know" and misunderstandings
Asking the interviewer to repeat or rephrase a question, and admitting a gap honestly while showing how you would find the answer.
Behavioral questions
Stories about conflicts, mistakes, deadlines and teamwork, usually expected in a clear structure: situation, task, action, result.
Questions you will hear in an English technical interview
Junior
Tell me about yourself.
What a strong answer covers:Keep it to about a minute: current role or studies, main stack, one project you are proud of, and what kind of work you want next. Skip your full biography and end with a link to the job. Useful phrases: "I’m a junior frontend developer with one year of commercial experience" and "Right now I’m looking for a team where I can grow in backend as well."
Which technologies have you worked with, and which one do you know best?
What a strong answer covers:Name a short list, then go deeper on one technology with a concrete example of what you built with it. Being honest about the level of each tool sounds stronger than a long list. Useful phrase: "I’ve used Docker on two projects, but I’m most confident with React."
Can you explain what an API is, as if to a non-technical person?
What a strong answer covers:Give a simple analogy, such as a waiter taking your order to the kitchen, then connect it to a real case: a frontend asking a server for data. Short sentences and one example beat technical jargon here. Useful phrase: "In simple terms, an API is an agreement on how two programs talk to each other."
How do you debug a problem you have never seen before?
What a strong answer covers:Describe steps in order: reproduce the bug, read the error and logs, narrow down where it happens, check recent changes, then search docs or ask a colleague with a clear description. A short real example makes it convincing. Useful phrases: "First, I try to reproduce it locally" and "Then I narrow it down step by step."
What have you learned recently, and how did you learn it?
What a strong answer covers:Pick one specific topic, say how you learned it (docs, a course, a side project) and how you used it in practice. This shows you can grow on your own. Useful phrase: "Recently I’ve been learning TypeScript generics, and I applied them in a small side project."
Middle
Walk me through the architecture of your current project.
What a strong answer covers:Go from the big picture to the details: what the product does, the main components and how data flows between them, then your own area. Mention one decision you would change and why. Useful phrases: "At a high level, we have three main parts" and "My area of responsibility was the payments service."
Tell me about a bug that was hard to find. How did you fix it?
What a strong answer covers:Use a clear structure: the symptom, why it was hard to find, how you tracked it down, the fix, and what you changed so it would not happen again. Concrete details like logs, metrics or a test show real experience. Useful phrase: "It turned out the root cause was a race condition between two requests."
What are the trade-offs between REST and GraphQL?
What a strong answer covers:Compare them on a few points: flexibility of queries, caching, tooling, complexity on the server, and over- or under-fetching. Finish with when you would choose each one instead of calling one better. Useful phrases: "It depends on the use case" followed by "For a public API with simple resources, I’d go with REST."
Describe a time you disagreed with a teammate or a client about a technical decision.
What a strong answer covers:Tell it as situation, task, action, result. Show that you listened, backed your view with arguments or data, and accepted the final decision even if it was not yours. Useful phrases: "I understood their concern, but I suggested we compare both options" and "In the end, we agreed to run a quick experiment."
How do you handle unclear requirements?
What a strong answer covers:Explain that you ask questions early, write down assumptions, confirm them with the product owner or client, and deliver small steps to get feedback fast. A real example from work with a client makes it stronger. Useful phrases: "Just to make sure I understand correctly..." and "Could you clarify what should happen if...?"
Senior
How would you design a URL shortener? Talk me through it.
What a strong answer covers:Start by asking about scale and requirements, then go through the API, how short codes are generated, storage, caching for reads and how the service scales. Name the trade-offs out loud instead of presenting one perfect design. Useful phrases: "Before I start, can I ask about the expected traffic?" and "The main trade-off here is between simplicity and scalability."
Tell me about a technical decision you made that turned out to be wrong.
What a strong answer covers:Choose a real decision, explain why it seemed right with the information you had, how you found out it was wrong, and what you did to fix it. The point is ownership and what you learned, not blaming others. Useful phrases: "Looking back, I underestimated the cost of maintaining it" and "What I learned from this is..."
How do you keep code quality high across a team?
What a strong answer covers:Cover the system, not just personal habits: code review rules, automated tests and linters in CI, shared conventions, and time for refactoring in planning. Mention how you balance quality with delivery speed. Useful phrase: "We agreed on a few rules that are checked automatically, so code review can focus on design."
How would you explain a major technical risk to a non-technical stakeholder?
What a strong answer covers:Translate the risk into business impact: what can break, how likely it is, what it would cost, and two or three options with their price. Avoid jargon and finish with a clear recommendation. Useful phrases: "If we don’t fix this, there is a real risk of downtime during peak hours" and "My recommendation is..."
How do you approach mentoring junior developers?
What a strong answer covers:Describe concrete practices: pairing, reviews that explain the why, gradually larger tasks, and regular one-on-ones. Add an example of someone you helped grow. Useful phrase: "Instead of giving the answer right away, I ask questions that lead them to it."
How the English mock interview works
- Pick English (and any other technologies from your stack), your level and the interview language: English, Ukrainian or Russian. Or upload your resume and a job description.
- Answer each question out loud, the way you would with a real interviewer.
- Get a score for every answer on technical accuracy, completeness and clarity, plus a report with your weak spots.
How to speak English confidently in a technical interview
- →Prepare your self-introduction and one project story in English and say them out loud several times. These parts come up in almost every interview, and a practised start lowers the stress for the rest.
- →Use short sentences. One idea per sentence is easier to say correctly and easier for the interviewer to follow than a long, complex phrase.
- →If you did not understand the question, ask: "Sorry, could you repeat the question?" or "Do you mean X or Y?" Interviewers expect this and prefer it to an answer to the wrong question.
- →Buy time with natural phrases instead of silence: "Let me think for a second" or "That’s a good question." Then think aloud so the interviewer hears your reasoning.
- →Learn the English names of the concepts in your own stack, such as dependency injection, race condition or eventual consistency, and practise using them in full sentences, not just as single words.
FAQ
Is my English grammar or pronunciation graded?
No. The report scores your answers on technical accuracy, completeness and clarity, not on grammar, accent or vocabulary. It shows whether you can explain your stack in English clearly enough, but it is not an English language test.
Can I practise my own stack in English?
Yes. Pick your technologies or upload your resume or a job description, choose your seniority level and set the interview language to English. The questions follow your stack, and you answer them by voice.
What level of English do I need?
Enough to understand spoken questions and explain your ideas in simple sentences. The practice is useful exactly when your English is not yet fluent: you hear where your answers get unclear and can fix that before a real interview.
Is there live coding in the interview?
No, there is no code editor. The interview is spoken: you explain concepts, decisions and examples out loud, which is the part many developers find hardest in English. Your first interview of up to 5 questions is free, then interviews start from $1.75 with no subscription.