DXC Technology Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about DXC: it hires in volume, so the online test is the real filter.

• Most candidates are eliminated before any human talks to them.
• A recruiter is not reading answers one by one. A scoring engine checks whether you crossed a sectional cutoff.
• Clear the test comfortably, not just barely, and your interview odds jump sharply.
• By then you are competing against a much smaller pool, and a human who wants to fill a seat.

2Getting the call (the part most guides skip)#

For a mass recruiter, getting the call is less about a golden referral and more about being in the right funnel and surviving the first automated gate.

• There is no one you can message to skip the test.
• Your energy is better spent on eligibility and a resume that parses cleanly.

Campus vs off-campus.

• If your college has a DXC drive, that is the easiest path by a wide margin. The eligibility bar is pre-negotiated and slots are reserved.
• Register the moment your placement cell opens the slot. These fill fast.
• The bar is commonly around 60% or 6.0-6.5 CGPA across 10th, 12th, and degree, with a cap on active backlogs (often zero at the time of the drive).
• Off-campus, watch the DXC careers page and trusted job boards, and apply to the exact fresher listing with the correct graduation year.
• Apply to a 2024 req when you are a 2026 grad and the filter auto-rejects you.
• Many drives run through a named assessment partner, so you may register on a testing platform rather than only on DXC's site. Read the invite email for which platform and which window.

Resume rules.

• One page. No photo, no "references available on request," no fluffy objective paragraph.
• Lead with a short skills line, then projects, then education.
• Every project bullet answers three things in one line: what you built, the stack, and the result.

Compare these two bullets:

• Weak: "Made a website using HTML and CSS."
• Strong: "Built a responsive student-attendance web app (React + Node + MySQL) used by 40+ classmates; cut manual roll-call time from 10 minutes to under 1."

Why the strong one wins:

• It names a stack a parser can index.
• It gives a number.
• It shows the thing actually got used. The weak one could be a tutorial you followed for an afternoon.

ATS keywords. The resume is parsed by software before a human sees it, so the words have to literally be present.

• Mirror the words in the job post: your language (Java / Python / C++), SQL, data structures, OOP, Git, and your frameworks.
• Do not keyword-stuff a hidden white-text block. Parsers and recruiters both catch it.
• Make the true skills appear in plain words inside your projects and skills sections.
• If the post says "SQL" and your resume only says "MySQL," add SQL too.

How people actually get shortlisted at DXC:

• Clear the online test.
• Have a resume that survives parsing.
• Match the basic eligibility.

There is no secret trick and no backdoor. A clean profile and consistency are all it takes to reach the interview.

3The loop at a glance#

Treat this as the typical shape, not a guarantee.

• Round names and the exact split vary by drive and by the assessment partner used that cycle.
• Do not panic if your invite labels things differently or merges aptitude and coding into one timed sitting.

One thing stays constant across every variant: the sectional cutoff.

• You often have to clear each section on its own, not just hit a good total.
• A brilliant quant score will not rescue a verbal section you skipped.

4The coding / aptitude rounds, patterns, not problems#

This is where most candidates are cut, so give it the most time. Put 60% of your prep hours here.

• Not because the interview does not matter.
• Because you never reach the interview if you miss the cutoff.
• The cutoff is a timer problem as much as a knowledge problem.

Quantitative aptitude. The standard services-test menu:

• Percentages, ratio and proportion, profit and loss, averages.
• Time-speed-distance, time and work, simple and compound interest.
• Permutations and combinations, probability, number systems, basic algebra.
• The questions are not hard individually. The challenge is doing them fast under a timer.
• Learn the shortcuts: percentage-to-fraction conversions by heart (1/8 = 12.5%), the profit-loss successive-change formula, and basic divisibility rules. These save the seconds that decide the section.

Logical reasoning. Pattern recognition, not raw thinking:

• Series (number and letter), coding-decoding, blood relations, directions.
• Syllogisms, seating arrangement, puzzles, and data-sufficiency style items.
• Practice until you can name the type in the first three seconds, because the slow part is deciding how to start, not the arithmetic once you have.
• Seating arrangements and puzzles are the biggest time-sinks. If one is not cracking in ninety seconds, flag it and move.

Verbal ability. The section freshers underprepare and the cutoff catches:

• Reading comprehension, sentence correction, error spotting, synonyms/antonyms, fill-in-the-blanks, para-jumbles.
• For RC passages, read the question stems first so you read with a target in mind instead of memorizing the whole thing.
• Error spotting rewards knowing a handful of rules cold: subject-verb agreement, tense consistency, and preposition pairs.

Pseudo-code and programming logic. This tests whether you can read code and predict behavior, not write it:

