DXC Technology Interview Questions (2026): Real, With Answers

Automata Fix is a debugging exercise inside the online assessment platform (commonly AMCAT or a similar vendor). You get a handful of short programs, usually 5 to 7, each with one or more compile errors or logic bugs planted in it, and you have to find and fix them within a tight per-question time limit rather than write code from scratch.

It's testing whether you can read someone else's code quickly and reason about what it's supposed to do, which is a closer match to day-to-day maintenance work at a services company than a from-scratch algorithm problem is. The practical prep move is to spend time reading buggy snippets in whatever language you list on your resume rather than only grinding new-problem practice.

Candidates describe roughly 14 to 16 questions per section with a tight one-minute-per-question pace: percentages, ratios, time and work, and basic probability on the quant side, and number series, directional sense (the "walk 3km north, then 4km east" style problems), and syllogisms on the logic side.

None of it is advanced. The failure mode candidates report is running out of time, not lacking the math, because the per-question clock is unforgiving if you get stuck rereading a question. Timed practice matters more here than depth of content.

Reports put the essay length requirement anywhere from 100 to 400 words depending on the specific drive, written in 15 to 20 minutes on an assigned topic that's usually generic (technology's impact on society, a recent trend, a personal opinion prompt).

It's graded on structure and grammar, not on having a brilliant thesis. A clear intro, two or three supporting points, and a short conclusion, written in plain sentences without spelling errors, clears this bar. Overwriting or trying to sound impressive tends to introduce more grammar mistakes under a time crunch, which is the opposite of what the section rewards.

A constructor has no return type, not even void, and its name must exactly match the class name. It runs automatically once, exactly when an object is created with new, and its job is to set up initial state. A regular method has a return type (possibly void), can be named anything, and only runs when you explicitly call it, any number of times, including zero.

A constructor also can't be inherited the way a method can, and it can't be marked static, abstract, or final, since none of those modifiers make sense for something whose entire purpose is object initialization tied to a specific class.

Encapsulation bundles data and the methods that operate on it together, and hides internal state behind private fields with public getters and setters, a BankAccount class that only lets you change balance through a deposit or withdraw method, never directly. Inheritance lets a subclass reuse and extend a parent's behavior, a SavingsAccount extending Account and adding interest calculation. Polymorphism lets the same method call behave differently depending on the actual object, calling calculateInterest() on a list of mixed Account and SavingsAccount objects and getting different math from each. Abstraction exposes only what a caller needs and hides implementation, an interface like PaymentProcessor with a single process() method, where callers don't know or care if it's calling Stripe or an internal gateway underneath.

Overloading is having multiple methods in the same class with the same name but different parameter lists (different count, order, or type). It's resolved at compile time based on the arguments you pass. Overriding is a subclass providing its own implementation of a method already defined in its parent class, with the exact same signature, and it's resolved at runtime based on the actual object type, which is what makes polymorphism work.

class Calculator {
  int add(int a, int b) { return a + b; }
  double add(double a, double b) { return a + b; } // overload
}

class Animal {
  String sound() { return "..."; }
}
class Dog extends Animal {
  @Override
  String sound() { return "Bark"; } // override
}

INNER JOIN returns only rows where the join condition matches in both tables. LEFT JOIN returns every row from the left table, with NULLs filling in columns from the right table where there's no match. RIGHT JOIN is the mirror of that, every row from the right table, NULLs on the left where unmatched. FULL OUTER JOIN returns every row from both tables, matched where possible, NULLs on whichever side has no match.

SELECT e.name, d.department_name
FROM employees e
LEFT JOIN departments d ON e.dept_id = d.id;
-- returns every employee, even ones with no department assigned yet

WHERE filters individual rows before any grouping happens, and it can't reference an aggregate function like COUNT or SUM. HAVING filters groups after a GROUP BY has already collapsed rows together, and it's specifically built to filter on aggregate results, departments with more than 10 employees, for instance.

SELECT department, COUNT(*) AS cnt
FROM employees
WHERE status = 'active'
GROUP BY department
HAVING COUNT(*) > 10;

