3 ms·
Whenever I interview, I pair with the candidate to built an arbitrary thing with a time limit. Often something from r/dailyprogrammer. This helps me understand
by deedubaya 9y ago
Whenever I interview, I pair with the candidate to built an arbitrary thing with a time limit. Often something from r/dailyprogrammer. This helps me understand how the grasp problems, parse the intent in the mind, and put that to something which solves the problem. We can talk about design choices together because if they get hired, we're going to collaborate in very much the same way.
I also allow the candidate to take the project home and finish/refactor if they want. I may have a follow up call to review as well. This elevates the pressure of the interview a bit as there is no requirement to deliver in time X.
I don't tend to have candidates work on "real" problems because I feel like it comes across as scummy to ask for free work. If I did, I'd make sure to compensate them for their time.
Edit: I only use r/dailyprogrammer as a source of challenges, I use the same challenge for all candidates.
- theptip 9y agoI do something similar; building an arbitrary thing gives you a good window into how they actually approach solving a problem. One key difference - I use the same task for each interview, which while boring for me, makes it easier to transfer my score between candidates. I initially had some colleagues that I've worked with for years do the interview to calibrate what a ninja would look like on that test, which I've found very useful. I've also considered doing real-world problems, but my concern is that 1) they tend to have too much back-story and context, and 2) it would be hard to calibrate the difficulty. Perhaps that's unfounded.
- deedubaya 9y agoYes, I use the same task for each interview as well. I just use r/dailyprogrammer as a resource for challenges. They're well illustrated and usually provide sufficient context. You're right about real-world problems. They often require a ton of context to grasp.
- theptip 9y agoGot it, yeah that's a good approach. I'll look at that reddit when it comes time to refresh my task.
- grogenaut 9y agoIf you build an arbitrary thing everyday that's completely different how do you calibrate of cross the different candidates so that you give an equal hiring experienced and make sure you're not biasing on other factors that can get you in legal deep-water, or just you know biasing accidentally because of the problem being harder today
- deedubaya 9y agoI typically use the same programming challenge for all candidates in a hiring cycle, not a different one for each candidate. I just use r/dailyprogrammer as a resource for arbitrary problems.
- grogenaut 9y agoHow long is a hiring cycle? Also do you pre-calibrate your questions on coworkers?
- mrisoli 9y agoI liked when I was tasked with "real" problems, one company paid for my services as a freelancer as part of the interview, another one "hired me" for one month as a contractor and would then make me an offer by the end of this trial period. My current company made me part of the team for three days and gave me a real task but on the NDA it states they are not allowed to use the code produced during the interview process, it was a great experience and is what made me decide to join the company.
- JustSomeNobody 9y agoHow would you, or would you at all, work with me, as a candidate, if I had a particular distaste for solving puzzley type problems? Note that I'm not saying I wouldn't try during an interview, but my distaste for puzzles may inhibit my successfully completing the assignment regardless of my programming abilities.
- deedubaya 9y agoI have a distaste for puzzles too -- my hiring method doesn't use puzzles, but arbitrary real-world like tasks that need solutions. It tries to mirror real-world scenarios of what you, the candidate, would be doing if employed by me. If this isn't an acceptable form of evaluation, I would be open to others -- which I would potentially reject.