IT consultant interview questions, with worked answers

How to use these questions

Answer each question with the steps you would take, then add a project of your own: the platform, the client's industry, your part and how it ended. Interviewers for consulting roles listen for the moment you made a decision with the client, so name it.

What an IT consultant is expected to know

• Discovery: requirements workshops, process maps and a fit-gap analysis the client signs.
• A platform in depth: such as SAPAsked in 6% of IT consultant ads (as of 5 Nov 2026).Know how a module maps a client's processes, where configuration ends and development starts, and what a release changes., SalesforceAsked in 4% of IT consultant ads (as of 5 Nov 2026).Objects, flows, profiles and the limits of standard features before anyone asks for custom work., ServiceNow or Microsoft Dynamics, with an overview of the others and of the clouds they run on.
• Delivery: project managementAsked in 28% of IT consultant ads (as of 5 Nov 2026).Plan a rollout with milestones, owners and risks, and keep a client steering group informed every week., agileAsked in 16% of IT consultant ads (as of 5 Nov 2026).Run a client project in short iterations with a backlog the client owns and demos they attend. work with a backlog in Jira, estimates, change requests and status reports.
• Data and testing: data migration, SQLAsked in 6% of IT consultant ads (as of 5 Nov 2026).Query the client's data yourself to check a migration, reconcile counts and answer a question in a workshop. to check it, test plans, cutover and the weeks after go-live.
• People: stakeholder managementAsked in 17% of IT consultant ads (as of 5 Nov 2026).Find who decides, who uses and who blocks, and keep each of them informed in their own words., presentingAsked in 4% of IT consultant ads (as of 5 Nov 2026).Present a recommendation to a steering group in ten minutes, with the options and the risks. to a steering group, and training users so they can run the system.

Requirements, workshops and stakeholders

How do you run a requirements workshop with a client who is busy and sceptical?

What they check: preparation, control of the room, and an outcome on paper.

Short answer: "I prepare a draft of the process from what I already have, so people correct something instead of starting from nothing. I invite the people who do the work and one who decides, keep to a clear agenda, park side topics on a visible list, and close with what we agreed and who owes what. The notes go out the same day for a quick confirmation."

The full answer: A sceptical client has usually lived through a project that took their time and gave little back. Show early that you listened: repeat their words in the process map, fix one small irritation they mention, and keep the workshop short. Separate what the system must do from how it looks today, because users often describe their workarounds as requirements.

A weak answer: "I send a questionnaire and wait for the answers." Follow-up: "Half the invited users did not come." Say how you would get their input before the design is fixed.

What is a fit-gap analysis, and what do you do with the gaps?

What they check: that you know the platform's standard and defend it before building.

Short answer: "A fit-gap analysis compares each requirement with what the platform does as standard. Fits are configured. For each gap there are four answers: change the process to the standard, use a setting or an add-on, build an extension, or accept a manual step. I write the cost and the risk of each, and the client decides."

The full answer: Every extension has to be tested and maintained through each release of the platform, so the cheapest answer on day one is often the most expensive over five years. A good fit-gap list says which gaps are legal or contractual musts and which are habits. Clients accept the standard more easily when they see a demo of it with their own data.

A weak answer: "We build whatever the users ask for." Follow-up: "The head of sales insists on his old report layout." Explain how you would handle it without a custom build.

How do you handle stakeholders who want different things from the same system?

What they check: that you surface conflicts early and let the right person decide.

Short answer: "I make the conflict visible in plain words: what finance wants, what sales wants, and what each option costs in time and risk. I do not pick a side. I take it to the person who owns the decision, usually the sponsor or the steering group, with a recommendation, and I write down the result."

The full answer: A stakeholder map helps: who decides, who uses the system every day, who must be informed and who can stop the project. Talk to each group in its own words. Many conflicts disappear when both sides see the same data; the rest need a decision, and a project that waits for agreement without a decision slips.

A weak answer: "I go with whoever is most senior." Follow-up: "The sponsor is on leave for three weeks." Say how you keep the project moving without overstepping.

Scope, estimates, contracts and proposals

How do you estimate a piece of work you have not done before?

What they check: method, honesty about uncertainty, and a number you can defend.

Short answer: "I break it into parts I can compare with work I know, estimate each part with a low and a high figure, and add the parts that are easy to forget: testing, data, training, meetings and fixes after go-live. I ask a colleague who has done similar work to check it, and I write down the assumptions the estimate rests on."

The full answer: An estimate without its assumptions becomes a promise. Name the open questions, give a range rather than one figure early on, and narrow it as discovery answers them. Track your own estimates against the actual time on every project; that history is the best tool a consultant has.

