- BCG X is BCG's tech, build and design unit. The interview depends heavily on the role, so the first step is to identify which tests yours includes.
- For Forward Deployed AI Scientists and Engineers, the process described in 2026 combines a recruiting call, an online coding test, live coding with an interviewer, technical case discussions and, for full-time roles, a business case in the final round.
- These are four different tests. Prepare the coding test, live coding, the technical case and the business case one by one, because strength in one does not carry over to the others.
- The technical case is a discussion about a client problem: you choose the data, justify the method, estimate the value and explain how it would be implemented. It still needs numbers and sound orders of magnitude.
- In Franco's experience of BCG decisions, the business case counts as much as each technical case. Do not treat it as a formality.
BCG X interview preparation starts with a simple question: which interview are you actually facing? A data scientist, an AI engineer, a product manager and a designer at BCG X go through different processes, and even candidates for the same role can see different sequences by office and year. This guide separates what BCG publishes, what has been described for specific roles and what candidates report, so that you can prepare for the right tests.
CasePreparation's coach, Franco Borgonovo, spent ten years at BCG, from intern to Principal, and interviewed and selected candidates as a global lead recruiter. In that role he interviewed many candidates for BCG X, as well as for BCG Platinion and INVERTO. He was not part of BCG X himself; his perspective is that of a BCG interviewer and recruiter, and of an official BCG coach who still works with new hires in BCG's Consulting Foundation Training. CasePreparation is independent and is not affiliated with BCG. All cases and exercises in this guide are fictional and written for it.
What BCG X is, and which interview you will face
BCG X was created in 2022, bringing together BCG Gamma (advanced analytics and data science), BCG Digital Ventures (venture building) and BCG's technology build teams. BCG describes it as its "tech, build, and design unit", fully integrated within the firm. In practice, BCG X people work on client projects with BCG consultants: building AI and data solutions, software and digital products, and new businesses.
That mix of roles is why "the BCG X interview" does not exist as a single format. The table below helps you place your role before you read further.
| Role family | What the process usually tests | Where to start |
|---|---|---|
| Data scientist, Forward Deployed AI Scientist | Coding, technical cases on data and models, a business case | Python and data skills, then technical cases |
| AI engineer, Forward Deployed AI Engineer | Coding, live coding, technical cases on building and deploying solutions, a business case | Live coding, then system and trade-off discussions |
| Product, design, venture roles | Portfolio or product discussions, judgement on priorities and feasibility, behavioural questions | Your own work, told as decisions and results |
| Consulting roles with a tech focus | Generalist case and fit, often with digital topics | The standard BCG case and fit |
If your job title includes "Forward Deployed", the role is built around working directly with clients. Interviewers therefore assess whether they can put you in front of a client, not only whether your technical work is sound.
For procurement and supply-chain roles, see the separate INVERTO interview guide.
The process for Forward Deployed AI Scientists and Engineers
The sequences below are the ones described in 2026 for Forward Deployed AI Scientist and Forward Deployed AI Engineer candidates. They apply to those roles. Other BCG X roles, offices and recruiting seasons can follow a different process.
| Role and contract | Before the interviews | Interviews |
|---|---|---|
| AI Scientist, internship | Recruiting call, online coding test | Two interviews with technical cases |
| AI Scientist, full-time | Recruiting call, online coding test | One technical interview including live coding, then three final interviews: two technical cases and one business case |
| AI Engineer, internship | Recruiting call, online coding test | One live-coding interview and one technical case |
| AI Engineer, full-time | Recruiting call, online coding test | One live-coding interview, then three final interviews: two technical cases and one business case |
BCG's official page for BCG X Associates in Australia and New Zealand describes the same logic for data scientists and AI engineers: an online coding test, a first round of virtual technical interviews with case studies and live coding, and a final round of further case-based and technical interviews.
Candidates add some detail. Several describe a first technical interview of about an hour for AI Scientists: a short discussion of background, around 15 minutes of live coding and around 30 minutes on a technical case. Final interviews are usually reported at 45 to 60 minutes each. Some data science candidates report final rounds with three technical cases and more statistics, such as A/B test design and causal inference, instead of two technical cases and a business case. One candidate in the United States reported a recorded one-way video step in 2026. Treat these as reported variations, not as the standard.
Ask the recruiter how many interviews each round has, which of them include live coding, whether a business case is part of the final round and which tools are allowed in each part. The rules you receive for your own process override anything in this guide.
Four different tests, prepared separately
Many candidates prepare "for BCG X" as a single block, then discover that they are strong in one test and weak in another. It helps to keep the four apart.
Online coding test
Completed alone on a testing platform before any interview. It checks that you can write working code on data problems within a time limit.
Live coding
Done with an interviewer watching, on a shared coding platform. It assesses your code and how you explain your choices while you write it.
Technical case
A conversation about a client problem that needs a data, AI or engineering solution. You discuss data, methods, value and implementation without writing code.
Business case
A consulting case, similar to BCG's generalist cases and sometimes with a digital angle. It assesses structure, logic, numbers and business judgement.
For AI Scientists, the first interview can include both live coding and a technical case in the same hour. The case part is a discussion without code, but that does not mean the interview has no coding: the coding simply happens in a separate section of the same conversation.
The online coding test
The online coding test is a screening step. Candidates describe timed Python exercises on data: reading and transforming tables, aggregating, handling missing values and sometimes simple modelling or SQL. Older BCG Gamma candidates reported tests on commercial coding platforms; check the platform named in your invitation.
Prepare in three ways. First, practise timed data-manipulation exercises in Python until common operations (filtering, grouping, joining, reshaping, handling dates) take you no time to write. Second, read each task fully before coding, because test cases often check the edge cases mentioned in a single line of the prompt. Third, test your code on a small example you build yourself before submitting it.
Live coding: how to prepare
Live coding is short, so the difficulty is less the problem itself than staying clear and organised under time pressure while someone watches. The exercises described for these roles are mostly about data manipulation in Python, sometimes with a short question on reading or explaining a piece of code.
Five skills to practise:
- Python and the standard data libraries. You should write pandas operations without thinking about syntax: selecting, grouping, merging, pivoting, parsing dates and applying functions.
- Data cleaning. Real data has duplicates, inconsistent codes, mixed date formats, missing values and impossible numbers. Spot them and say how you handle each one.
- Readable, modular code. Short functions with clear names, one job each, are easier for the interviewer to follow and easier for you to fix.
- Checking the result. Compare row counts and totals before and after each step, and look at a few rows of the output. A wrong answer you catch yourself is much better than one the interviewer catches.
- Thinking aloud. Say what you are about to do and why, then do it. This lets the interviewer follow your reasoning as well as read your code.
Some candidates are told that they may look up syntax during the coding exercise. If your instructions say so, that permission applies to that exercise only. Do not assume that internet access, calculators or AI tools are allowed in the technical or business cases; follow the rules you receive for each part.
The task
You receive a table of 20,000 order lines from an industrial distributor, with part code, order date, warehouse and quantity. The task: compute weekly demand per part and warehouse, then list the ten parts whose demand grew most between the last two quarters.
What a strong candidate does
Before writing anything, they look at the data and name the problems: part codes in mixed upper and lower case, some with trailing spaces; dates in two formats; negative quantities that are probably returns; a few lines that appear twice. They agree with the interviewer how to treat returns, then write one function to clean the data, one to aggregate it by week and one to compare the quarters. After each step they check the number of rows and the total quantity, so they would notice if a merge or a filter had silently dropped data.
(Writes code silently for four minutes, then says:) "OK, this should work. Let me run it."
"I'll start by looking at the data. Part codes have mixed cases and trailing spaces, so I'll normalise them first, otherwise the same part will count twice. There are negative quantities: are those returns? If so, I'd exclude them from demand and keep them separately. I'll put the cleaning in one function so we can reuse it, then check that the total quantity only changes by the returns I removed."
The stronger version shows judgement on the data before any code, makes an assumption explicit and asks to confirm it, and builds a check into the plan. The interviewer can follow the reasoning even if the code needs a fix later.
The technical case: what it assesses
The technical case is a problem-solving conversation about a fictional client, usually lasting around half an hour inside a longer interview. There are no real data and no code. You receive a scenario and a description of the data the client has, and you work towards a solution the client could use.
The case is assessed on two levels at the same time:
- The business level. Do you understand what the client is trying to achieve, which decision the solution supports, and how success would be measured in money or operations?
- The technical level. Do you pick the right data, propose an approach that fits the problem and explain why it fits better than the alternatives?
A useful sequence for most technical cases:
- Restate the problem and the objective, and confirm them with a question.
- Ask what data exists, how the process works today and what the solution must respect, for example interpretability, latency, cost of errors or integration with existing systems.
- Propose a simple approach first, with your reasons, then say how you would improve it if it works.
- Discuss alternatives and their trade-offs, and choose one.
- Estimate the value with simple numbers and check the order of magnitude.
- Close with a recommendation that combines the business and technical sides, the main risk and how the solution would be implemented.
It is not only a qualitative conversation
Interviewers push on technical choices. Expect questions such as "why this model and not that one?", "how would you validate it?", "what happens when the data drift?" or "which metric would you use, and why not accuracy?". You are expected to go into enough depth to justify each choice, without getting lost in details that the time does not allow.
You are also expected to quantify. You will not calculate anything to the cent, but you should estimate value, cost and error rates sensibly, use ranges when the data are uncertain and check that the result is plausible. A recommendation that improves a model score but cannot say what it is worth to the client is incomplete.
Why generalist frameworks do not fit
A profitability framework or a market-entry checklist does not tell you how to forecast demand, detect fraud or design a retrieval system. Applied mechanically, it wastes time and signals that you have not understood the problem. The structure of a technical case comes from the client's objective and from the logic of the solution: what to predict or build, with which data, how to measure it and how it changes a decision.
That said, the habits of a good consulting case still apply: clarify before solving, state a hypothesis, lead the discussion, say what each result means and finish with a clear recommendation.
A technical case from prompt to recommendation
The case below is fictional and written for this guide. A real interview would be shorter and less complete, and you would ask for most of the information yourself. Try each step before reading the solution.
Your client, Norvik Industrial Parts, distributes spare parts for factory equipment (pumps, bearings, valves and drives) from three warehouses. It stocks about 45,000 different parts. Planners set reorder levels in spreadsheets, based on their own judgement. The COO says: "We hold €80 million of inventory and we still run out of the parts our customers need. Can better forecasting fix this?"
Step 1: clarify the objective and the data
The question
What do you need to know before proposing an approach?
Solution
Four questions shape the case. Objective: the COO wants to release cash from inventory without lowering availability; today 92% of order lines are shipped from stock, and she wants at least that. Data: four years of order lines by part, customer and warehouse; supplier lead times; part costs; and, for the 200 largest customers, a list of the machines they operate. Process: stock is replenished weekly against reorder levels in the ERP system. Constraints: planners must understand the forecasts and be able to override them.
"What machine learning infrastructure does Norvik have, and do they use the cloud?"
"Before I propose anything, I'd like to check three things. Is the goal mainly to cut inventory, to improve availability, or both? What data do we have on past demand, lead times and the customers' installed machines? And how are stock levels set today, so I know where a forecast would actually change a decision?"
The infrastructure question may matter later, but it does not change the approach. The stronger questions define what success means, what the model can learn from and where its output would be used.
Step 2: structure the problem on two levels
The question
Present your approach and where you would start.
Solution
The decision is where inventory can be reduced safely, and whether a forecast is the right tool to do it. A structure built on that decision:
- Where the problem sits: which parts hold the inventory and which cause the stockouts
- The right method for each type of part: a forecasting model where demand is regular enough to learn, a different stocking policy where it is not
- Value: cash released and annual savings, compared with the cost of building and running the solution
- Implementation: how forecasts become reorder levels, how planners use them and how the model is monitored
Hypothesis: the gain from a better forecast is concentrated in parts with regular demand, while for very slow-moving parts the larger lever is where and whether to stock them. I would start by splitting the parts by demand pattern.
Step 3: read the data
The question
The interviewer gives you the table below. "What do you take from it?"
| Demand pattern | Share of parts | Inventory value | Share of missed order lines |
|---|---|---|---|
| Regular (ordered most weeks) | 12% | €30m | 60% |
| Intermittent (a few orders a month or less) | 38% | €35m | 35% |
| Very slow (under two orders a year) | 50% | €15m | 5% |
Solution
Three different problems sit inside one inventory. Regular parts are only 12% of the range but cause 60% of the missed order lines, and they hold €30m: this is where a forecasting model can improve both availability and inventory. Intermittent parts hold the most money, €35m; standard forecasting methods handle them poorly, so they need methods built for sporadic demand and, where possible, information on the customers' installed machines. Very slow parts are half of the range and €15m of inventory but cause only 5% of misses: individual orders that arrive once every two years are difficult to predict, so stocking policy also matters, for example holding them in one warehouse instead of three.
"Regular parts cause most of the stockouts, so we should focus the model on them."
"The table splits the problem in three. Regular parts are 12% of the range but 60% of the misses, so that's where a forecast pays. Intermittent parts hold the most cash and need a different method. And half of the range barely moves: for those €15 million, the question isn't the model but whether we need them in three warehouses at all."
The weaker answer reads one column. The stronger one combines the columns, assigns a different solution to each segment and spots a lever that is not a model at all.
Step 4: choose the method and defend it
The question
"How would you forecast the regular and intermittent parts? And how would you know it works?"
Solution
Regular parts. Start with a simple baseline per part, such as seasonal exponential smoothing, because it is quick, interpretable and gives a benchmark. Then test a single gradient-boosted tree model trained across all regular parts, using recent demand, seasonality, lead time and the number of installed machines among large customers. A model trained across thousands of parts can learn shared patterns; test whether those patterns improve on the per-part baseline using a time-based holdout.
Intermittent parts. Use methods designed for sporadic demand, which estimate separately how often a part is ordered and how much is ordered each time, or simulate demand from its history to set stock levels directly. For parts linked to known customer machines, expected demand can be built from the number of machines and their typical replacement rates.
Metric. Percentage error does not work when many weeks have zero demand, so measure weighted absolute error and bias. The real test, though, is business: simulate the reorder policy with each forecast on the last twelve months of data and compare inventory and the share of lines shipped from stock with what the planners achieved.
The interviewer then challenges you: "Why not a deep learning model for everything?"
"Deep learning would probably be more accurate, so we could try it."
"I'd keep it as a later option. Four years of weekly data does not establish that a neural network will beat a tree model, and planners need to understand why a forecast changed before they trust it. If the tree model works on regular parts, we could test a neural network on the same backtest and adopt it only if it improves inventory and availability, not just the error."
The stronger answer does not reject the alternative. It compares it on data volume, interpretability and adoption, and proposes a test that would settle the question on business results.
Step 5: estimate the value
The question
The interviewer adds three facts. On regular parts, about half of the inventory is safety stock. Holding inventory costs Norvik about 20% of its value per year. Building the solution would cost €0.8m, and running it €0.2m per year. "Your backtest shows a 30% lower standard deviation of forecast error on regular parts. Assume unchanged lead times and the same service target. What is that worth?"
Solution
For this simplified estimate, safety stock is proportional to the standard deviation of forecast error, with lead times and the service target held constant. A 30% reduction therefore suggests about 30% less safety stock. Validate the inventory and availability effects in a simulation and pilot before committing to the saving.
Safety stock on regular parts: 50% × €30m = €15m
Reduction: 30% × €15m = €4.5m of cash released, once
Annual saving: 20% × €4.5m = €0.9m; net of running costs: €0.9m − €0.2m = €0.7m a year
Payback of the build on the annual saving alone: €0.8m ÷ €0.7m ≈ 1.1 years
Then check the order of magnitude: €4.5m is under 6% of total inventory, a plausible effect for one segment. Add the stocking-policy lever: if holding very slow parts in one warehouse instead of three cut their stock by about a third, that would release roughly another €5m, without any model. Together, about €9.5m, or 12% of inventory.
Step 6: recommend and plan the implementation
The question
"So, should we invest in forecasting?"
Solution
Lead with the decision, support it with the numbers, then give the risk and the implementation path.
"We built a segmentation, tested several models and the gradient-boosted trees performed best, with a 30% lower standard deviation of forecast error. There are also some opportunities in slow-moving parts and some risks around data quality."
"Yes, but only for part of the range. A forecasting model on the 12% of parts with regular demand would release about €4.5 million of inventory and save €0.7 million a year, paying back the build in just over a year, while targeting the parts behind 60% of stockouts. For the very slow parts, the bigger lever isn't a model: holding them in one warehouse could release about €5 million more. I'd pilot the model in one warehouse for three months, with planners able to override it and every override logged. The main risk is data quality, for example parts replaced by new codes, so we'd clean that first and track forecast bias monthly."
The weaker answer describes the work and the model. The stronger one answers the COO's question in the first word, gives business value rather than a model score, separates the model from the non-model lever and makes implementation concrete.
What made the difference in this case was not knowledge of a specific algorithm. It was splitting the problem before choosing a method, matching the method to the data, translating forecast error into cash and keeping the people who would use the forecasts in the plan.
The business case
For full-time Forward Deployed roles, one of the three final interviews is a business case. In Franco's experience of BCG hiring decisions, the business case counts as much as each technical case. Because there are two technical cases, the technical side carries more weight in total, but a weak business case is not compensated automatically by two good technical ones. This reflects his experience of how decisions are discussed, not a formula BCG publishes.
The business case is a consulting case: a client problem, usually open, that you structure, analyse with data and close with a recommendation. It may have a digital or data angle, but it is assessed like a business problem. Candidates with strong technical backgrounds often underestimate it, because they expect it to be lighter. It is shorter in the process, not easier.
From the interviewer's side, three things most often separate candidates in this interview: top-down communication (the answer first, then the reasons), leading the case without waiting for the next question, and business judgement on what matters for the client. These sit on top of the basics rather than replacing them. You still need a clear structure, sound logic and accurate numbers, because an error in any of these is noticed immediately.
The prompt
A home-appliance maker sells extended warranties through retailers at checkout. Over one year, the share of appliances sold with a warranty fell from 20% to 14%. The CEO asks why, and what to do.
A structure built for the question
- Customers: did the price or the perceived value of the warranty change?
- Retailers: did their incentive or the checkout process change?
- Competition: do retailers now push their own warranties?
Hypothesis: a drop of this size in one year points to the channel rather than to customers, so start with the retailers.
The numbers
The company sold 500,000 appliances in each of the two years, and each warranty earns €40 of margin.
Lost warranties: (20% − 14%) × 500,000 = 30,000 a year
Lost margin: 30,000 × €40 = €1.2m a year
The insight and the recommendation
The interviewer reveals that the commission paid to retailers was cut last year. That supports the hypothesis: sales staff now have less reason to offer the warranty. A strong close: "The decline is worth about €1.2 million of margin a year and is most likely caused by last year's commission cut. I'd test restoring part of the commission with two retailers for three months and compare uptake with the others before changing it everywhere."
Fit questions and "why BCG X"
The personal part of BCG X interviews looks like the generalist BCG fit: your background, your motivation and experiences you tell in depth. For technical roles, interviewers also ask about your own technical projects: what you built, why you chose that approach, what went wrong and what the result was worth.
Choose the right stories first, then tell them in a structured and concise way. A good technical project story covers the problem, your personal role, the alternatives you considered, the decision and the measurable result. Expect follow-ups on any technical choice you mention.
How to answer "why BCG X"
For BCG X roles, the real comparison is rarely BCG X against another consulting firm's digital unit. It is this role against the other careers open to you: a data science or engineering job at a technology company, an in-house team at a large company, a start-up, or generalist consulting. Interviewers want to know why you would choose client-facing technical work over those.
A strong answer connects three things: the work you want to do, the skills you already have and the alternatives you considered.
"BCG X is at the cutting edge of AI, it combines technology with BCG's strategy expertise, and I want to work on impactful projects with great people."
"I've spent three years building forecasting models in a retail company's data team. The part I enjoy most is the moment a model changes a decision, and that happened too rarely, because I was far from the people deciding. I looked at tech companies, but there I'd be further still from the business. Forward deployed work is the opposite: I'd be building with the client team and explaining the choices to them. I spoke with two data scientists at BCG X, and both described moving between industries every few months. That's the range I'm missing."
The stronger answer explains why this role rather than the alternatives, uses specific evidence from the candidate's career and conversations, and gives reasons the interviewer can test with follow-up questions.
Product, design and venture roles
BCG X also hires product managers, designers, venture architects and other roles linked to building digital products and new businesses. Their interview sequences vary more than those of technical roles, and there is no public standard format, so ask your recruiter for yours. What you can prepare with confidence is the set of skills these interviews look for.
Product roles
Show how you decide what to build: how you prioritised features, weighed user value against feasibility and cost, made trade-offs on scope and measured whether a product worked. Expect discussions of product architecture, scalability and prioritisation.
Design roles
Show your design process on real work: how you understood users, which options you discarded and why, and how you worked with engineers and business owners. Prepare to walk through your portfolio as a series of decisions.
Venture roles
Show business building: how you tested an idea, sized an opportunity, decided to continue or stop, and organised a team with limited resources. Expect business-case style questions on market and economics.
For all three, later rounds with senior leaders tend to focus more on judgement, motivation and how you work with clients. Prepare to explain your work to someone who is not a specialist, and to answer "why consulting rather than a product company".
Tech and digital roles in BCG's consulting practice, including TDA
Not every technology role at BCG belongs to BCG X. BCG's consulting practices include Tech and Digital Advantage (TDA), formerly Technology Advantage, which works on technology strategy, digital transformation and IT topics within BCG's consulting business. Consultants who join TDA without an expert track generally follow the generalist BCG process: online tests where the office uses them, case interviews and fit interviews.
The difference shows in the cases. Interviewers often write cases based on their own projects, so a TDA interviewer may give you a case on digital sales, Industry 4.0, IT costs or a technology transformation. These cases are assessed like any BCG case: structure, analysis, numbers and a clear recommendation. You need to be comfortable with core technology concepts, but nobody expects a generalist candidate to be an IT specialist. Experienced hires are expected to bring knowledge from their own work.
BCG Platinion, BCG's specialist technology architecture and implementation firm, has its own recruiting brand and process. The BCG Platinion interview guide explains it in detail, and the BCG interview guide covers the generalist process step by step.
Common mistakes in BCG X interviews
- Staying in the details of the model without saying what it means for the client's decision.
- Proposing the most sophisticated method first, instead of a simple approach with a clear reason and a path to improve it.
- Answering "it depends" to a request for an estimate, instead of giving a range and checking its order of magnitude.
- Silence during live coding, or writing code before looking at the data.
- Applying a generalist framework to a technical problem.
- Preparing the technical cases thoroughly and treating the business case as an afterthought.
- Looking for leaked cases or a "secret BCG X framework" instead of practising the skills.
A pattern that comes up repeatedly, in Franco's coaching and in candidate reports, is technically strong candidates who give good technical answers without structure or synthesis. One candidate Franco coached for a Forward Deployed role passed the technical stages and then received exactly that feedback after the final technical cases. That is one candidate's experience, but it shows why structure and synthesis deserve as much practice as technical depth.
A preparation plan for BCG X interviews
The plan below assumes about four weeks before your first interview and a technical role. Adjust the weights to your profile: a strong coder with no case experience should move time towards cases, and a former consultant towards live coding.
| Week | Focus | What to check |
|---|---|---|
| 1 | Confirm the format; timed Python data exercises daily; list your project stories | You know each test in your process and the tools allowed |
| 1 to 2 | Live coding aloud with a partner; cleaning and checking habits | You talk through each step and check totals unprompted |
| 2 to 3 | Two or three technical cases a week on varied problems | You quantify value and defend each choice |
| 3 to 4 | Business cases with feedback; top-down synthesis | You lead the case and open with the answer |
| 4 | Full mock final round: two technical cases and a business case in a row | Same quality in the third interview as in the first |
Useful technical topics to refresh for technical cases include regression and tree-based models, time series, classification metrics and class imbalance, A/B testing and causal inference, optimisation methods, and, for engineering roles, system design trade-offs such as cost, latency, data quality, integration and security.
Preparing with a former BCG interviewer
Practice partners can check whether your code runs or your model is reasonable. What they rarely see is how a BCG interviewer would read your answer: whether your structure would hold, whether your synthesis answers the question and whether your business case meets the same bar as your technical cases.
Franco interviewed many BCG X candidates as a BCG Principal and global lead recruiter, and today coaches candidates for technical BCG X roles as well as generalist ones. For technical roles, he uses practice cases developed with a practising data scientist, so that the technical content is credible while his feedback focuses on structure, communication and business judgement. All practice cases are original, never real BCG interview material.
1:1 coaching for BCG X interviews
Practise technical and business cases with a former BCG Principal
Franco Borgonovo spent ten years at BCG and has conducted more than 1,500 interviews, over 800 of them for MBB firms. Every session is with him and is followed by a written report with your scores and priorities.
- Technical cases, business cases and fit questions, adapted to your role and round
- Start with one session (US$249) for a diagnosis and a plan; packages of 3, 5 or 10 sessions add a progress dashboard, practice materials and email support
- Money-back guarantee if the coaching does not meet your expectations
Not sure what you need? Use the free call to tell Franco your role, your interview dates and which part of the process worries you.
Frequently asked questions
How many interviews are there at BCG X?
It depends on the role and contract. For Forward Deployed AI Scientists and Engineers, the full-time process described in 2026 has one technical or live-coding interview followed by three final interviews; internships have two interviews. Other roles and offices can differ, so ask your recruiter.
Is there coding in the technical case?
No code is written in the technical case discussion, although you may be asked how you would structure the code or the pipeline. Coding is assessed separately, in the online test and in live coding, which can take place in the same interview as a technical case.
Do I need to know consulting frameworks for BCG X?
You need to be comfortable with a consulting case, especially for the business case, but generalist frameworks do not fit technical cases. Build each structure from the client's objective and the logic of the solution.
Can I use a calculator or AI tools?
Follow the instructions for your own process. Permissions given for one part, such as looking up syntax during live coding, do not extend to the other interviews. In case discussions, expect to estimate with pen and paper.
Is the business case easier than a generalist BCG case?
It may be shorter or carry a digital angle, but it is assessed on the same skills: structure, logic, numbers and a clear recommendation. In Franco's experience it counts as much as each technical case.
I am a data scientist from industry. What should I work on most?
Usually the consulting side: leading the conversation, quantifying value in money and opening with the answer. Test both your technical depth and how clearly you explain it. A mock case can show whether structure, synthesis or a technical gap deserves your preparation time.
Final checklist
Your next step
Confirm your process with the recruiter, then run one technical case and one business case this week, aloud and timed, and note where you needed help. If you want a former BCG interviewer's view of how you structure technical cases, explain your decisions and handle the business case, one session gives you a realistic mock, a debrief and a written plan.
Coaching with Franco
Get a precise diagnosis before your BCG X round
A realistic interview, a debrief and a written report with your priorities. Start with one session, or talk it through for free first.
About Franco
Franco Borgonovo
Former BCG Principal · 10-year tenure · Official BCG coachFranco spent ten years at BCG, from intern to Principal, interviewing and selecting candidates as a global lead recruiter. He is still an official BCG coach for new hires, and today works one to one with candidates on applications, McKinsey Solve and interviews.
More about Franco →- BCG: BCG X Associate recruitment, Australia and New Zealand (careers page) · online coding test, first-round technical interviews with case studies and live coding, final case-based and technical interviews; read 3 November 2026
- BCG: Interview process (careers page) · skills, case and team interviews; read 2 November 2026
- BCG: How to use AI in your application process · read 2 November 2026