A table can have only one primary key, and it can't contain NULL values in any column that's part of it. A table can have multiple unique keys, and depending on the database, a unique key can allow one NULL (or in some engines, multiple NULLs, since NULL isn't considered equal to another NULL for uniqueness purposes). Both enforce that no two rows share the same value in that column or column set.

public static String reverse(String s) {
  char[] chars = s.toCharArray();
  int left = 0, right = chars.length - 1;
  while (left < right) {
    char temp = chars[left];
    chars[left] = chars[right];
    chars[right] = temp;
    left++;
    right--;
  }
  return new String(chars);
}

Two pointers moving toward each other from opposite ends, swapping as they go, is the pattern to reach for. It's O(n) time and O(n) space for the character array in Java (strings are immutable, so you can't mutate the original in place the way you could a char array or a mutable string in another language), and it's the same underlying pattern used for palindrome checks and array reversal.

public static boolean isAnagram(String a, String b) {
  if (a.length() != b.length()) return false;
  int[] counts = new int[26];
  for (char c : a.toCharArray()) counts[c - 'a']++;
  for (char c : b.toCharArray()) counts[c - 'a']--;
  for (int count : counts) if (count != 0) return false;
  return true;
}

Sorting both strings and comparing works too, but it's O(n log n). The counting-array approach is O(n) and only needs a fixed 26-slot array for lowercase letters, which is the detail that tells an interviewer you thought about the actual constraint (fixed alphabet size) instead of reaching for sort() by reflex.

Binary search is O(log n) because each comparison eliminates half of the remaining search space, so the number of comparisons needed to get down to one element is log base 2 of n. It requires a sorted array because the algorithm's core decision, "is the target bigger or smaller than the middle element, so which half do I discard", only produces a correct, reliable answer when the array's order guarantees everything on one side of the middle is uniformly smaller and everything on the other side is uniformly larger.

A process is an independent unit of execution with its own memory space, one process can't directly read another's memory without going through the OS. A thread is a unit of execution within a process, and all threads inside the same process share that process's memory space and file descriptors. Creating a new process is heavier (a full memory space to set up), spawning a new thread is lighter, since it just needs its own stack and register state while sharing everything else.

du -sh * inside a directory shows human-readable disk usage per subdirectory, and df -h shows overall disk usage per mounted filesystem. top or htop shows live CPU and memory usage per process, sorted by whichever column you tell it to sort by. ps aux gives a snapshot of every running process at the moment you run it, useful for piping into grep when you're hunting for a specific service.

IaaS gives you raw infrastructure, virtual machines, storage, and networking, and you manage the OS, runtime, and everything above it yourself (AWS EC2, Azure VMs). PaaS gives you a managed runtime environment, you deploy code and the platform handles the underlying servers, scaling, and patching (Heroku, Azure App Service). SaaS is a fully finished application you just use, no infrastructure or platform management at all (Salesforce, Office 365). Each layer up trades control for less operational burden.

Structure it in three parts and keep it under two minutes: where you are now (current role or, for a fresher, your degree and specialization), one or two concrete things you've built or contributed to that are relevant to the role you're interviewing for, and why you're interested in this specific role or company. Skip the childhood-to-present chronology, the interviewer already has your resume and is listening for how you frame your own experience, not for new facts.

Pick strengths you can back up with a specific example in one sentence each, not adjectives alone, "I'm good at debugging" backed by a quick line about a production issue you traced to a specific root cause reads far better than the adjective by itself. For weaknesses, name something real and describe the concrete thing you're doing about it, not a disguised strength like "I work too hard." A DXC interviewer specifically flagged this pattern as one they can spot instantly and don't respect.

Tie the answer to a realistic growth path inside the kind of work DXC actually does, moving from an individual contributor role into a technical lead or specialist track within a practice area, rather than a vague "management" answer or an answer that signals you see this as a one-year stopover before something unrelated. Interviewers at a large services company are partly screening for retention risk here, and an answer that shows you've thought about what growth actually looks like at a company like this reads as more credible than a rehearsed generic answer.

Candidates describe this as fundamentals-level: output-of-a-code-snippet questions in C and Java, basic data structure complexity (is a linked list search O(n) or O(log n)), normalization basics in DBMS, and process versus thread distinctions in OS. It's the kind of material covered in a second-year CS course, not advanced systems material.

