From Campus to Career
Students memorise hundreds of questions for an interview that tests something else
A technical interview weighs fundamentals, problem-solving, practical understanding, communication and what a candidate does when stuck. This session shows your students how the round actually works, and has practitioners question them under realistic conditions.
A technical interview is not a test of memory.
Memorising question banks helps with revision. It does not answer what an interviewer is actually weighing: can you apply what you know, explain your thinking, connect theory to something you built, and behave sensibly when you do not know.
Readiness is therefore broader than definitions — and it is role-specific. Preparing for “engineering interviews” in general is the most common wasted effort of a final year.
What to prepare, and how
99 topics across 16 areas. Sixteen areas, in the order they usually matter.
Start With the RolePrepare for the interview you are actually attending.5
Preparation for a developer differs from data analyst, business analyst, QA, DevOps, security, cloud, embedded or mechanical design.
- What does the role involve?
- What skills are expected?
- What fundamentals are relevant?
- What tools are commonly used?
- What questions are likely?
Know Your FundamentalsStrong basics give you something to build on.8
For software roles this usually means the list below. For other disciplines the fundamentals differ, but the test is the same: can you explain them and apply them?
- Programming
- Data structures
- Algorithms
- Object-oriented programming
- Databases
- Operating systems
- Computer networks
- Software development basics
Don't Just Define. Explain.Move from definition to understanding.4
Asked “what is polymorphism?”, a definition is one level. Stronger: why it is useful, where it applies, a simple example, and how you used it in a project.
- Why it is useful
- Where it applies
- A simple example
- How you used it
Problem-SolvingThe interviewer can only evaluate thinking that is spoken.7
- Understand it — what is actually being asked?
- Clarify assumptions
- Break it into smaller pieces
- Think aloud
- Try a simple solution first
- Improve it
- Test it
Coding InterviewsWriting code is one part of the conversation.11
Difficulty varies by company and role, but the ground is usually the same.
- Arrays
- Strings
- Loops and functions
- Recursion
- Sorting
- Searching
- Hashing
- Linked lists
- Stacks and queues
- Trees
- Basic dynamic programming
Focus on understanding the problem, readable code, explaining the approach, testing, and complexity where it is relevant.
Know the Language You ClaimIf the resume says Java, expect Java questions.7
- Syntax
- Data types
- Functions
- Error handling
- Object-oriented concepts
- Language-specific behaviour
- Libraries you have used
Do not list a language because you finished one course in it.
Database ReadinessWhere theory meets your own project.9
- Tables
- Primary and foreign keys
- Relationships
- Joins
- Normalisation
- SQL queries
- Indexes
- Transactions
- Constraints
Expect “how did you design the database in your project?”
Project-Based QuestionsYour own project often becomes the technical interview.8
- Explain your architecture
- Why this technology?
- How is the database designed?
- How does authentication work?
- What happens when it fails?
- How did you test it?
- What security concerns exist?
- How would you scale it?
System ThinkingCan you connect components, not just write a function?5
Freshers are not expected to design large systems. Basic architectural thinking still shows.
- How would you design a simple login system?
- How would you build a URL shortener?
- How would a file-upload system work?
- How would you structure notifications?
- What happens with thousands of users?
DebuggingReal engineering is finding what is wrong.5
Show a process rather than guesses: observe, reproduce, isolate, investigate, fix, verify.
- Broken code
- Incorrect output
- An error message
- A failing query
- Unexpected behaviour
Interviewers often value the process even when the problem is unfamiliar.
When You Don't KnowOne unknown answer does not end an interview.4
Say “I haven't worked with that directly” — then, where you can, “but based on what I know, I would approach it this way.”
- Ask for clarification
- Connect it to something you do know
- Explain how you would find the answer
- Work through it step by step
Honesty plus reasoning beats a confident wrong answer.
Think AloudSilence hides your thinking.3
“My first thought is to iterate through the list…” “That works, but the complexity looks high…” “A hash map might help here…” That turns an examination into a conversation.
- Your first instinct
- Why you are rejecting an approach
- What you are trying next
Ask Clarifying QuestionsGood engineering starts with understanding the problem.6
- Can the input be empty?
- Can values repeat?
- Is it already sorted?
- What is the expected size?
- Optimise for memory or speed?
- What should happen at this edge case?
Test Your Own SolutionFinding your own mistake beats the interviewer finding it.7
- Normal case
- Empty input
- Minimum values
- Maximum values
- Duplicates
- Invalid values
- Boundary conditions
Time & Space ComplexityEnough to justify one approach over another.4
- O(1)
- O(n)
- O(log n)
- O(n²)
You do not need to turn every answer into mathematics. You do need to say why one approach is more efficient.
Technical CommunicationKnowing and explaining are different skills.6
Practise each of these in 30 seconds, then in two minutes.
- What is an API?
- What happens when you open a website?
- What is a database index?
- What is object-oriented programming?
- What is cloud computing?
- What is machine learning?
Common mistakes
- Memorising without understanding — follow-ups expose it
- Starting to code before understanding the problem
- Staying silent, so the reasoning is invisible
- Ignoring edge cases
- Giving up instead of breaking the problem down
- Pretending to know
- Listing skills that cannot be defended — your resume sets the questions
- Revising generic questions but not your own project
A ten-step preparation plan
- Choose the target role
- Identify its core skills
- Assess yourself: strong, moderate, weak
- Revise the weak fundamentals
- Practise progressively harder problems
- Review your own projects
- Explain out loud, not just on paper
- Take mock interviews
- Review the feedback
- Repeat the cycle
Who students face
- Working engineers
- Technical leads
- Engineering managers
- Interviewers who assess freshers
- Young professionals
How the session runs
An engineer explains how candidates are evaluated. A student and a practitioner work a technical problem together in front of the room. A student's own project becomes the basis for technical questioning. The awkward case is demonstrated deliberately — what to do when you are stuck. Then mock technical interviews, with feedback on fundamentals, problem-solving, technical communication, project understanding and coding approach.
What your students leave with
- A clear picture of what a technical interview evaluates
- How to prepare for one specific role rather than “engineering interviews”
- Which fundamentals they personally need to revise
- A method for approaching an unfamiliar problem
- The habit of thinking aloud so reasoning is visible
- A way to handle questions they cannot answer
- Their own project treated as interview material
- The habit of testing their own answer before handing it over
Scheduled sessions
Nothing scheduled yet
Sessions are arranged with a college once a date is agreed. Ask us and we will find the right person for it.
A student rather than a college? See what is coming up, or ask your placement team to host this.
Technical interviews are not about knowing everything.
Tell us who your students are and what stage they are at. Sessions are free for participants.