3 ms·

I also loved the idea. Except it was wildly unpopular amount the other interviewers as t was seen as setting traps and watch if the poor guy falls into them.

I also loved the idea. Except it was wildly unpopular amount the other interviewers as t was seen as setting traps and watch if the poor guy falls into them. And interviewees were sometimes dumbfounded looking at the code, and we didn't know if they were just crushing under the stress or had never looked at code in their life. All in all, it wasn't that different from a straight leetcode interview. Code reviews were basically the same, nice on paper but hard to judge in practice.

ludicrousdispla 1y ago
If I was asked to review code in an interview, I'd prefer it be printed out on a sheet of A2 or A3 paper that I could look over and write on. Regardless, there should be a hard rule that if you show code (either working code or example code) to a candidate then it needs to stay visible for at least five minutes. No skipping ahead to the next slide or switching windows after 2 seconds.
- makeitdouble 1y ago
  For live debugging/fixing we were sharing a dedicated GitHub repo, and the candidate would share his screen while doing it. It was kinda of a mess, so I switched to a more static approach of sharing a MR and have the candidate explain what it does, and potentially comment on it. TBH I wouldn't do that face to face, it's so unnatural I'd prefer white boarding or straight handing them a computer. That's also where using an online coding platform where the candidate can run the code works a lot better, less preparation on either side, less surprises.
  - ludicrousdispla 1y ago
    I generally make it a rule to not share my screen, install software, or create a new account as part of an interview process, so using an online coding platform is nice.
mixmastamyk 1y ago
Disagree. Am a good programmer who can’t perform under stress or surveillance. A code review would be 10x less stressful than writing fresh code and enable me to show off knowledge easily, in a good way.
- makeitdouble 1y ago
  To dig a bit on this, setting up the review itself isn't trivial. I felt we were just applying different biases, which could be fine, but it also wasn't catching up internally. For instance I personally use and abuse the online GitHub/gitlab interface a lot and am extremely familiar with both. But looking at my colleagues, many do code reviews locally, diffing in their IDE. Some also don't navigate the code the same way and tend to work "bottom up" instead of "top down", which puts them at a disadvantage in time limited settings when they might be better reviewers in general. Referring to the other comment wishing to get full A3 printout to look at the code, we also had a guy who used his personal laptop to interview and felt lost as he usually reviews code on his giant work screen. Having the candidate choose could be the best of both worlds, but that' a lot more work on the interviewing side.

ludicrousdispla 1y ago

If I was asked to review code in an interview, I'd prefer it be printed out on a sheet of A2 or A3 paper that I could look over and write on. Regardless, there should be a hard rule that if you show code (either working code or example code) to a candidate then it needs to stay visible for at least five minutes. No skipping ahead to the next slide or switching windows after 2 seconds.

makeitdouble 1y ago
For live debugging/fixing we were sharing a dedicated GitHub repo, and the candidate would share his screen while doing it. It was kinda of a mess, so I switched to a more static approach of sharing a MR and have the candidate explain what it does, and potentially comment on it. TBH I wouldn't do that face to face, it's so unnatural I'd prefer white boarding or straight handing them a computer. That's also where using an online coding platform where the candidate can run the code works a lot better, less preparation on either side, less surprises.
- ludicrousdispla 1y ago
  I generally make it a rule to not share my screen, install software, or create a new account as part of an interview process, so using an online coding platform is nice.

mixmastamyk 1y ago

Disagree. Am a good programmer who can’t perform under stress or surveillance. A code review would be 10x less stressful than writing fresh code and enable me to show off knowledge easily, in a good way.

makeitdouble 1y ago
To dig a bit on this, setting up the review itself isn't trivial. I felt we were just applying different biases, which could be fine, but it also wasn't catching up internally. For instance I personally use and abuse the online GitHub/gitlab interface a lot and am extremely familiar with both. But looking at my colleagues, many do code reviews locally, diffing in their IDE. Some also don't navigate the code the same way and tend to work "bottom up" instead of "top down", which puts them at a disadvantage in time limited settings when they might be better reviewers in general. Referring to the other comment wishing to get full A3 printout to look at the code, we also had a guy who used his personal laptop to interview and felt lost as he usually reviews code on his giant work screen. Having the candidate choose could be the best of both worlds, but that' a lot more work on the interviewing side.