The trap is C-specific quirks that Java and Python developers forget: pointer arithmetic, how printf handles format specifiers, and what a variable declared but not initialized actually prints. If C isn't your daily language, a 30-minute refresher on those specific gotchas the night before pays off disproportionately.

int arr[5] = {10, 20, 30, 40, 50};
int i = 0;
int sum = 0;
while (i < 5) {
  sum += arr[i++];
}
printf("%d %d", sum, i);

arr[i++] reads arr[i] using the current value of i, then increments i afterward, so the loop correctly touches indices 0 through 4 exactly once each. sum ends up as 10+20+30+40+50 = 150, and i ends at 5, so the output is "150 5". Questions like this are testing whether you actually trace state step by step instead of eyeballing it and guessing, since post-increment inside an index is a classic place candidates rush and get wrong.

Static methods belong to the class itself, not to any instance, and they're resolved at compile time based on the reference type, not the runtime object type. Declaring a same-signature static method in a subclass doesn't override the parent's version, it hides it. Call the method through a parent-typed reference and you get the parent's static method even if the actual object is a subclass instance, which is the opposite of what overriding is supposed to guarantee.

An abstract class can hold constructors, instance fields, and a mix of abstract and fully implemented methods, and a class can only extend one abstract class. An interface (pre-Java 8) could only declare method signatures with no body, and a class can implement any number of interfaces. Since Java 8, interfaces can carry default and static methods too, which narrowed the gap, but a class still can't have state (instance fields) through an interface.

Pick an abstract class when subclasses genuinely share common state and partial implementation, a base Shape class with a shared color field and an abstract area() method. Pick an interface when you're defining a capability unrelated classes might all support, Serializable, Comparable, where forcing a shared base class would be artificial.

Checked exceptions (IOException, SQLException) extend Exception and must either be caught or declared in a method's throws clause, the compiler enforces it. Unchecked exceptions (NullPointerException, ArrayIndexOutOfBoundsException) extend RuntimeException and the compiler doesn't force you to handle them, they typically represent programming errors rather than recoverable external conditions like a missing file or a dropped network connection.

ArrayList is backed by a resizable array, so random access by index is O(1), but inserting or removing from the middle means shifting every element after it, O(n). LinkedList is a doubly-linked list, insertion and removal at a known node is O(1), but reaching an arbitrary index means walking the list from one end, O(n).

In practice, ArrayList wins most of the time because CPU cache locality makes its sequential access much faster in real workloads than the complexity numbers alone suggest, and most collections in a typical service are read far more than they're mutated in the middle. LinkedList earns its keep specifically for a queue or deque-style access pattern where you're always adding or removing from the ends.

Normalization is organizing a schema to reduce redundant data and avoid update anomalies. First normal form (1NF) requires atomic columns, no repeating groups or comma-separated lists stuffed into a single column. Second normal form (2NF) requires 1NF plus every non-key column depending on the whole primary key, not just part of a composite key. Third normal form (3NF) requires 2NF plus no non-key column depending on another non-key column (no transitive dependency).

A concrete example: an Orders table with OrderID, CustomerName, and CustomerCity violates 3NF, because CustomerCity depends on CustomerName, not directly on OrderID. Splitting CustomerName and CustomerCity into a separate Customers table, referenced by a CustomerID foreign key, fixes it, and it means updating a customer's city once instead of hunting down every order row that customer ever placed.

An index is a separate data structure, usually a B-tree, that stores a sorted copy of one or more columns' values alongside a pointer back to the full row, so the database can find matching rows without scanning the entire table. It turns a WHERE clause on that column from an O(n) full table scan into roughly O(log n).

The tradeoff is write cost: every INSERT, UPDATE, or DELETE has to update every index on that table too, so a table with heavy write traffic and five unnecessary indexes pays that cost on every single write for read speed it may never actually use. Indexing the columns you actually filter and join on, and skipping the rest, is the real skill, not indexing everything.

SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

