The code tests we gave was a completed project with security issues, half implemented features, completed features, and a few very badly written classes, with n

The code tests we gave was a completed project with security issues, half implemented features, completed features, and a few very badly written classes, with no tests. It was something you could wrap your head around after half an hour. Then we would provide a list of features, bugs, and “known technical debt” and ask them to tackle at least one issue. If they discovered any security issues, they were asked to fix them or at least document how they would fix them. It would take the average engineer a Saturday afternoon. During the technical interview, one of the topics was what they thought about the order of the tasks. Thus we got a window into how they thought through what was important or not important and why. There was no wrong answer, we just wanted a balance between “feature first”, “bug first”, “security first”, and “debt first” on teams.