Inteview techniques

So – you’ve got to the interview stage, you’ve got an idea of what questions might come up now you’ve honed your psychic skills, but now you’ve got to figure out how to answer those questions.

You might have heard there are a couple of simple structures you can use to make sure your answers are concise, yet still provide enough information to the recruiter to evidence that you meet their scoring criteria. The two methods I’ll introduce you to here are STAR and CARL. We talked about STAR earlier in the course, so let’s do a quick recap first:

• S – Situation: Start off with the context of your example. Where/when was it that the situation occurred?
• T – Task: Then go onto what the task was, give an outline of the requirements.
• A – Action: At this point, you’ll get into what should be the longest section of your answer – what you did! Think about it chronologically and be specific about your actions and the reasoning behind them.
• R – Result: You can finish off your answer by talking about the consequences or outcomes of your actions in this situation. What was the result and then reflect back on how it answers the question.

If you use this method to evidence your teamworking skills, you might end up with something like this:

Situation – When I was at university, during my software engineering degree, we were given a team project working with a real business. We were tasked with developing a new feature for the company’s brand-new mobile app. The deadline was tight, and the project required close collaboration between developers, designers, and a group of students who would test the software.

Task – My specific task was to integrate the front-end design with the back-end functionality, which required clear communication and coordination with both the design and QA teams. The challenge was to ensure that the user interface met the design specifications while functioning seamlessly with the back-end code.

Action – I took the initiative to organise daily meetings with my university team and testers to ensure everyone was kept up to date on the project’s progress and any issues that arose. I also made sure to document all changes and share them with the team in real time. When the testing team encountered bugs, I worked closely with them to identify the root causes and quickly find fixes. I also encouraged an open line of communication so that any team member could raise concerns or suggest improvements.

Result – Our coordinated efforts allowed us to deliver the feature on time, with minimal bugs. The project was well-received by both the client and our module leader, and we ended up with a First for the assignment!

The alternate, and my personal preferred, method is called CARL. It’s very similar to STAR, but goes slightly further in enabling you to reflect on your action and draw out pieces of learning, or link what you did to the role’s specification.

• C – Context: Just like with STAR, you begin with the context of the example you’re about to give.
• A – Action: Then we move right onto the action, what exactly did you do in this example?
• R – Result: You can then talk about the result of your work – can you bring in any specific data or evidence of a positive outcome?
• L – Learning/Link: This is where CARL differs from STAR, where you are encouraged to reflect on your answer and talk about what you learnt from the situation, or link it directly back to the questions/skill/competency. It’s up to you which method you choose to use, but it’s a great way to ensure that you are answering the question in full and evidencing your experience, whilst remaining succinct.

If you use this method to evidence your teamworking skills, you might end up with something like this:

Context – When I was at university, during my software engineering degree, we were given a team project working with a real business. My team was responsible for developing a new feature for our company’s brand-new mobile app. The project had a tight deadline and required close collaboration between developers, designers, and a group of testers to ensure a successful outcome.

Action – To foster effective teamwork, I took the initiative to organize daily meetings with my team and the testers. This ensured that everyone stayed aligned on the project’s progress and could quickly address any issues. I documented all changes and shared them with the team in real time. When the testing team encountered bugs, I worked closely with them to identify and resolve the issues promptly. I also promoted an open communication culture, encouraging team members to voice concerns or suggest improvements as we progressed.

Result – Thanks to our collaborative efforts, we delivered the feature on time with minimal bugs. The feature was well-received by both the client and our management. Our teamwork was highlighted as a crucial element in the project’s success.

Learning – This experience reinforced the importance of clear communication and collaboration in achieving project goals. Working together effectively allowed us to meet the tight deadline and deliver a high-quality product, as well as enabling me to gain insight into how a real company works to create new programs and apps.

There may be situations where neither of these methods are useful in formulating your answers, but they’re good to have in the back of your mind to start to think about how you might talk about your strengths/competencies in a logical way.