• Expect "what does this snippet print," loop and recursion tracing, array and string manipulation, time-complexity basics, and simple output questions in C/Java-style pseudo-code.
• Know how pass-by-value versus pass-by-reference behaves.
• Know how loops terminate (off-by-one is the classic trap they set) and how operator precedence works.
• Trace with pen and paper, writing each variable's value as it changes. Do not try to run it in your head.

Coding problems. Usually one or two problems at easy-to-lower-medium difficulty:

• String reversal, palindrome check, Fibonacci, prime check, factorial.
• Counting vowels/characters, finding max/min in an array, basic sorting or searching, simple pattern printing.
• You rarely need advanced data structures.

Here is the kind of thing they ask, and the clean way to answer it:

# Problem: check if a string is a palindrome, ignoring case
def is_palindrome(s):
    s = s.lower()
    i, j = 0, len(s) - 1
    while i < j:
        if s[i] != s[j]:
            return False
        i += 1
        j -= 1
    return True

# dry-run: "RaceCar" -> True ; "hello" -> False ; "" -> True (edge case)

Read the solution, not the cleverness:

• No trick, just a two-pointer walk and a named edge case.
• That is exactly the bar they are scoring against.

How to practice.

• Do timed aptitude sets daily. Speed is a trained skill, not a talent, and it only improves with the clock running.
• For coding, pick one language and solve 60-80 easy problems until the basics are reflex and you are not googling syntax mid-problem.
• Learn the common pseudo-code tracing patterns by hand on paper, because the test often does not let you run the code.

How to win the round: manage the clock first.

• Make one fast pass marking the easy questions and bank those points.
• Skip the time-sinks and come back only if time allows.
• For coding, read the full problem and confirm the input and output format (boolean, count, or printed line?).
• Write the straightforward correct solution before you optimize anything.
• Dry-run it on one normal example and one edge case (empty input, single element, all-same values) before you submit.
• A correct simple solution beats a half-finished clever one every time on this test.

5CS fundamentals, the technical interview core#

For a fresher at DXC, the technical interview leans on core CS basics far more than hard DSA.

• The interviewer is usually a delivery engineer, not an algorithms specialist.
• They want to know you understand the building blocks of the systems you will maintain.
• Have crisp, example-backed answers for each area below.

OOP.

• The four pillars (encapsulation, abstraction, inheritance, polymorphism) with a real example for each, not just the textbook line.
• Overloading (same method name, different parameters, resolved at compile time) versus overriding (subclass redefines a parent method, resolved at runtime).
• Abstract class versus interface, and when you would reach for each.
• Why OOP over procedural for a large codebase (reuse and boundaries).
• The follow-up that trips people: "give me an example of polymorphism from your own project." Have one ready.

DBMS / SQL.

• Normalization (1NF kills repeating groups, 2NF kills partial dependencies, 3NF kills transitive ones), in plain words.
• Primary versus foreign key.
• DELETE versus TRUNCATE versus DROP (row-level and rollback-able, fast full-wipe, removes the table entirely).
• Joins (inner, left, right), and the ability to write a simple query on the spot with WHERE, GROUP BY, and a join.
• ACID properties at a high level: know what each letter stands for and one line on why it matters.

Operating systems.

• Process versus thread (separate memory versus shared memory inside one process).
• What a deadlock is and its four conditions (mutual exclusion, hold and wait, no preemption, circular wait).
• Basics of scheduling (FCFS, round robin).
• What paging and virtual memory do conceptually (let a program use more memory than physically exists).

Networking.

• OSI versus TCP/IP layers.
• TCP (connection-oriented, reliable, ordered) versus UDP (connectionless, fast, lossy).
• What happens when you type a URL and press enter (DNS lookup, TCP handshake, HTTP request, response, render).
• HTTP versus HTTPS (the S is TLS encryption).
• The URL question is a favorite because it touches DNS, networking, and web basics in one answer.

Data structures.

• Arrays versus linked lists (contiguous and O(1) index versus O(1) insert at a known node).
• Stack versus queue (LIFO versus FIFO).
• What a hash table buys you (average O(1) lookup).
• When you would use a tree (ordered or hierarchical data).
• State the Big-O for common operations without hesitating.

Your project.

• Expect "explain your project" early, then why you chose that stack, the hardest part, and what you would improve with more time.
• Know your own code cold. This is the easiest place to shine and the easiest to get caught bluffing.
• The interviewer can keep asking "and how does that part work?" until you hit a wall.
• If a teammate wrote a module, say so and explain what you do understand about it.

6Behavioral & culture fit#

DXC's public values center on delivering for customers, caring for people, doing the right thing, and working better together (its stated commitments around colleagues, clients, communities, and conduct).

• You do not need to recite them like a slogan. That reads as rehearsed.
• Your answers should echo the spirit: reliability, teamwork, integrity, and a service mindset.

