Getting interviews means your profile works; the gap is performance under pressure. Find out which kind of round you are failing, practise that format out loud with a timer, learn to talk through your approach before coding, and review every attempt like a post-mortem.
What people tell me
My applications do lead to interviews, and sometimes I clear the aptitude or screening stage, but I keep failing the technical round. It might be a live coding problem, a machine coding task, JavaScript or framework questions, or core computer science topics. I prepare a lot, yet I freeze or run out of time, and I never get useful feedback about what went wrong.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Name the exact round you fail: problem solving, machine coding, language fundamentals, core CS or design. Each needs different practice.
- Interviewers score your reasoning, not only the final code. Clarify, plan aloud, then code.
- Timed practice spoken out loud is the closest thing to the real room. Silent practice builds the wrong habit.
- Write a short post-mortem after every interview while you still remember the questions.
- Two mock interviews a week for a month changes results more than another hundred solved problems alone.
First, notice what is already working
If you are getting interviews, your resume, projects and applications are doing their job. That narrows the problem considerably. You are not starting over; you are fixing one stage of the process. That is also why "just practise more" is poor advice here. You need to practise the right thing, in the right conditions.
Identify which round is failing
Technical rounds are not one skill. Look back at your last few interviews and place each failure in one of these rows.
| Round type | What it tests | Typical failure | Practice that fixes it |
|---|---|---|---|
| Problem solving (DSA) | Choosing an approach, complexity, clean code | Freezing, or brute force with no improvement | Pattern-based practice, timed and spoken aloud |
| Machine coding | Building a small working app or module in 60 to 120 minutes | Unfinished, messy structure, no working core | Timed builds of common tasks with a fixed plan |
| Language and framework questions | JavaScript closures, event loop, React rendering, Java collections | Knowing terms but not explaining behaviour | Explain concepts in your own words with small examples |
| Core CS | Operating systems, networks, databases, OOP | Memorised definitions that collapse on follow-up | Study through "why" and real examples |
| Aptitude | Speed with numbers and logic | Running out of time | Short daily timed sets |
| Design (for experienced roles) | Structuring systems, trade-offs | Jumping to tools without requirements | Structured framework and mock discussions |
Most people fail in one or two rows, not all six. Put most of your time there.
The habit that matters most: think out loud
Many candidates who could solve a problem at home fail it in an interview because they solve it silently. The interviewer cannot give credit for reasoning they cannot hear, and cannot offer hints if they do not know where you are stuck. Use this sequence every time:
- Restate the problem and ask about inputs, edge cases and constraints.
- Give a brute-force idea first, with its complexity, so you have something on the table.
- Improve it by naming the pattern you think applies and why.
- Agree the approach before writing code.
- Code in small, readable pieces, narrating as you go.
- Test with an example and an edge case, then state the final complexity.
This structure also stops panic, because you always know what the next step is.
Practising each round properly
Problem solving
Practise by pattern, not at random: two pointers, sliding window, binary search, BFS and DFS, heaps, dynamic programming basics. Solve with a 30 to 40 minute timer and say your reasoning aloud, even alone. If you are stuck after 20 minutes, read the approach, then re-solve it the next day without looking.
Machine coding
Pick common tasks such as a to-do app with filters, a parking lot module, an autocomplete input, or a small REST API. Use a fixed plan: requirements in five minutes, structure in ten, a working core first, then polish. A running, simple solution beats an elegant half-finished one.
Language and framework fundamentals
For JavaScript roles, be able to explain closures, hoisting, scope, this, promises and async/await, the event loop, and how React re-renders. For backend roles, know how your language handles concurrency, errors and memory, plus databases, indexes, caching and API design. Write tiny examples for each rather than reading definitions.
Aptitude and core CS
Both reward little and often. Twenty minutes of timed aptitude sets a day builds speed faster than a weekend cram. For core CS, pick one topic a day, such as how an index speeds up a query or what happens when you type a URL, and explain it aloud as if teaching a junior. If you cannot answer the follow-up "why?", you have found the gap.
A four-week reset plan
| Week | Focus | Output |
|---|---|---|
| 1 | Post-mortems of past interviews, pick your two weakest rows | A written list of gaps with examples |
| 2 | Daily timed practice on the weakest row, spoken aloud | 10 to 12 problems or 3 machine coding builds |
| 3 | Mock interviews with a peer or mentor, two per week | Notes on what the interviewer saw |
| 4 | Mixed practice under real conditions, then resume applying | Confidence on your own process |
Getting feedback when companies give none
- Write a post-mortem within an hour of every interview: questions asked, where you hesitated, what you would do differently.
- Politely ask the recruiter for any feedback. Some will share a line or two.
- Do mock interviews with friends in the industry or community members, and ask them to be blunt.
- Record yourself solving a problem and watch it back. It is uncomfortable and extremely effective.
Nerves are normal and trainable
Freezing is usually a lack of rehearsal in realistic conditions, not a lack of knowledge. The more often you solve problems out loud with someone watching, the less the real interview feels unfamiliar.
If you are still stuck
For recognising which approach a problem needs, read Fifteen problem shapes and the move that solves each. The full graduate plan, including how interviews fit into the search, is in From CSE graduate to your first software engineering job. If you want someone to look honestly at where your rounds are going wrong, book a free 1:1 session.
Was this answer helpful?
Read next
- From CSE Graduate to Your First Software Engineering JobJob, timing and learning are one loop that traps graduates. How to run learning, applications and interview practice in parallel, what to stop learning, how junior technical interviews are structured, how to practise patterns and speak your thinking aloud, plus a twelve week plan and a reflection template.
- Fifteen Problem Shapes and the Move That Solves EachThe usual way to learn algorithms is to work through a long list of problems and hope something generalises, which leaves most people with a hundred solutions memorised and no idea what to do with the hundred and first. There are perhaps a dozen shapes of problem, each with a move that usually works. Fifteen of those shapes and how to recognise them.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.