This works because the subquery finds the true maximum, then the outer query finds the maximum of everything strictly less than that, which is exactly the second-highest value. It handles duplicate salaries at the top correctly too, since WHERE salary < max excludes every row tied for first place, not just one of them. The alternative with DENSE_RANK() OVER (ORDER BY salary DESC) is worth mentioning as the more general solution if the interviewer asks for the Nth highest instead of specifically the second.

public static int findMissing(int[] arr, int n) {
  int expectedSum = n * (n + 1) / 2;
  int actualSum = 0;
  for (int num : arr) actualSum += num;
  return expectedSum - actualSum;
}

The expected sum of 1 to n has a closed-form formula, so you never need to sort or use extra space, one pass to sum the array and one subtraction gets you the answer in O(n) time and O(1) space. A candidate who reaches straight for sorting and a linear scan for the gap still gets a correct answer, but it's O(n log n) instead of O(n), which is the kind of thing worth mentioning even if the interviewer doesn't push on it.

public static boolean hasCycle(ListNode head) {
  ListNode slow = head, fast = head;
  while (fast != null && fast.next != null) {
    slow = slow.next;
    fast = fast.next.next;
    if (slow == fast) return true;
  }
  return false;
}

This is Floyd's cycle detection, the "tortoise and hare" approach: a slow pointer moves one node at a time, a fast pointer moves two, and if there's a cycle they're guaranteed to meet inside it eventually because the fast pointer is gaining exactly one node per step on the slow pointer within a fixed-size loop. No cycle means the fast pointer simply hits null and the loop exits. It's O(n) time and O(1) extra space, versus O(n) space if you tracked visited nodes in a HashSet instead.

public static int[] twoSum(int[] nums, int target) {
  Map<Integer, Integer> seen = new HashMap<>();
  for (int i = 0; i < nums.length; i++) {
    int complement = target - nums[i];
    if (seen.containsKey(complement)) {
      return new int[]{seen.get(complement), i};
    }
    seen.put(nums[i], i);
  }
  return new int[]{-1, -1};
}

A HashMap lets you check "have I already seen the number that would complete this pair" in O(1) per element, one pass, O(n) total, instead of the O(n squared) brute force of checking every pair. This is a common warm-up question specifically because there's an obvious slow answer and a slightly less obvious fast one, and the interviewer wants to see whether you find the second one on your own or need a nudge.

public static List<Integer> removeDuplicates(int[] arr) {
  Set<Integer> seen = new LinkedHashSet<>();
  for (int num : arr) seen.add(num);
  return new ArrayList<>(seen);
}

LinkedHashSet is the detail that matters here, a plain HashSet also dedupes in O(n), but it doesn't guarantee iteration order matches insertion order, which breaks the "preserving original order" requirement. That single word in the question is doing a lot of work, and missing it is an easy way to submit a solution that looks correct but fails the actual spec.

A deadlock is a state where two or more processes are each waiting on a resource the other one holds, and neither can proceed. The four necessary conditions are mutual exclusion (a resource can only be held by one process at a time), hold and wait (a process holding one resource is waiting to acquire another), no preemption (a resource can't be forcibly taken away, it has to be released voluntarily), and circular wait (a cycle of processes each waiting on the next one's resource). Breaking any single one of these four conditions is enough to prevent a deadlock, which is why most practical fixes target just one, ordering resource acquisition consistently to eliminate circular wait, for instance.

ls -l lists directory contents in long format. Reading left to right: file type and permissions (a leading d for directory or - for a regular file, followed by read/write/execute permissions for owner, group, and others), number of hard links, owner username, group name, file size in bytes, last modification timestamp, and finally the filename. A permission string like -rwxr-xr-- means the owner can read, write, and execute, the group can read and execute, and everyone else can only read.

TCP is connection-oriented, guarantees ordered and reliable delivery through acknowledgments and retransmission, and does congestion control. UDP is connectionless, sends packets with no delivery guarantee and no ordering guarantee, but has far lower overhead per packet since there's no handshake or acknowledgment tracking.

UDP is the right call when occasional packet loss is tolerable and low latency matters more than perfect delivery, live video or voice calls where a dropped frame is better than a frozen one waiting for a retransmit, DNS lookups where the client just retries if it times out, and some multiplayer game state updates where a slightly stale position update is fine because a newer one is already on the way.

