3 ms·

Critical take below, but i appreciate the hard work spent in building this and i think its going to help a lot of people. This is productizing a totally broken

Critical take below, but i appreciate the hard work spent in building this and i think its going to help a lot of people. This is productizing a totally broken understanding of code reviews it seems. Anybody can stare at someone else's code and criticize it. It's a well known meme that many devs heavily criticize their own code 6 months lateral. Code reviews in practice need to be about ensuring conformance to written team agreements on which practices to follow and the reasoning for it, identifying emerging patterns that need to be addressed as new standards adopted by team agreement, and generally publishing changes to the codebase so the whole team is aware how the repo is evolving. This isn't a code review product, it's just selecting candidates who think similarly to the publisher, ensuring a monoculture of thought. However, great job on building this product! It's a great start and I wish you the best of luck!

creativeSlumber 3y ago
> This isn't a code review product, it's just selecting candidates who think similarly to the publisher, ensuring a monoculture of thought. I have to agree to this. It takes a quite a lot of experience, maturity and wisdom as a software engineer to learn to appreciate other view points that do not agree with your current view.
CharlieDigital 3y ago
> Anybody can stare at someone else's code and criticize it. I think there is a distinct difference between "criticize" and "uncover" and it seems like it's pretty easy to distinguish a candidate that can only criticize and not uncover. Part of this is that it is dependent on the using good exercises to begin with. For example, find a PR that fixed a performance issue and use the before code as the exercise to see if the candidate spots the issue. Do they propose the same fix? Perhaps they can propose an even better fix. Another example might be to use code before a refactor and ask candidate for feedback to see how they might think about this code, why it should be refactored, and how they would propose the refactor. Will they come up with the same analysis as your team? Perhaps they have some approach that's entirely novel. Or they may completely miss the point of the why the code should be refactored. It seems that such an exercise can reveal a lot about the depth of experience of a candidate without many of the downsides of live coding exercises focused on leetcode or long take homes that then require followups to close the loop. Like any tool, there's No Silver Bullet, but it can be another option to have. > However, great job on building this product! It's a great start and I wish you the best of luck! Thanks!
- marcinzm 3y ago
  > Part of this is that it is dependent on the using good exercises to begin with. For example, find a PR that fixed a performance issue and use the before code as the exercise to see if the candidate spots the issue. Do they propose the same fix? Perhaps they can propose an even better fix. I think this exactly highlights the problem with this approach. Most senior engineers I've talked to would start by looking at metrics and traces versus code. If that didn't exist then they'd start by adding instrumentation before trying to solve the performance problem. In fact they'd consider a code first approach as a sign of a very junior engineer (or out of touch EM). The original PR as a result likely took that all into account. Someone who figures it out code first either has bad habits/approaches to performance issues (thus making them good at the wrong way of solving such problems) or just got lucky.

creativeSlumber 3y ago

> This isn't a code review product, it's just selecting candidates who think similarly to the publisher, ensuring a monoculture of thought. I have to agree to this. It takes a quite a lot of experience, maturity and wisdom as a software engineer to learn to appreciate other view points that do not agree with your current view.

CharlieDigital 3y ago

> Anybody can stare at someone else's code and criticize it. I think there is a distinct difference between "criticize" and "uncover" and it seems like it's pretty easy to distinguish a candidate that can only criticize and not uncover. Part of this is that it is dependent on the using good exercises to begin with. For example, find a PR that fixed a performance issue and use the before code as the exercise to see if the candidate spots the issue. Do they propose the same fix? Perhaps they can propose an even better fix. Another example might be to use code before a refactor and ask candidate for feedback to see how they might think about this code, why it should be refactored, and how they would propose the refactor. Will they come up with the same analysis as your team? Perhaps they have some approach that's entirely novel. Or they may completely miss the point of the why the code should be refactored. It seems that such an exercise can reveal a lot about the depth of experience of a candidate without many of the downsides of live coding exercises focused on leetcode or long take homes that then require followups to close the loop. Like any tool, there's No Silver Bullet, but it can be another option to have. > However, great job on building this product! It's a great start and I wish you the best of luck! Thanks!

marcinzm 3y ago
> Part of this is that it is dependent on the using good exercises to begin with. For example, find a PR that fixed a performance issue and use the before code as the exercise to see if the candidate spots the issue. Do they propose the same fix? Perhaps they can propose an even better fix. I think this exactly highlights the problem with this approach. Most senior engineers I've talked to would start by looking at metrics and traces versus code. If that didn't exist then they'd start by adding instrumentation before trying to solve the performance problem. In fact they'd consider a code first approach as a sign of a very junior engineer (or out of touch EM). The original PR as a result likely took that all into account. Someone who figures it out code first either has bad habits/approaches to performance issues (thus making them good at the wrong way of solving such problems) or just got lucky.