Why Technical Candidates Fail Behavioural Rounds
The pattern plays out constantly in UK tech graduate hiring. A candidate solves two LeetCode mediums cleanly, explains their approach well, and then hits the behavioural round. Asked "Tell me about a time you dealt with conflict in a team," they give a 45-second answer that sounds like it was written for a hospitality job application. They don't get an offer.
Behavioural interviews are not a soft formality before the "real" technical assessment. At companies like Amazon (where Leadership Principles determine hiring decisions), Sky, Monzo, and most UK financial services tech employers, the behavioural round can and does outweigh the coding round. Getting it right is not optional.
This guide gives you the STAR framework applied specifically to software engineering and CS project scenarios - with real example answers you can adapt. For the technical side, see our guide on graduate software engineer interview questions and answers.
What STAR Actually Means (and Where People Go Wrong)
STAR stands for: Situation, Task, Action, Result.
- Situation: The context. Where were you, what was the project, who was involved?
- Task: Your specific responsibility. What were you supposed to do?
- Action: What you specifically did. Not "we" - you.
- Result: The measurable outcome. What changed because of your action?
The two most common mistakes CS graduates make:
- Overweighting Situation and underweighting Action. Interviewers don't need 3 minutes of context. They need to hear what you specifically did.
- Using "we" throughout the Action section. "We decided to refactor the API" tells the interviewer nothing about you. "I identified that the API was the bottleneck, proposed the refactor in our retro, and led the implementation over two sprints" is what they're listening for.
Building Your STAR Story Bank
Before any interview, prepare 6-8 flexible stories that can be adapted to different questions. For a CS graduate, your material comes from:
- Final year project or dissertation
- Group coursework and team projects
- Internships and placements
- Hackathon projects
- Side projects or open-source contributions
- Part-time technical work or freelance projects
Stories that involve: a technical decision you made, a constraint you worked within, a failure and how you recovered, a conflict you resolved, or a deadline you met under pressure are the most versatile.
The 10 Most Common Behavioural Questions in UK Tech Interviews - With Example Answers
1. "Tell me about a challenging technical problem you faced and how you solved it."
What they're testing: Problem-solving depth, technical ownership, ability to communicate complex topics simply.
Example answer: "During my final year project, I was building a real-time recommendation system in Python. The core issue was that my matrix factorisation algorithm was taking 45 minutes to retrain on the full dataset, which made live updates unusable. (S) My responsibility was to make the recommendation engine production-viable within a 2-week deadline. (T) I profiled the code with cProfile, identified that 80% of the time was spent in a scipy sparse matrix multiplication. I switched to an incremental training approach using SGD rather than batch retraining, which reduced the retrain time to 4 minutes. I also implemented a Redis cache for the most common queries so users experienced sub-50ms response times even during a retrain cycle. (A) By the end of the two weeks, the system was running reliably with live updates and the project received a distinction. (R)"
2. "Describe a time you had a disagreement with a team member."
What they're testing: Maturity, communication, ability to disagree constructively without personal conflict.
Example answer: "In our third-year group project, a teammate wanted to use MongoDB for our data store. I felt a relational schema was a better fit because our data had clear relationships and we'd need complex joins. (S) I was responsible for the backend architecture. (T) Rather than debating it in a standup, I suggested we each write a one-page document outlining the trade-offs and share them before our next meeting. We both did this, and when we read them together, the team agreed the relational model was more appropriate given our access patterns - but my teammate's point about document flexibility led us to add a JSONB column for user preferences, which turned out to be genuinely useful. (A) The architecture worked well throughout the project, and more importantly, we established a pattern of writing down trade-off analyses that the whole team adopted for future decisions. (R)"
3. "Tell me about a time you had to learn something quickly."
Example answer: "During my summer internship at [company], I was assigned to a project that required building a data pipeline in Apache Kafka - a tool I hadn't used before. (S) I had 3 weeks to deliver a working prototype. (T) I spent the first two days exclusively on the Kafka documentation and built a small proof-of-concept message producer/consumer before touching the actual project code. I also found a senior engineer on the team who'd used Kafka extensively and asked for a 30-minute architecture review of my approach before I started building. (A) The prototype was delivered on schedule, and the approach I used was adopted as the pattern for two subsequent pipeline builds that quarter. (R)"
4. "Give me an example of a time you failed."
What they're testing: Self-awareness, ability to reflect and improve. Candidates who claim they've never failed, or who describe a "failure" that was obviously a success, lose credibility immediately.
Example answer structure: Be genuinely honest. Describe a real failure. The emphasis should be 30% on what went wrong, 70% on what you learned and changed. "The most significant failure in my technical work was [X]. What I didn't appreciate at the time was [root cause]. Since then, I've [concrete change in behaviour], which meant [specific positive outcome in a subsequent situation]."
5. "Tell me about a time you had to prioritise under pressure."
6. "Describe a project where you took ownership of something beyond your remit."
7. "Give an example of when you had to work with ambiguous requirements."
8. "Tell me about a time you had to give difficult feedback."
9. "Describe a situation where you had to adapt your communication style for a non-technical audience."
10. "Tell me about your most impactful contribution to a team project."
For questions 5-10, apply the same STAR structure with a heavy emphasis on your specific action. The single most important word in behavioural answers is "I" - not "we."
Amazon Leadership Principles - Special Preparation
If you're interviewing at Amazon, behavioural questions are explicitly mapped to their 16 Leadership Principles. Every interviewer is assigned 2-3 principles to assess. Prepare at least one story for each of the most commonly tested:
- Customer Obsession - "Tell me about a time you advocated for the end user when it was inconvenient."
- Ownership - "Tell me about a time you took on something that wasn't your responsibility."
- Invent and Simplify - "Tell me about a time you found a simpler solution to a complex problem."
- Bias for Action - "Tell me about a time you made a decision with incomplete information."
- Dive Deep - "Tell me about a time you used data to challenge an assumption."
Company-Specific Behavioural Questions
Beyond Amazon, companies like Sky, Monzo, Barclays, and BT all use company-values-mapped behavioural questions. GradSignal's interview playbooks include the specific behavioural questions asked at each company, so you can prepare the right stories for the right audience. Using a generic STAR story for a company-values question is a common miss that company-specific prep eliminates entirely.