SOLA INSIGHTS
New Grad Technical Interviews: What to Practise Besides Algorithms
Some students have solved a large number of problems and still stall in a Mock Interview. They code before confirming the prompt, repeat a resume bullet when a project question goes deeper, or lose ownership of a Behavioral story. New Grad interviews move among algorithms, projects, Behavioral, OOD, System Design, and communication, so problem count alone is a poor readiness measure.
- Published
- Last reviewed
- Reading time
- 10 min read
Let recruiting dates decide this week's practice
List OA, coding, project-depth, Behavioral, and design rounds separately for the roles in view. Then look at the time before applications open or a confirmed interview takes place. A student still uncomfortable in the chosen language needs fluency work now; a student already receiving OA should add timed practice, project follow-ups, and simulations to the calendar.
- Name each interview stage instead of grouping everything under 'technical'
- Record what the student can complete today and how long it takes
- Keep at least one simulation and one focused review every week
Use each algorithm problem to inspect more than correctness
Before coding, confirm the input, output, and boundary conditions. Once an approach appears, state a correct version before optimizing it. After implementation, run normal, boundary, and error cases by hand. A green result on a practice platform does not reveal whether the explanation, debugging, and time management would hold up in a live interview.
- Group problems to expose recurring recognition or implementation gaps
- State time and space complexity before finishing
- Regularly explain a complete solution without IDE assistance
Expect a major project to generate several follow-up layers
A single resume bullet can lead into architecture, data models, failure handling, testing, and performance. A memorized two-minute introduction answers only the first layer. The student needs one or two decisions worth examining in depth, including the alternatives, costs, result, and accurate boundary between personal contribution and team work.
- Prepare a 30-second overview, a two-minute explanation, and a deeper technical version
- Choose one trade-off and explain both its benefit and cost
- Review one failure, rework, or disagreement from the project
Answer the OOD or System Design question before reaching for a template
Begin by confirming the user's core action and the constraints stated in the prompt. Then define entities, interfaces, responsibilities, and data flow. When a question calls for a clear class design, opening with caches, sharding, and distributed systems can signal that the student has missed the level of the problem.
- Confirm the user, core functions, and important constraints
- Draw the main entities, interfaces, responsibilities, and data flow
- Explore performance, security, or reliability only where the prompt requires it
Say Behavioral and technical answers out loud before interview day
Placing a story into STAR order does not automatically make it persuasive. The interviewer still needs to understand what the student owned, why a choice was made, what happened, and what the student would change now. During coding, assumptions, the current plan, test results, and the point of difficulty should remain audible as well.
- Use genuine examples of collaboration, conflict, failure, and initiative
- Draw a precise line between team results and personal contribution
- When blocked, ask one specific question that can move the problem forward
After a Mock Interview, fix the few problems that keep returning
'Do more problems' does not describe what failed. Separate knowledge gaps, recognition errors, implementation bugs, time allocation, and unclear communication, then move the recurring issues into the following week's practice. One unusually difficult question is worth recording, but it should not overturn the entire schedule on its own.
- Record the observed symptom separately from the likely cause
- Use a related problem several days later to test whether the issue changed
- Track correctness, speed, and communication as separate measures