I write from time to time.
Views expressed are my own and may not represent the opinions of any entity with which I have been, am now, or will be affiliated.
What’s your experience with coding challenges, technical tests, tasks? (e.g. codility, hackerrank or various custom “homeworks”) as an applicant and as an evaluator as well?
As a interviee: I get nervous when doing timed tests with people watching me. Every mistake suddenly seems magnified hundred-fold. It's definitely not representative of my true capability - like you said, the vast majority of the time you are in a environment where you can reference docs and think at your own pace.
As a interviewer: I don't have much experience here - I've only interviewed one person. But it was a interesting experience being on the other side. You give out a relatively simple question to a person with decades of experience and they can't even being to solve it. But we have all been there - I'm not only looking for a solution (although that would be nice), I'm looking for how they approach the problem. In this instance they got angry, complained about it being a unfair question, and left without shaking my boss's hand. No go.
Do you think it properly evaluates if an applicant is a fit for the job?
There's no golden bullet for properly evaluating a candidate - it depends on how you use it. Ideally you would ask questions directly relevant to the job at hand. If the questions are tricky theoretical ones then you would ask just to see the thought process, not necessarily for a solution.
What is a viable alternative that works for you as a hiring manager?
I haven't tried it, but some companies invite you to their office and pay you to work a full/half day like a real employee. That would be nice as a employee and as a employer it would give you a much better idea of how the employee performs than theoretical CS questions.
Senior DevOps Engineer with 8.5+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
Been there, done that with the getting nervous part myself too.
While the experience you had as an interviewer seems to be unfortunate but in retrospect, if a person with decades of expertise doesn't have basic etiquette right - I'd be doubtful of having someone like that onboard if I were an interviewer myself.
Coming to the whole working as a real employee for a half/full day concept, it's interesting but not exactly feasible for everyone since there are so many variables to be factored.
From my knowledge so far, I'd ideally go with a 2-3 rounds of interviews with people of the designated team and then a panel round with all of them so that it's easy to get a fair overview of the candidate.
I write from time to time.
Views expressed are my own and may not represent the opinions of any entity with which I have been, am now, or will be affiliated.
Coming to the whole working as a real employee for a half/full day concept, it's interesting but not exactly feasible for everyone since there are so many variables to be factored.
Since my last post I've done this and it's awesome. Not practical for larger companies since there is a lot of setup involved, yes, but for small companies I would reccomend it. For me it was the difference between accepting / not accepting the offer.
Senior DevOps Engineer with 8.5+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
As a interviee: I get nervous when doing timed tests with people watching me. Every mistake suddenly seems magnified hundred-fold. It's definitely not representative of my true capability - like you said, the vast majority of the time you are in a environment where you can reference docs and think at your own pace.
As a interviewer: I don't have much experience here - I've only interviewed one person. But it was a interesting experience being on the other side. You give out a relatively simple question to a person with decades of experience and they can't even being to solve it. But we have all been there - I'm not only looking for a solution (although that would be nice), I'm looking for how they approach the problem. In this instance they got angry, complained about it being a unfair question, and left without shaking my boss's hand. No go.
There's no golden bullet for properly evaluating a candidate - it depends on how you use it. Ideally you would ask questions directly relevant to the job at hand. If the questions are tricky theoretical ones then you would ask just to see the thought process, not necessarily for a solution.
I haven't tried it, but some companies invite you to their office and pay you to work a full/half day like a real employee. That would be nice as a employee and as a employer it would give you a much better idea of how the employee performs than theoretical CS questions.
Been there, done that with the getting nervous part myself too.
While the experience you had as an interviewer seems to be unfortunate but in retrospect, if a person with decades of expertise doesn't have basic etiquette right - I'd be doubtful of having someone like that onboard if I were an interviewer myself.
Coming to the whole working as a real employee for a half/full day concept, it's interesting but not exactly feasible for everyone since there are so many variables to be factored.
From my knowledge so far, I'd ideally go with a 2-3 rounds of interviews with people of the designated team and then a panel round with all of them so that it's easy to get a fair overview of the candidate.
Since my last post I've done this and it's awesome. Not practical for larger companies since there is a lot of setup involved, yes, but for small companies I would reccomend it. For me it was the difference between accepting / not accepting the offer.
Glad to know this played a key role in helping you decide but then again it's easier said than done regardless of the company's size.