Mock Contest 3 -- Speed Round

Time limit: 1.5 hoursTarget audience: Codeforces 1000-1500

In a real contest, solving A-C fast gives you more time for D-E. This round trains your autopilot. Eight implementation-heavy problems, no deep algorithms -- just clean, fast, bug-free coding.

If you can't solve a 1000-rated problem in 8 minutes, the bottleneck isn't your algorithm knowledge -- it's your coding fluency.

Set a timer. Go.

Quick Revisit

• Eight implementation-heavy problems (rated ~800 to ~1200) — no deep algorithms, just fast and bug-free coding.
• Focus areas are hidden behind collapsible blocks below; if the file is being used as a timed simulation, do not expand them until stuck.
• Targets total 74 min, leaving a 16-min buffer in the 90-min window. Speed contests are not about using every minute; they are about creating time for the hard problems.
• Prerequisite: Speed Drills.

Problems

#	Problem	Expected Difficulty	Time Target
A	CF 1A -- Theatre Square	800	5 min
B	CF 1560B -- Who's Opposite?	800	5 min
C	CF 1433C -- Dominant Piranha	900	8 min
D	CF 1512C -- A-B Palindrome	1100	12 min
E	CF 1520D -- Same Differences	1200	12 min
F	CF 1462C -- Unique Number	1100	10 min
G	CF 1547C -- Pair Programming	1100	12 min
H	CF 1559B -- Mocha and Red and Blue	1000	10 min

Focus Areas (open only when stuck)

Problem A focus

Math — ceiling division.

Problem B focus

Math — circular table positions.

Problem C focus

Array processing — find a strict neighbor.

Problem D focus

String — greedy palindrome construction.

Problem E focus

Math — transform a[i] - i and count equal pairs.

Problem F focus

Greedy — pick the largest digits first.

Problem G focus

Simulation — merge two action sequences.

Problem H focus

Greedy — fill blanks to avoid adjacent duplicates.

Diagnostic Read-out

Speed-round results are noisy on a single sitting; treat the table as a diagnostic.

Problems Solved (in time)	Diagnostic	Where to focus next
1-3	Reading or debugging is consuming most of the time	Drill Tier 1 Speed Drills and re-rerun this mock
4-5	Decent speed but Div 2 A-C will still leak time	Specific focus on whichever category was slowest below
6-7	Strong autopilot for Div 2 A-C territory	Move on to deeper problems; speed is not the bottleneck
All 8	Implementation speed is no longer the limiting factor	Bottleneck is algorithm knowledge, not coding

Speed Benchmarks

Track your actual times versus targets:

#	Target	Your Time	Delta	Notes
A	5 min
B	5 min
C	8 min
D	12 min
E	12 min
F	10 min
G	12 min
H	10 min
Total	74 min			16 min buffer

Post-Contest Reflection

After the timer ends, answer in your Mistake Journal:

1. Where did you lose time to bugs vs thinking? If you knew what to do but kept getting WA, your coding hygiene needs work. If you stared at the problem, your pattern recognition needs work.
2. Which problem type was slowest? String manipulation? Math? Simulation? That's your drill target.
3. Did you read problems carefully? Speed-round mistakes often come from misreading constraints or edge cases.
4. Copy-paste vs fresh code: Did you write each solution from scratch, or did you have a template? For speed rounds, having a solid template matters.
5. Edge cases: Which edge cases burned you? Off-by-one? Empty input? n=1? Add them to your pre-submit checklist.

Detailed Walkthrough (read after attempting)

Problem A -- Theatre Square

Cover an nxm rectangle with axa tiles. Answer: ceil(n/a) x ceil(m/a). Use integer ceiling: (n + a - 1) / a. Common mistake: integer overflow -- use long long. Also, don't use floating-point ceil.

Problem B -- Who's Opposite?

People sit in a circle. Given positions a and b are opposite, the total count is 2x|a-b|. Then check if c is valid (1 <= c <= total), and compute opposite as (c - 1 + total/2) % total + 1. Common mistake: not validating that a, b, c are all <= total.

Problem C -- Dominant Piranha

The dominant piranha must be non-minimum (so it can eat a neighbor). Find any element that is not the global minimum and is adjacent to a strictly smaller element. If all elements are equal, output -1.

Simpler: find any element that has a strictly smaller neighbor. If all equal, -1. Common mistake: overcomplicating -- just find any max element adjacent to a non-max element.

Problem D -- A-B Palindrome

Fill '?' characters in a string to make it a palindrome with exactly a zeros and b ones. Process from both ends: if one side is fixed, the other must match. Then fill remaining '?' pairs. Handle the middle character of odd-length strings separately. Common mistake: not checking feasibility after filling -- verify final counts match a and b.

Problem E -- Same Differences

Count pairs (i,j) where a[j] - a[i] = j - i, i.e., a[i] - i = a[j] - j. Transform: let b[i] = a[i] - i. Count pairs of equal elements in b using a hash map. Common mistake: counting ordered vs unordered pairs -- use countx(count-1)/2 or accumulate as you go.

Problem F -- Unique Number

Find the smallest number with distinct digits summing to x. Greedily pick the largest digits first (9, 8, 7, ...) to minimize the number of digits, then reverse to get the smallest number. If x > 45 (sum of 1..9), output -1. Common mistake: forgetting that digits must be distinct (no repeated digits).

Problem G -- Pair Programming

Two developers with action sequences. Action 0 = add a line, action > 0 = edit line #action. Merge the sequences maintaining relative order within each, ensuring edits only happen after enough lines exist. Greedily pick the action that's valid now -- prioritize 0s (adds) when both are available. Common mistake: not greedily prioritizing adds -- you need lines to exist before editing them.

Problem H -- Mocha and Red and Blue

Fill '?' in a string of 'R', 'B', '?' to minimize adjacent same-color pairs. Process from right to left (or left to right): each '?' becomes the opposite of its already-determined neighbor. If both neighbors are '?', defer. Common mistake: processing in the wrong order -- process from any fixed character outward, or do two passes.

---

See also: Mock Contest 1 | Mock Contest 2 | Mistake Journal | Speed Drills