How a machine-coding round works

Some product companies run a round where you write working code for a small problem, such as a parking lot. They run your code and then change a rule. Time and scoring differ by company, so ask at the start.

A weak candidate designs for too long, or codes without a plan. A strong one asks questions, runs a simple version early, and keeps the code ready for a new rule.

Think about a one-day market. You must build a small stall and sell something before the market closes. A pretty stall that sells nothing fails. A stall that breaks when the owner asks for one change also fails.

A machine-coding round gives you one small problem, a fixed time and an editor. You write code that runs, with no database and no web server. Everything stays in memory. A requirement is a rule the code must follow. The core is the main rules from the problem statement. After the core, the interviewer adds one new requirement, and you change your code to match it.

The Tradeoff practice round is the example here. It plans 75 minutes and stops at 90. It has five steps. The times are upper limits:

The Tradeoff scoring has six parts. These are the weights out of 100:

• Clarifying requirements: 10
• Object design (each class has one clear job): 25
• Working code (hidden tests on your code): 25
• Extensibility (the new requirement fits in a small change): 20
• Code quality (clear names, short methods): 10
• Communication (short, clear steps): 10

What to build first: the thinnest path that runs from start to end. For a parking lot, that is "park a car" and "leave and pay". Run it. Then add edge cases, such as a full lot or an unknown ticket. Do not build what nobody asked for, such as a database or a screen.

A parking lot. Assumption: the round is 75 minutes.

A good plan.

The steps add up: 10 + 15 + 15 + 15 + 15 + 5 = 75.

The predict box. 75 - 10 - 40 = 25 minutes remain. The good plan gives code, new requirement and wrap-up 30 + 15 + 5 = 50 minutes. With only 25, you may never reach the new requirement. It is worth 20 of the 100 points.

A score. Assumption: a candidate passes 9 of 11 core tests, which gives 9 / 11 x 100 = 82 (rounded). The other scores are made up: clarifying 60, design 70, extensibility 80, code quality 70, communication 60. Each score is multiplied by its weight: 600 + 1,750 + 2,050 + 1,600 + 700 + 600 = 7,300. Divide by 100: 73.

A thin version first solves the risk of having nothing to show. It costs some tidiness, which you fix as you go. I would change the order if the interviewer asks for a design talk before any code.

"Design everything first, then code." The round gives 15 minutes to class design. After 40 minutes of design, only 25 minutes remained.

"More features give more points." The tests check what the statement asks. An unasked database takes minutes and earns nothing.

"My examples work, so I am done." The tests also try a full lot and an unknown ticket.

1. Name the five steps of the round in order.
2. A round is 80 minutes. You plan clarify 8, design 12, code 35 and wrap-up 5. How many minutes are left for the new requirement? If you skip it and earn 0 points for that part, what is the best total score, with the weights above?
3. At minute 30 of 75 your class drawing is perfect, but nothing runs. What do you do?