Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Interesting. What do you think about having the candidate look into the used codebase and explain the process of understanding what is going on?
I assume it depends on various factors if that is suitable, but I had the chance of trying that out and found it had an excellent side effect: you basically get a code review from an external view. This can be a win as the existing team tends to create a "bubble" and inconsistencies, missing docblocks etc become more apparent. At the same time, you gain a pretty solid understanding of the candidates ability to "pick up work"
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
If it's a case where you can do that without needing multiple layers of NDA's just for the interview, then yes, I think that's a good option as well. It's kind of dependent though on how close to BCP for whatever language/platform you're using you are, as being too far just makes it too difficult for the candidate to pick up anything.
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Sure, and there's probably an even longer list of cases where it's also not appropriate neither of us are thinking about. That is what I implied when I said it probably isn't a possibility in many cases.
It certainly makes sense for a team around an open source project to relate screening challenges to the existing code base! That can be an amazing technique...as y'all said, if done right.
There is a fundamental difference between reading/explaining code and writing code, though, and that should be accounted for. I've met plenty of people who could do one, but not the other.
And then you have the companies whose code base is already a horrific pile of spaghetti, and showing any of their code in an interview would reasonably send candidates screaming into the night. ;) Or do you ask then: how do we make this function better?
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Interesting. What do you think about having the candidate look into the used codebase and explain the process of understanding what is going on?
I assume it depends on various factors if that is suitable, but I had the chance of trying that out and found it had an excellent side effect: you basically get a code review from an external view. This can be a win as the existing team tends to create a "bubble" and inconsistencies, missing docblocks etc become more apparent. At the same time, you gain a pretty solid understanding of the candidates ability to "pick up work"
If it's a case where you can do that without needing multiple layers of NDA's just for the interview, then yes, I think that's a good option as well. It's kind of dependent though on how close to BCP for whatever language/platform you're using you are, as being too far just makes it too difficult for the candidate to pick up anything.
Sure, and there's probably an even longer list of cases where it's also not appropriate neither of us are thinking about. That is what I implied when I said it probably isn't a possibility in many cases.
It certainly makes sense for a team around an open source project to relate screening challenges to the existing code base! That can be an amazing technique...as y'all said, if done right.
There is a fundamental difference between reading/explaining code and writing code, though, and that should be accounted for. I've met plenty of people who could do one, but not the other.
And then you have the companies whose code base is already a horrific pile of spaghetti, and showing any of their code in an interview would reasonably send candidates screaming into the night. ;) Or do you ask then: how do we make this function better?
Lol. Yes, but my point is: then that company needs such feedback.
True. So I guess you want to see both capabilities.