A weak answer: "I take what the client's budget allows." Follow-up: "The client says your estimate is twice what another firm offered." Explain how you compare scope, not totals.

What changes between a fixed price project and one on time and materials?

What they check: that you understand where the risk sits and how it changes your behaviour.

Short answer: "In a fixed price project the consultancy carries the risk of overrunning, so the scope must be written tightly and every change goes through a change request. On time and materials the client pays for the hours worked and carries more of the risk, so the client needs frequent reports of progress and spending."

The full answer: Many contracts mix the two: discovery on time and materials, then a fixed price for the build once the scope is clear. Either way, the statement of work, the document that says what will be delivered, by when and under which assumptions, is what both sides return to when they disagree.

A weak answer: "It makes no difference to my work." Follow-up: "You are halfway through a fixed price project and the effort is over plan." Say what you raise and with whom.

Two weeks before go-live, a client asks for something outside the scope. How do you handle the change request?

What they check: calm control of scope without damaging the relationship.

Short answer: "I thank them and write the request down, then work out its effect on the date, the cost and the risk to go-live. I offer options: do it after go-live, swap it for something of the same size, or move the date. The client decides in writing through the change request."

The full answer: Late changes are where projects fail, so the change process should be agreed at the start and used for small changes too, so it is normal and not a confrontation. Say yes to the need and be clear about the price of doing it now. A short list of post-go-live items shows the client their request is not forgotten.

A weak answer: "I just add it; the client is always right." Follow-up: "The client says it is not a change, it was always meant." Explain how the signed requirements settle it.

How do you write a proposal or a statement of work that a client can sign?

What they check: that you can turn a conversation into a clear, safe commitment.

Short answer: "I restate the client's goal in their words, then describe the approach in phases with what each delivers, the roles on both sides, the timeline, the assumptions and what is out of scope. The price follows from that. Before it goes out, someone who was not in the meetings reads it to see whether it can be misunderstood."

The full answer: The client's duties matter as much as yours: access, data, people for workshops and testing, decisions within a set time. Most disputes come from a missing assumption, so write them down. A proposal also sells the team, so name who will do the work and what they have done before.

A weak answer: "Sales writes it; I just deliver." Follow-up: "The client wants the price before discovery." Discuss a range, a paid discovery phase, or a fixed first phase.

Data, integration, testing and go-live

How do you plan a data migration from an old system to a new platform?

What they check: that you treat data as its own workstream with owners and checks.

Short answer: "I agree with the client which data moves, from which systems and how far back, and who owns each object. We clean the data in the old system first, map the fields, and run several trial loads with checks of counts and totals. The business signs off each trial, so the final load is a repeat, not a first attempt."

The full answer: Open items such as unpaid invoices or open orders need the most care, because the business runs on them on the first day. Reconcile with SQLAsked in 6% of IT consultant ads (as of 5 Nov 2026).Query the client's data yourself to check a migration, reconcile counts and answer a question in a workshop. or the platform's own tools, not by looking at a few records. Plan what happens to the old system afterwards: read only, archived, or switched off.

A weak answer: "The client exports a file and we import it." Follow-up: "The trial load shows customers with three different addresses." Say who decides which one is right.

How do you plan testing, and who should test what?

What they check: a test approach that matches the risk, with the users involved.

Short answer: "The project team tests each configured function and each interface first. Then end-to-end tests run whole processes, such as order to cash, with realistic data. Finally the users test their daily work in user acceptance testing and sign it off. Defects go into one list, such as Jira, with a priority agreed with the client."

The full answer: Write test cases from the requirements so every requirement is tested once. Users find different problems from consultants, so plan their time early; they have day jobs. Agree before testing starts what counts as ready for go-live, for example no open defects of the highest priority.

A weak answer: "We test at the end if there is time." Follow-up: "Users keep reporting change requests as defects." Explain how you sort them.

Walk us through a cutover weekend and the first weeks after go-live.

What they check: planning to the hour, a way back, and support afterwards.

Short answer: "Cutover is the switch from the old system to the new one. We follow a plan with every step, its owner and its time, rehearsed at least once: freeze the old system, final data load, checks, sign-off, open for users. A go or no-go decision is taken at set points, with a plan to fall back. After go-live, hypercare, a period of extra support, fixes problems fast."

The full answer: Hypercare usually lasts a few weeks: daily calls, a clear route for problems, consultants close to the users, and a list of issues with owners. It ends with an agreed handover to the client's own support. The first month-end close or the first big order day after go-live is the real test, so plan to be there.

A weak answer: "We switch on Monday morning and see." Follow-up: "At two in the morning the data checks fail." Say who decides and on what basis.

