What a technical interview looks like
“Technical” means the skills of the job, so the format depends on your field:
- Software and IT: coding problems, data structures, databases, system design for senior roles, and a deep dive into your projects.
- Core engineering: subject questions (strength of materials, fluid mechanics, surveying), drawings, site or plant scenarios and numericals.
- Finance and accounts: accounting entries, reconciliations, tax basics, Excel tasks and case problems.
- Healthcare: clinical scenarios, protocols, drug calculations and patient-safety questions.
- Design and marketing: portfolio walkthrough, a take-home task or a live critique.
Most technical rounds have three parts: questions on fundamentals, one or more problems to solve, and questions about your past work. Browse interview questions by profession to see what is asked in your field.
How to revise in one to two weeks
- Map the job description. List every skill and tool it mentions. Mark which ones you use daily and which need revision.
- Revise basics before advanced topics. An interviewer who hears a shaky definition will probe harder. Be able to explain each core concept in two or three simple sentences with an example.
- Practise problems under time. Solve problems of the type used in your field with a 20–30 minute timer, and say your reasoning aloud as you work.
- Take timed tests. Use the free interview tests to find weak topics quickly.
- Prepare two projects deeply. Know the problem, your exact role, the tools, the trade-offs, the result and what you would change.
How to answer a problem in the room
Use the same routine for every problem, whether it is a coding question, a numerical or a case:
- Repeat and clarify. Restate the problem and ask about inputs, limits and edge cases. “Can the list be empty? Are the values always positive?”
- Give a simple approach first. Describe a straightforward solution even if it is slow. It shows you can get to an answer.
- Improve it. Explain what makes it slow or risky and how you would do better.
- Work it through. Write the code, calculation or plan step by step, talking as you go.
- Test it. Walk through one normal case and one edge case. Fix mistakes calmly when you spot them.
Silence is the biggest problem in technical rounds. If you are stuck, say what you are considering. Interviewers often give hints, but only when they can follow your thinking.
Talking about your projects
Expect the interviewer to pick one project from your resume and go deep. Prepare to answer:
- What problem did it solve, and for whom?
- What exactly did you build or decide, as opposed to the team?
- Why did you choose this tool, method or design over another?
- What went wrong, and how did you fix it?
- What was the measurable result?
Use “I” for your own work and “we” for the team’s. If a project is on your resume, you must be able to defend it. Remove anything you cannot explain. The STAR answer builder helps you structure project stories.
When you do not know the answer
Everyone hits a question they cannot answer. What matters is how you handle it:
- Say it honestly: “I have not worked with that directly.”
- Connect to what you do know: “I have used a similar approach with…”
- Reason it out: “If I had to guess, I would expect it to work like this, because…”
- Show how you would learn it: documentation, a small test, asking a senior.
Bluffing is quickly exposed by a follow-up question and damages trust in your other answers. A clear “I do not know, but here is how I would approach it” is a respectable answer in any technical round.
Online coding and take-home tasks
Many companies run a first technical screen as an online test or a shared-screen coding session. Check the platform beforehand, test your internet and practise typing code without auto-complete. For take-home tasks, read the brief twice, meet every stated requirement before adding extras, write a short note on assumptions and trade-offs, and submit before the deadline. Clean, working and well-explained beats clever and incomplete.
After a take-home task, expect a follow-up call where you walk through your work. Be ready to explain why you structured it that way, what you would add with more time and how you would test it further.
A worked example of thinking aloud
Suppose a data analyst candidate is asked: “Our monthly sales report shows revenue fell 15% last month. How would you investigate?” A strong answer sounds like this:
“First I would confirm the number is right: check whether the data for the full month has loaded and whether any filter or currency setting changed. If the drop is real, I would break revenue into number of orders and average order value to see which one moved. Then I would split by region, product category and sales channel to find where the fall is concentrated. If one region explains most of it, I would check for stock-outs, price changes or a sales team change there. Finally I would compare with the same month last year to rule out a seasonal pattern, and share a short summary with the likely cause and the next check.”
The answer is not perfect or complete, but it is structured, starts with data quality, moves from broad to specific and ends with a clear next step. That is exactly what interviewers want to hear, whatever your field.
Common mistakes
- Jumping straight into a solution without clarifying the question.
- Solving in silence so the interviewer cannot follow or help.
- Listing tools on the resume that you cannot explain in depth.
- Revising only advanced topics and stumbling on basic definitions.
- Bluffing an answer instead of admitting a gap and reasoning it out.