EY · Primly Community

EY machine learning engineer interview: what they actually test vs the job description

ml_mike · 4 replies

Interviewed for an ML engineer role at EY (specifically the AI practice within Technology Consulting) a few months back. The job description had the usual laundry list of buzzwords. Here's what the interview actually tested.

Background: role was on a team building ML-driven solutions for financial services clients. Think fraud detection, credit risk modeling, some NLP for document processing. Not research, applied ML.

The process: Recruiter screen Technical screen with an ML engineer (60 min) Case study: sent a few days before, present to a panel of 3 Partner/managing director conversation

Technical screen breakdown. The interviewer was solid. We went through: Explain gradient boosting vs random forest. When would you pick one over the other for a fraud detection use case. You're working with heavily imbalanced classes (fraud is 0.3% of transactions). Walk me through how you'd handle that. SQL: write a query to pull a training dataset from a transaction table with specific conditions. Real SQL, not toy SQL. System design question: you have a batch fraud scoring job that's taking 6 hours and the business needs near-realtime scores. How do you approach this.

No leetcode. No algorithmic coding puzzles. If that's what you've been grinding, recalibrate. They want applied ML thinking, not Big-N DSA prep.

The case study was the hardest part. They gave me a fictional client scenario: retail bank wants to build a document classification system to automate loan processing. I had to walk through problem framing, data requirements, model selection rationale, how I'd evaluate it, and how I'd explain the tradeoffs to a non-technical client stakeholder.

That last part matters at EY. If you can't explain precision vs recall tradeoffs to a VP who doesn't know what a confusion matrix is, you'll struggle in a consulting environment.

What they're not testing: deep research-level stuff. Transformers, custom architectures, RLHF. They care more about 'can you ship a reliable model into production for a client' than 'do you know the SOTA on paper.'

4 replies

ds_dmitri

The class imbalance question is a good one to prep. My go-to answer structure: oversampling/undersampling, class weights in the loss, threshold calibration at inference time, and then making sure you're not using accuracy as your metric. Did they push back on any of those or were they looking for a specific approach?

sec_sasha

Curious about the near-realtime fraud scoring question. Did they expect you to have a strong opinion on streaming vs micro-batch or were they okay with you framing the tradeoffs and asking clarifying questions about latency requirements?

ml_mike

They wanted me to ask clarifying questions first, which I did. 'What does near-realtime mean here, under a second or under 5 minutes' is a real question because the answer changes the architecture completely. After I got 'under 2 seconds per transaction' I walked through serving a pre-trained model via a lightweight API vs a streaming pipeline. They seemed to value the question more than any specific architecture I landed on.

pivot_pat

I'll push back slightly on the 'no leetcode' framing. The SQL question you described is legitimately hard if you're not practiced at it. Complex joins, window functions, subquery vs CTE tradeoffs: that's its own skill that you have to practice. Calling it 'not leetcode' can give people false confidence.