A container packages an application with its dependencies and shares the host machine's kernel, isolated at the process level through namespaces and cgroups, which makes it lightweight and fast to start, typically seconds. A virtual machine virtualizes an entire hardware stack and runs its own full guest OS on top of a hypervisor, which is heavier and slower to boot, typically minutes, but gives stronger isolation since a VM doesn't share a kernel with the host or other VMs.

docker run -d -p 8080:80 nginx
# starts an isolated nginx process sharing the host kernel, ready in ~1 second

Docker packages and runs a single container. Kubernetes orchestrates many containers across many machines: it decides which node runs which container, restarts a container automatically if it crashes or fails a health check, scales the number of replicas up or down based on load, and handles rolling deployments so you can update an application without downtime by gradually replacing old container instances with new ones.

Running one container on your laptop, plain Docker is all you need. Running a service across a fleet of servers that needs to survive individual machine failures and handle traffic spikes, that's the gap Kubernetes fills.

Continuous integration means merging code changes frequently, with an automated build and test suite running on every merge to catch integration problems early instead of at a big-bang release. Continuous delivery extends that by automatically producing a release-ready build after every successful pipeline run, but a human still clicks a button to actually release it to production. Continuous deployment goes one step further and skips the manual approval, every change that passes the pipeline goes straight to production automatically.

Most enterprise environments, DXC's client base included, land on continuous delivery rather than full continuous deployment, because a change-control process or a client's own release calendar usually requires a human approval gate before production, even when the pipeline itself is fully automated.

A generic "great culture and growth opportunities" answer is what nearly every candidate says and it doesn't differentiate you. A stronger answer names something specific: DXC's scale in managed IT services and enterprise cloud migrations across industries most companies never touch directly, insurance, banking, government contracts, and connects that to what you actually want next, exposure to large legacy-modernization projects, working across a genuinely broad client base rather than one product, or a specific practice area (cloud, applications, security) that matches your background.

Pick a real disagreement with a concrete outcome, not a hypothetical or a story where you were obviously right and everyone else was obviously wrong. Explain the actual technical tradeoff both sides saw (a shortcut versus a more maintainable approach, for example), how you brought data or a specific example to the conversation instead of just repeating your opinion louder, and what actually happened, including if you were the one who ended up changing your mind. Interviewers are listening for whether you can hold a technical position under pushback without becoming inflexible or folding immediately.

This one is asked specifically because DXC's work is heavily client-delivery-driven, unlike a pure product company. The answer that lands well acknowledges you'd first clarify scope and identify what's actually driving the deadline (a hard external commitment versus an arbitrary internal target), then communicate tradeoffs early and in writing rather than silently working overtime or silently missing the date without warning anyone. Naming a specific example, even a small one, of flagging a risk early and proposing a scope cut or phased delivery instead of overpromising, is far stronger than a general statement about "communication being important."

Separate "we" from "I" explicitly. Name the specific component, feature, or bug you owned end to end, what the actual technical challenge was, and one decision you made that someone else on the team might have made differently. A candidate who can only describe the project at the level of "we built a web app for X" without being able to point to a specific piece they personally owned reads as having padded a group project onto their resume rather than genuinely contributed to it.

Have one specific, real bug ready, not a hypothetical. Describe the symptom first (what broke, an exception, wrong output, a slow endpoint), the investigation steps in order (reading a stack trace, adding logging, using a debugger to step through, checking recent commits), and the actual root cause once found, not just "I fixed it." A candidate who can only offer "I just fixed bugs when they came up" without a specific story is a strong signal to an interviewer that the resume line is thinner than it looks.

Name the actual platform (AWS, Azure, GCP) and a specific service you've used hands-on, not a list of buzzwords. "I deployed a Node app on an EC2 instance behind an Application Load Balancer for a college project" is a complete, credible answer. "I know cloud computing" with no follow-up detail available is the answer that gets an interviewer to stop asking and mentally discount that entire line of the resume, which candidate reports suggest happens specifically when this question gets asked and the candidate can't go one level deeper.