Why the HR round matters more here than at a product company:

• DXC is a services company. Its product is people who show up and deliver for a client week after week.
• The round checks whether you are that kind of person.
• It tests communication, honesty, flexibility (shifts, relocation, the bond or service agreement some offers include), and whether you will stay and grow rather than treat this as a placeholder while you hunt elsewhere.

Prep 4-5 STAR stories (Situation, Task, Action, Result) you can adapt to almost any question:

• A team conflict.
• A tight deadline.
• A failure you learned from.
• A time you helped someone.
• A time you had to learn something fast.
• Five flexible stories beat twenty memorized answers.

Worked STAR example, "Tell me about a tight deadline."

• Situation: Our 4-person final-year team had a working prototype but the demo was moved up by five days.
• Task: I owned the backend API and it wasn't done.
• Action: I listed the must-have endpoints, cut two nice-to-have features, paired with a teammate to parallelize testing, and set a nightly 15-minute check-in so blockers surfaced fast.
• Result: We shipped all core features one day early, demoed with zero crashes, and scored 9/10, the highest in our batch of 12 teams.

What makes that answer land:

• The result ends on a number. "It went well" is not a result. "Scored 9/10, highest of 12 teams" is.
• The action is specific: cut scope, paired for testing, daily check-in.
• Vague actions ("I worked really hard") tell the interviewer nothing.

In a services role, being understood is half the job. A right answer nobody can follow scores like a wrong one.

7Your prep plan#

4-week plan

• Week 1: Aptitude fundamentals, one topic per day, 30 timed questions each.
• Week 2: Pseudo-code tracing plus 40 easy coding problems in your main language.
• Week 3: CS core (OOP, DBMS, OS, CN). Write one-line definitions and examples for each.
• Week 4: Full-length mock tests, polish 5 STAR stories, rehearse "tell me about yourself" and your project out loud.

2-week plan

• Days 1-4: Aptitude speed drills (quants, reasoning, verbal), daily timed sets.
• Days 5-8: Pseudo-code plus 50 easy coding problems, dry-run each.
• Days 9-11: CS fundamentals flashcards; master your resume projects.
• Days 12-14: Two full mock tests plus HR answer rehearsal.

2-day crash plan

• Day 1 AM: 2 timed aptitude sections. PM: 20 easy coding problems plus pseudo-code output drills.
• Day 2 AM: Speed-review OOP/DBMS/OS/CN one-liners and your projects. PM: write 4 STAR stories, rehearse intro and project aloud, sleep early.

The one rule for any plan: do at least one full-length timed mock before the real thing.

• The first time you feel the clock pressure should not be on test day.
• It should be in your bedroom, where a bad score costs nothing.

8Why people get rejected at DXC#

1. Failed the cutoff on the online test. Ran out of time on aptitude and never reached a human. This is the single biggest cause, and it is a pacing failure, not an intelligence one.
2. Memorized definitions they couldn't explain. Recited "encapsulation is data hiding" but froze when asked for an example from their own code.
3. Didn't know their own project. Couldn't explain the code or the stack choices on the resume, which reads as either copied work or padding.
4. Weak communication. Correct answers delivered so unclearly the interviewer couldn't follow. In a services role, being understood is part of the job.
5. Dishonesty. Overstated skills or experience and got exposed under light questioning. One caught lie poisons the whole interview.
6. Rigid on logistics. Said a flat no to shifts, relocation, or the service agreement without discussion, which reads as low commitment for a role where clients and locations change.

9The offer, comp & negotiation#

What to expect in the package:

• Fresher offers in India typically land in the Rs 3.5-7 LPA range.
• Many entry roles sit near Rs 4-5 LPA, depending on role band, any skill premium, and location.
• Usually a fixed base plus standard benefits (PF, insurance).
• Large joining bonuses and stock are not typical at the fresher level, so do not go in expecting equity.
• Some offers include a service agreement or bond clause: you commit to stay a set period or repay a training cost if you leave early. Read it carefully, and ask exactly what triggers it and what the amount is.

Negotiation tips:

1. For a standard campus or fresher band, the number is often fixed by a pre-set grid, so push on role and location fit more than on salary. A better first project or a city you actually want to live in can matter more to your early career than an extra Rs 20k.
2. If you hold a competing offer, state it politely and factually, with the number. That is your only real leverage as a fresher, and it only works if the other offer is genuine.
3. Get the offer and any bond terms in writing, and confirm the joining timeline and probation details before you accept. A verbal "we'll sort it later" is not something you can hold them to.

Want this turned into a personalized, dated prep schedule that counts down to your DXC test day? Build your own week-by-week plan from the steps above and start with the first timed aptitude set today.