We review code here, so we like to see our candidates do it too. Here's an exercise in code review, which we expect to take about 2 hours.
We spun up a small application that lets utilities sign up to control devices. A utility administrator fills out a form; then we track the utility name, the type of devices they can control, and the type of control they can exert.
This is very exciting! But to actually control these devices we need to actually have them in our system. So an enterprising junior developer, Alex, has written some code for us to track devices with.
They worked on this for a few weeks, then submitted the PR about a week ago with this description:
This code makes it so that we can track devices in our system. Happy to receive any feedback!
A senior developer, Sasha, reviewed it a few days later, with this note:
Hi Alex, good start, but this code isn't up to our standards. I have to run but will provide more details later.
Sasha never followed up. Now both of them are out of the office, and Alex will be returning tomorrow.
Product wants these changes made ASAP, so now you're reviewing this code in an attempt to unblock Alex.
The code is expected to:
- allow people to add devices
- which are associated with utilities and device types
- validate input
- allow people to view devices
- what the utility is
- what the device type is
We're not worried about user authentication or authorization right now, and we certainly don't have to be able to send controls to these devices.
Please review the difference between the devices
branch and the main
branch as if a real junior developer submitted these changes.
We understand that this is a little bit different from the typical code review tooling - we suggest writing your comments as literal code comments and submitting the output of git diff
.
You'll be graded on:
- technical knowledge
- communication skills
- process guidance
Of course, if you run into any questions, please ask! We'll be happy to answer.
You can get the code here.