4 ms·
Late to the party but I'll just add in my $0.02 I remember the best interview I had was at a company offering open source software. For the coding components o
by gurgus 11y ago
Late to the party but I'll just add in my $0.02
I remember the best interview I had was at a company offering open source software. For the coding components of the interview they give applicants a task (they cherry pick one of the easier ones) from their JIRA backlog and told applicants they've got two weeks to come up with a patch. It didn't matter if the applicant could fully solve the bug/feature, since it's not particularly fair to expect the applicant to be familiar with the ins and outs and gotchas of the system they are working with, but what did matter is that they A) submitted something, and B) could talk their way through their thought process and how they arrived at their current solution.
This sort of process really clicked with me. Obviously it's not as straightforward for some organisations that may offer proprietary software, but the process could certainly be adapted for a lot of organisations, in my opinion.
- deleted 11y ago[deleted]
- tedmiston 11y agoThis is interesting because without knowing how their system is architected or designed, it allows you to state assumptions and you can use that time to assert knowledge of best practices of a given framework. Sort of an implicit test for depth though. Edit: I missed where you said open source company. Though I still think this thought for a closed source company that uses open source pieces (like a web framework) could be useful.