AQR Behavioural Interview: 6 Competencies & How to Answer

What to expect from a behavioural interview at AQR

AQR Capital Management is publicly known as a systematic, research-driven investment manager, and firms of this type tend to hire people who combine technical strength with sound judgement. A behavioural interview is where the second half gets tested. Instead of asking you to solve a problem, the interviewer asks what you actually did in a past situation, on the assumption that past behaviour is the best available predictor of future behaviour.

One caveat: we have no inside knowledge of AQR's current process, and nobody outside the firm should claim to. Formats vary by role (research, engineering, portfolio implementation, client-facing and so on) and by hiring cycle, and may include phone screens, live conversations or recorded one-way video questions. Check your invitation and the job description, and ask your recruiter what to expect. What follows is built on the competencies quantitative asset managers commonly assess, so it should transfer whichever format you meet.

Six competencies behavioural questions usually probe

Read the job description closely and map its wording onto these themes. The labels differ between firms, but the underlying qualities are consistent across research-led investment businesses.

• Intellectual curiosity and rigour: do you dig into why something works, test your assumptions and check your data? Expect questions like 'Tell me about a time you went deeper than you needed to.'
• Intellectual honesty: can you say 'I was wrong' and change your view when the evidence changes? Questions often ask about a mistake, a flawed analysis or a time you disagreed with a result you wanted.
• Collaboration: research-led teams rely on peers challenging each other constructively. Interviewers look for how you give and take feedback, not just whether you worked in a team.
• Integrity and risk awareness: in finance this means being open about errors, respecting controls and thinking about what could go wrong. A story where you flagged a problem early is valuable.
• Resilience and ownership: how do you behave when a project stalls, results disappoint or you face a hard deadline? Strong answers show you took responsibility rather than assigning blame.
• Clear communication of complex ideas: can you explain a technical piece of work to someone who does not share your background, briefly and without losing accuracy?

Structure every answer with STAR

STAR keeps answers specific and stops rambling. Situation: set the scene in one or two sentences. Task: state your responsibility or the goal. Action: explain what you personally did, step by step. Result: say what happened, what you learnt and what you would do differently.

Spend most of your time on Action. Candidates commonly spend half their answer on background, which leaves little evidence of their own contribution. Say 'I' when describing your decisions and 'we' only for genuinely shared outcomes. For recorded one-way video questions, aim for roughly 60 to 90 seconds unless the platform sets a different limit, which means about two sentences each for Situation and Task, four to six for Action and two for Result.

Worked example: 'Tell me about a time you were wrong'

This illustrative answer shows the shape to aim for. Replace the details with your own real experience; interviewers can tell when a story has been borrowed.

Situation: 'During my master's dissertation I built a trading signal that looked impressive in testing.' Task: 'I was responsible for validating it before presenting to my supervisor.' Action: 'When I re-ran the pipeline on a clean copy of the data, the performance dropped sharply. I traced it to a look-ahead problem: one input was being aligned to a date before it would actually have been available. I rebuilt the data alignment, documented the error in my notes, and told my supervisor before the meeting rather than hoping it would not come up. I also added a check to my code that flagged any feature using future-dated data.' Result: 'The corrected result was much weaker, but it was one I could trust, and my supervisor said that was the version worth discussing. I now treat any result that looks too good as something to test harder, not celebrate.'

Why it works: the mistake is real and specific, the candidate owns it, the action shows rigour, and the lesson changed their behaviour.

Do and don't: small differences that change the impression

Interviewers form a view from small signals in how you tell the story.

• Do choose a real failure with real stakes. Don't offer a disguised strength such as 'I care too much about quality'.
• Do explain your reasoning and what you checked. Don't just list outcomes; the process is what they are assessing.
• Do give credit to colleagues accurately. Don't claim sole ownership of team work or blame others for setbacks.
• Do quantify results where you honestly can. Don't invent figures; 'noticeably faster' is better than a made-up percentage.
• Do explain technical work in plain language first, then add detail. Don't hide behind jargon.

How to prepare in a week

Build a bank of five or six stories rather than memorising twenty answers. Each story should be flexible enough to cover several competencies: a project that went wrong, a disagreement with a colleague, a time you learnt something quickly, a moment you spotted a risk, and an explanation of complex work to a non-specialist.

Then rehearse out loud. Written answers read well and sound stilted, and the gap only shows when you speak. Record yourself, check the timing and watch for filler words and long, slow set-ups. A tool like ScreenReady lets you practise timed, one-way video questions and get AI feedback on structure and clarity, which is a useful way to rehearse under the same pressure; a friend or a phone camera also works.

Finally, prepare questions of your own about how research is reviewed, how teams give feedback and what the first six months look like. Specific, curious questions are themselves evidence of the competencies above.