How do you connect the new platform to a system the client cannot change?

What they check: practical integration thinking and clear ownership.

Short answer: "First I learn what the old system can offer: files, a database view, an interface or nothing but a screen. Then we agree the data, the direction, the timing and who watches the integration when it fails. If the old system cannot change, the work happens in the new platform or in a middle layer the client already uses."

The full answer: Every integration needs an owner on each side, error handling, a way to resend data, and monitoring someone actually reads. Test it with real volumes. Agree early with the client's IT whether real-time is truly needed, because a nightly file is simpler to run.

A weak answer: "The developers will sort out the interfaces." Follow-up: "Orders sometimes arrive twice." Discuss how to make the integration safe to repeat.

How do you make sure users are trained and the client can run the system after handover?

What they check: that you leave a working organisation, not only a working system.

Short answer: "I train key users first, in their own processes and data, and they help train the rest. The guides are short and built around tasks. Before handover the client's support team takes calls with us beside them, and we agree a list of open points with owners and dates."

The full answer: A system the client cannot run comes back as unpaid support. Plan knowledge transfer from the start: the client's people join the configuration, write parts of the documentation and run a test cycle themselves. Measure it, for example by the share of tickets the client solves alone in the last week of hypercare.

A weak answer: "We send the documentation at the end." Follow-up: "The client's key user resigns a week before go-live." Say what you do.

Cloud and security

A client wants to move a system to the cloud. What questions do you ask first?

What they check: that you start from the business reason, not from a vendor.

Short answer: "Why: cost, speed, an end-of-life data centre or a new capability. Which systems and data, how they depend on each other, and what downtime the business accepts. Which cloud the client already uses, AWS, Azure or Google Cloud, and which skills its team has. Then what rules apply to the data, and who runs it afterwards."

The full answer: Lifting a system unchanged is fast but may cost more to run; reworking it takes longer and saves later. The vendor's own tools and the client's licences shape the plan. Bring in cloud and security specialists early, and keep the business owner in the decision, because the cloud bill lands on their budget.

A weak answer: "Everything goes to the cloud; it is cheaper." Follow-up: "The finance team asks why the monthly bill is higher than the old data centre." Explain what to look at.

How do you bring security and data protection into a project from the start?

What they check: that security is part of the design, not a gate at the end.

Short answer: "I ask the client's security and data protection people to the first design workshop. We agree roles and access, which personal data the system holds and why, where it is stored, and what is logged. These become requirements like any other and are tested before go-live."

The full answer: Roles and access are where most problems start: too many people with too much access because it was quicker in testing. Follow the client's own policies and, in the EU, the GDPR rules on personal data; name the open questions instead of guessing. This is a summary, not legal advice.

A weak answer: "Security is the client's IT department's job." Follow-up: "Testers need real customer data." Discuss masking and test data.

Reporting, utilisation and the senior steps

How do you report the status of a project that is going badly?

What they check: honesty, early warning and a plan.

Short answer: "I say it early and plainly: what is late, why, what it does to the date and the cost, and what I propose. A status report with green lights until the last week destroys trust. I bring options and a recommendation to the steering group, not only the problem."

The full answer: Keep the status report short and the same every week: progress against plan, the main risks with owners, decisions needed and the budget used. Name risks while they are still risks. Inside the consultancy, tell your manager before the client hears it, so the firm can help.

A weak answer: "I keep it amber and hope we catch up." Follow-up: "The client's project manager asks you to keep the report green for the board." Say what you do.

As a senior or principal IT consultant or an IT consulting manager, how do you balance utilisation, the client and your team?

What they check: that you understand the business of consulting as well as the craft.

Short answer: "Utilisation is the share of working time billed to clients, and a consultancy lives on it. I keep it healthy by planning people onto projects early, but I protect time for training and for proposals, because the next project depends on them. The client comes first in quality; the team comes first in how the work is shared."

The full answer: At senior IT consultant level you lead a workstream and coach juniors. A principal IT consultant is the expert clients ask for by name and shapes solutions across projects. An IT consulting manager runs projects and accounts: budgets, staffing, proposals and the relationship with the client's leaders. Expect a case: two clients need your best consultant in the same week.

A weak answer: "Utilisation is the partners' problem." Follow-up: "Your team is fully booked and a new proposal is due." Explain how you staff it.

Your CV for these questions

Every project on your CV invites the questions above: which platform, which phase, what you decided with the client, what went live. Give each project a line that answers one of them before it is asked:

Check your CV against an IT consultant job you want with the free score; the questions it finds thin are the ones to rehearse with a real project.