[djstein]

I've decided I'm going to start interviewing with a set of PR's per each role we hire for. each PR will have obvious mistakes, complicated logic problems, as well as code that could be "refactored" once the whole PR has been read.

this provides a few things; it gives us an ability at how the interviewee problem solves. next we can see how they respond too obvious fixes (would they be someone you'd want to send a PR too?). finally, it tests their knowledge of the language and APIs, hopefully much better than Leet Code can. I would also like to see if the user can spot obvious bugs in the setup code (say, package.json, pyproject.toml, etc)

I am going to make an example PR for: - frontend (React/NextJS, TypeScript, CSS) - backend (Django, Python) - DevOps (potentially some Pulumi code for deploying to a Kubernetes cluster?)

[djmips]

Although this is better than leet code, PRs have been shown to be a poor way to prevent bugs. I find they are mostly useful for disseminating knowledge.

[yieldcrv]

I think there are flaws with this approach too, but I wish this approach was more common so that there was industry wide rapid iteration to a more optimized version of this.

What I’ve seen are time trials, which don’t show you how well a candidate will adapt to a codebase, wont show you how they will do tickets for your sprint. Only reinforces a flawed idea of the employer about how they wont “hit the ground running” despite having that job opening for 8 months.

What you described might not be a time trial, its what ive seen though.

[aitchnyu]

I once a test with badly written code and gave my comments. A bot immediately asked me to implement those changes, but I assumed a human would respond. I made a YAGNI change, trying not to disturb existing code too much. They responded saying the comments raised during PR were good, but writing a big switch statement for all subclasses violates Liskov Substitution Principle.