The coding round: what to expect and how to practice

In most technical drives, the coding round is where a campus shortlist becomes a real one. You are given one to three problems, a time limit and an editor in a language of your choice, and your code is run against test cases you cannot see. It is the round students fear most and prepare for least well, usually by reading solutions instead of writing them.

What the round looks like

Patterns differ by company, but the shape is common. Each problem describes a task and an input and output format, gives a sample or two, and then runs your submission against a set of hidden test cases. Your score depends on how many of those hidden cases pass. The common languages are allowed almost everywhere: C, C++, Java and Python in nearly every test, often more.

Some tests show you only pass or fail per case, and some show nothing until the end. Plan for the version that shows nothing: test your own code before you submit.

What the hidden tests are looking for

The visible samples are there to explain the problem. The hidden cases are there to find the ways your solution is wrong. They almost always include:

• The edge cases: empty input, a single element, all elements the same, negative numbers, the largest values allowed
• Large inputs, which fail a solution that is correct but too slow
• Formatting, since an extra space or a missing newline can fail an otherwise correct answer

Read the constraints before you design anything. If the input can hold a hundred thousand elements, a solution that compares every pair will time out, and the constraints are telling you so.

A solution that passes the samples has told you it understood the example. The hidden tests find out whether it understood the problem.

The topics that come up

Most campus coding rounds draw on a stable core: arrays and strings, hashing, sorting and searching, recursion, two pointers and sliding windows, stacks and queues, and basic trees and graphs. Dynamic programming appears in harder drives. You do not need every trick in every topic; you need to recognise which of these a problem is really asking for.

How to practice

• Solve problems yourself first, for at least twenty minutes, before looking at any solution
• Write the brute force first, make it correct, then improve it; a working solution earns marks, a clever unfinished one does not
• Before submitting, write down three test cases of your own that the samples do not cover, and run them
• Practice in the same language and a similar editor to the test, so the tools do not slow you down
• Practice explaining your solution out loud: why this approach, what it costs, where it breaks, because the interview that follows will ask

On the day

Read all the problems first and start with the one you are surest of. Get a correct answer submitted before you optimise anything. If you are stuck, submit the brute force; partial marks from the hidden cases it passes are worth more than a blank. Leave a few minutes at the end to check the output format.

The short version

The coding round runs your code against hidden tests that look for edge cases and slow solutions. Read the constraints, solve problems yourself before reading solutions, test your own code with cases the samples miss, and practice explaining what you wrote. If your college uses Assessly, the practice library marks your code against hidden tests the same way, and the Learn tracks cover the core topics in order.