When the increment is the only thing happening in that statement, ++i and i++ produce the same end state for i, the difference only shows up when the expression's value is used somewhere else in the same statement. arr[i++] uses the old value of i as the index, then bumps it. arr[++i] bumps i first, then uses the new value as the index. Swap one for the other inside a loop and you can skip index 0 entirely or run one iteration short, off-by-one bugs that pass a quick visual read and fail on the exact edge cases a debugging round is built to catch.

By default, Object's equals() compares reference identity (are these the exact same object in memory) and hashCode() returns a value based on the object's memory address. If you override equals() to compare field values (two Person objects with the same name and id count as equal) but leave hashCode() untouched, you break the contract that equal objects must have equal hash codes.

The practical failure shows up in a HashMap or HashSet: two logically-equal Person objects can land in different buckets because their hash codes differ, so a lookup with a "new" but equal key won't find the entry you already put in, even though equals() would return true if you compared them directly. Every IDE that generates equals() also generates hashCode() for exactly this reason, and skipping one while writing the other by hand is a common, hard-to-spot bug.

A transaction is a group of one or more SQL statements executed as a single unit, either all of them succeed or none of them take effect. Atomicity guarantees that all-or-nothing behavior. Consistency guarantees the database moves from one valid state to another, no constraint gets violated partway through. Isolation guarantees that concurrent transactions don't see each other's uncommitted intermediate state (though the exact degree of isolation depends on the isolation level set, read committed, repeatable read, serializable). Durability guarantees that once a transaction commits, it survives a crash, typically because it's already been written to a transaction log on disk.

A classic example is a bank transfer: debiting one account and crediting another has to be one transaction, because a crash between the debit and the credit, without atomicity, would either lose money or create it out of nowhere.

public static boolean isValidBST(TreeNode node, Long min, Long max) {
  if (node == null) return true;
  if (min != null && node.val <= min) return false;
  if (max != null && node.val >= max) return false;
  return isValidBST(node.left, min, (long) node.val)
    && isValidBST(node.right, (long) node.val, max);
}

The common mistake is checking only that a node's immediate left child is smaller and immediate right child is larger, which misses violations further down the tree, a left grandchild that's larger than the root even though it's smaller than its direct parent. Passing a running min and max bound down through the recursion, tightening it at every level, is what actually enforces the BST property across the whole subtree, not just one level at a time.

Infrastructure as code means defining servers, networks, and other infrastructure in version-controlled configuration files (Terraform, CloudFormation, Ansible playbooks) instead of clicking through a console or SSHing in and running commands by hand. Applying that same file reliably recreates the identical environment, whether that's a fresh dev environment, a disaster-recovery region, or scaling a staging environment to match production.

The problem it solves is configuration drift, the slow accumulation of undocumented manual changes across servers that eventually makes environments subtly different from each other in ways nobody can fully account for. With infrastructure as code, the config file is the single source of truth, and a diff between two environments' Terraform state is something you can actually inspect instead of hunting through servers by hand to find what changed.

This question is really testing whether you've kept learning since finishing the project or treat it as a closed chapter. A strong answer names one specific architectural or technology choice you'd change now, and explains what you learned since that makes the original choice look worse in hindsight, switching a monolithic script to a proper layered structure, adding tests you skipped under a deadline, or picking a database that actually matched the access pattern instead of the one you were most familiar with at the time. "Nothing, it worked fine" is the answer that suggests you haven't grown past that project.

Start with what changed recently, a deploy, a config change, a traffic spike, a dependency's status page, before touching anything, since most production incidents trace back to a recent change rather than a random failure. Pull logs and metrics around the exact timestamps of the failing requests specifically, not just a general "look at the dashboard," correlating error spikes with CPU, memory, connection pool exhaustion, or a downstream dependency's latency.

Intermittent, not constant, points toward resource exhaustion under load (a connection pool or thread pool maxing out under a spike, then recovering once load drops) or a race condition rather than a straightforward code bug that would fail every time. Reproducing it in a lower environment under similar load, if you can, beats guessing from production logs alone, since production incidents under time pressure tend to get patched with the first plausible fix rather than the actual root cause if you skip that step.