How DXC Technology fresher interviews usually run, campus and off-campus. Patterns shift by year and role, so treat this as a prep map, not a script.
DXC Technology is a large US-headquartered IT services company - infrastructure and cloud, applications, security, analytics and engineering, plus a substantial insurance software business - with major India delivery centres in Bengaluru, Chennai, Hyderabad, Noida, Mumbai and Pune. Fresher roles are usually titled Associate Professional or Associate Software Engineer.
Profile: B.Tech CSE, ~7.6 CGPA, no internship, steady aptitude practice
Online assessment
A webcam-monitored test of roughly 100 minutes with several short, separately timed sections: English verbal ability, logical reasoning, quantitative aptitude, computer fundamentals, and a written essay.
No negative marking, but once a question was submitted it could not be revisited - so guessing beat leaving blanks.
The essay section surprised several candidates. Plan two minutes, write four short paragraphs, keep the grammar clean.
Technical interview (~35 min)
Everything on my resume was fair game: the academic project, what I personally built, and why I chose the stack.
Which language are you most comfortable with, and why that one?
OOPs basics - inheritance, polymorphism, and an example from my own code.
A simple DSA question described verbally rather than coded on a shared screen.
HR (~20 min)
Why DXC, relocation flexibility, and comfort with rotational shifts.
A situational question about handling a deadline slip.
Result: Selected, letter of intent first, formal offer later What helped: Aptitude practice. The interview was fundamentals-level, but the assessment cut a large fraction of the batch.
Takeaways
What decided it: Clearing the multi-section OA (including the surprise essay), then defending resume OOP and a verbal DSA prompt before shift-flexible HR
Common fail: Leaving blanks instead of educated guesses when sections cannot be revisited, or skipping essay practice
How to practise: Timed AMCAT-style sections with no revisit; 4-paragraph WriteX drafts; 60-second project ownership stories
Experience 2: on-campus with two technical rounds (2024)
Profile: B.Tech CSE, ~8.0 CGPA, one internship, average coding practice
What differed
The assessment ran about two and a half hours on a different platform: arithmetic aptitude, cognitive MCQs, an English communication section, pseudo-code problems, and two coding questions that were genuinely easy.
Two technical interviews rather than one. The first (about 45-50 minutes) covered my language of choice, OOPs, some cloud-computing awareness, project decisions, and career goals. The second (about 30 minutes) was OS and DBMS theory, what I knew about DXC, and a question about a conflict in a group project.
The process was slow - roughly a month between rounds. Several classmates assumed they had been rejected and stopped preparing.
Mistakes that hurt other candidates
Not being able to explain a resume project beyond the tech-stack list
No answer at all to “what does DXC do?”
Treating the gap between rounds as a rejection
Result: Selected after the second technical round and HR Takeaway: DXC panels reward honesty and clear fundamentals over rehearsed depth. Interviewers were reported as friendly and fine with “I don’t know, but here’s how I’d approach it.”
Takeaways
What decided it: Easy coding OA plus two technicals covering language/OOP/cloud awareness, then OS/DBMS and honest “What does DXC do?” answers
Common fail: Stopping prep during the month-long gap, or blanking on company basics and group-project conflict stories
How to practise: Keep revising between rounds; draft a one-minute DXC business pitch; rehearse conflict STAR without overclaiming
Profile: B.Tech IT, ~7.0 CGPA, applied through the careers portal
What differed from the campus drive
The assessment leaned harder on computer fundamentals and pseudo-code than on coding; one short debugging block asked only for bug fixes rather than fresh solutions.
Interview 1: DBMS and SQL - joins, primary vs foreign keys - plus OS basics like process vs thread.
Interview 2 / managerial: how I would handle being staffed on an unfamiliar technology, and whether I was comfortable with client-facing support work and shift rosters.
Result: Selected after a second HR call Takeaway: For an IT services role, willingness on shifts and location is a real evaluation criterion, not small talk. Answer it honestly and early.
Profile: B.Tech ECE, C-only resume, college training programme before the drive
Online assessment
Same ~100-minute AMCAT mix: aptitude, logical, English, programming MCQs, WriteX essay, Automata Fix (seven debugging items in twenty minutes reported).
Proctoring via webcam; could not return to earlier sections.
Technical & HR (single long slot)
Intro, hobbies, family background, strengths and weaknesses.
C fundamentals because C was the only language listed: structure vs union, function pointers, static vs extern, Fibonacci algorithm and live execution in an online compiler.
Branch pivot question: “Why software as an ECE student?” - answered with self-taught projects and internship interest.
IoT and networking basics from coursework; project ownership questions.
Relocation, backlog status, day/night shift willingness, and how they prepared (aptitude daily + one language deep dive).
Result: Selected; letter of intent, then offer Takeaway: DXC panels adapt to what you put on the resume. If you claim only C, expect C drills and a live run - not abstract DSA trivia.
Experience 5: Automata Fix-heavy OA, scenario HR on Teams (2025–2026 pattern)
Failed first mock because Automata Fix was unfamiliar; spent four days on snippet debugging before the real OA and cleared with moderate aptitude scores.
Technical (~30 min): Java vs C++ choice, abstraction vs interface, polymorphism with a project example, OSI layers at a high level, thrashing, SQL LIKE and keys, ER diagram from a mini schema on the whiteboard.
HR (~25 min, MS Teams): Why DXC, relocate to Noida or Hyderabad, then scenario chain - peer conflict, handling a mistake at work, reacting to negative feedback, noisy environment during WFH.
Mistakes that hurt batchmates
Skipping essay practice (grammar errors under timer)
Listing Android on resume without being able to explain activity lifecycle basics
Result: Selected Takeaway: Scenario HR is not small talk; have short, ethical, practical answers ready. OA rewards debugging speed more than competitive programming depth.
Pre-interview checklist (DXC Technology)
Confirm whether your drive uses Automata Fix, scratch coding, or both, plus whether SVAR is listed
Practise one full 100-minute timed sit with no back-navigation
Resume audit: remove any skill you cannot defend for five follow-up minutes
Prepare letter-of-intent vs offer timeline questions - gaps of 2–3 weeks between stages are commonly reported
HR: three scenarios (conflict, error, feedback) plus relocation/shift honesty
Questions that come up often
Coding / technical
Explain your project end to end - your role, the stack, the hardest problem
Which programming language do you prefer and why?
OOPs: inheritance, polymorphism, abstraction vs encapsulation, with examples
DBMS/SQL: joins, keys, normalisation basics
OS: process vs thread, deadlock, scheduling basics
Basic DSA: arrays, strings, searching and sorting, simple recursion
Pseudo-code reading - trace the output carefully
Cloud and infrastructure awareness at a general level, for some panels
HR / behavioural
Why DXC Technology? What do you know about the company?
Relocation to a DXC India location, and comfort with rotational or night shifts
A conflict or disagreement in a group project
How you would handle being assigned an unfamiliar technology
Long-term plans and joining date
Practical tips for DXC Technology
Treat the online assessment as the main hurdle. Timed sectional practice beats last-minute topic hopping.
If your drive includes an essay section, practise writing 200-250 clean words in 20 minutes.
Know every line of your resume. The technical round almost always opens there.
Prepare a two-sentence answer to “what does DXC do?” - a surprising number of candidates have none.
Be honest about shifts and location. IT services roles genuinely need that flexibility.
If a round is followed by weeks of silence, keep preparing. Long gaps between DXC rounds are commonly reported.
HR interview
After the technical rounds, DXC usually closes with a short HR / hiring-manager conversation: motivation, location, shifts, joining date, and a couple of behavioural stories. Prepare those answers on the dedicated page rather than cramming them into this hub.
Sample answers for high-frequency questions
Use these as frames, not scripts - interviewers probe follow-ups.
Q. What are the four pillars of OOPs? A. Encapsulation bundles data and the methods that operate on it inside one class and hides internal state behind private fields with public getters and setters, so an object controls how it is mutated. Abstraction exposes only what a caller needs - an abstract class or interface declares what an object does while hiding how it does it. Inheritance lets a subclass reuse and extend a parent class, so a SavingsAccount extends Account and adds interest calculation without rewriting deposit and withdraw. Polymorphism lets one interface take many forms, either at compile time through overloading or at runtime through overriding, so calling area() on a Shape reference invokes Circle’s or Rectangle’s version depending on the actual object.
Q. What is the difference between method overloading and method overriding? A. Overloading means several methods in the same class share a name but differ in parameter count or types; the compiler picks the right one from the arguments, so it is compile-time or static polymorphism. Return type alone cannot distinguish overloads. Overriding means a subclass supplies its own implementation of a method already defined in its parent with the same signature; the JVM picks the implementation from the actual object type at runtime, so it is runtime or dynamic polymorphism. An overriding method cannot reduce visibility or throw broader checked exceptions, and the @Override annotation makes the compiler verify that you really are overriding something.
Q. What is normalization, and what are 1NF, 2NF and 3NF? A. Normalization organises tables to remove redundancy and the insert, update and delete anomalies that redundancy causes. First normal form requires every column to hold a single atomic value with no repeating groups, so three phone numbers in one cell must become three rows or a separate table. Second normal form requires 1NF plus no partial dependency - no non-key column may depend on only part of a composite primary key. Third normal form requires 2NF plus no transitive dependency, so if employee id determines department id and department id determines department name, then department name belongs in a separate department table. Reporting and analytics systems often denormalize deliberately to avoid joins, trading write-side redundancy for read speed.
Q. What is the difference between INNER JOIN and LEFT JOIN? A. INNER JOIN returns only rows where the join condition matches in both tables, so an employee with no department and a department with no employees both vanish from the result. LEFT JOIN returns every row from the left table and fills the right table’s columns with NULL where there is no match, which makes it the standard way to find missing relationships: SELECT e.name FROM employees e LEFT JOIN departments d ON e.dept_id = d.id WHERE d.id IS NULL; returns employees with no valid department. RIGHT JOIN is the mirror image, and FULL OUTER JOIN keeps unmatched rows from both sides. A common bug is putting a filter on the right table in the WHERE clause of a LEFT JOIN, which silently turns it back into an inner join - that condition belongs in the ON clause.
Q. What is the difference between DELETE, TRUNCATE and DROP? A. DELETE is a DML statement that removes rows one at a time subject to a WHERE clause, fires triggers, is fully logged and can be rolled back inside a transaction; it leaves the table structure alone and does not reset an auto-increment counter. TRUNCATE is a DDL statement that deallocates the data pages of the whole table at once, so it is far faster on large tables but takes no WHERE clause, does not fire row triggers, and typically resets the identity counter. DROP is DDL that removes the table itself along with its data, indexes, constraints and permissions. Being DDL, TRUNCATE and DROP cause an implicit commit in MySQL and Oracle, though PostgreSQL and SQL Server can roll them back inside an explicit transaction.
Tips from successful candidates
Assessment tips
Confirm the current DXC Technology pattern from the drive mail before practising old papers
Finish one problem or section fully before starting the next
Revise the fundamentals listed in the round table on this page
Interview tips
Narrate trade-offs; expect “why” after every answer
Only list projects you can defend under follow-ups
Prepare 3-4 STAR stories for behavioural prompts
HR tips
Know why DXC Technology, not just why the industry
Be clear on location / notice period / higher studies
These links are research inputs used to map DXC OA platforms, Automata Fix, and shift-focused HR - not copied page mirrors. We reorganized reports into process tables, outcome notes, and prep takeaways.