Great article and great advice. It misses one huge advantage of doing this: if you write down what you expect from interviewees, it forces you to think about and justify why the things that you look for in interviews translate to skills you need in the job.
Great point. Another benefit is a public declaration will hold everyone’s feet to the fire. For example, if a company declares they will get back to a candidate in a week in an externally facing document, suddenly that becomes the expectation, internally and externally.
Just another example of the benefits of making the implicit explicit.
A lot of companies seem to think that if they gave out what their process looks like, their process will be gamed and cheated. So I don’t expect them to change their mind.
I think you’re correct, sadly. I have worked at companies which took this view and don’t think it’s a coincidence that in at least one case the interview process was a common cause of poor reviews on Glassdoor. But it’s a weird view to take!
If somebody is capable of learning the things they need to perform well in your interview, you would hope they are capable of learning what they need to perform well at the job. If that doesn’t hold true, perhaps the interview process has a problem.
If somebody is capable of learning the things they need to perform well in your interview, you would hope they are capable of learning what they need to perform well at the job.
I think that sometimes this is the issue. The interview bears only passing resemblance to the job, so you see other tests to check for stuff like algorithmic implementation ability.
In the places I had any control over the interview process, I tried to make it as close to the job experience as possible (in terms of resources they could use, interactions with the team, and tasks). This, in my opinion, is best for both the candidate and the company.
I wish more companies would do this. For the last company I interviewed at, I knew how things were going to happen because I had a friend there that referred me, and it made interviewing actually pleasant, allowed me to focus on the interesting parts I wanted to learn, and was not an adrenaline-inducing exercise. Hell, the only reason I interviewed there first, before everything else, was because I knew how things were going to go. (I did end up getting an offer, but US immigration is incredibly painful.)
I pushed for a formal process/document at my last job, ended up being told I wasn’t senior enough to be involved in those discussions. I hope that I can have that impact at the next job. :)
I knew how things were going to happen because I had a friend there that referred me, and it made interviewing actually pleasant.
I have taken advantage of existing relationships in companies for this purpose as well. Not just for learning about the interview process, but for the all important “pings” afterwards. I have found that you typically can’t count on the official process to keep you informed on your progress through the interview pipeline, so you have to either bide your time or go through a back channel.
Backchannels are absolutely invaluable and being ‘stranded’ in a new company without them makes for some of the most stressful workdays. Mentorship programs usually are aimed at combatting that, but are rarely successful in these cases. I wonder what can be done to make them more effective. The problems seem to be 1) if participation is coerced, people do not want to interact with the newbies and 2) if it isn’t not enough mentors are available.
I’m pretty sure a fascinating study/trial/experiment is waiting here but I’m in no position to tinker with it.
I have started trying to outline the process for candidates on their first interview, to hopefully make them more comfortable with the process. I’m not sure about maintaining a written document of it in general.
However, I do think that the described process of expecting the candidate to have a development environment set up on their local system that you can collaborate with them on something in is not a very good idea. If you do choose to do that, the candidate should have a written description of what is expected of their setup well before the interview. In general, this sounds like a great way to spend all of the time you expected to spend on coding and debugging on troubleshooting their development environment setup instead. Either that, or turn off half of the candidates by expecting them to spend several hours getting a dev env setup to very specific details just to do an interview.
Any coding collaboration should take place on a pre-configured environment. Any of the interviewer’s actual device, a standard environment like repl.it or coderpad.io, or maybe some standard instance spun up by CloudFormation is fine. Spending the time of both the interviewer and candidate troubleshooting environment setup is a waste of everyone’s time.
Great article and great advice. It misses one huge advantage of doing this: if you write down what you expect from interviewees, it forces you to think about and justify why the things that you look for in interviews translate to skills you need in the job.
Great point. Another benefit is a public declaration will hold everyone’s feet to the fire. For example, if a company declares they will get back to a candidate in a week in an externally facing document, suddenly that becomes the expectation, internally and externally.
Just another example of the benefits of making the implicit explicit.
A lot of companies seem to think that if they gave out what their process looks like, their process will be gamed and cheated. So I don’t expect them to change their mind.
I think you’re correct, sadly. I have worked at companies which took this view and don’t think it’s a coincidence that in at least one case the interview process was a common cause of poor reviews on Glassdoor. But it’s a weird view to take!
If somebody is capable of learning the things they need to perform well in your interview, you would hope they are capable of learning what they need to perform well at the job. If that doesn’t hold true, perhaps the interview process has a problem.
I think that sometimes this is the issue. The interview bears only passing resemblance to the job, so you see other tests to check for stuff like algorithmic implementation ability.
In the places I had any control over the interview process, I tried to make it as close to the job experience as possible (in terms of resources they could use, interactions with the team, and tasks). This, in my opinion, is best for both the candidate and the company.
This plan is fine until you get 400 resumes for a job.
I wish more companies would do this. For the last company I interviewed at, I knew how things were going to happen because I had a friend there that referred me, and it made interviewing actually pleasant, allowed me to focus on the interesting parts I wanted to learn, and was not an adrenaline-inducing exercise. Hell, the only reason I interviewed there first, before everything else, was because I knew how things were going to go. (I did end up getting an offer, but US immigration is incredibly painful.)
I pushed for a formal process/document at my last job, ended up being told I wasn’t senior enough to be involved in those discussions. I hope that I can have that impact at the next job. :)
I have taken advantage of existing relationships in companies for this purpose as well. Not just for learning about the interview process, but for the all important “pings” afterwards. I have found that you typically can’t count on the official process to keep you informed on your progress through the interview pipeline, so you have to either bide your time or go through a back channel.
Backchannels are absolutely invaluable and being ‘stranded’ in a new company without them makes for some of the most stressful workdays. Mentorship programs usually are aimed at combatting that, but are rarely successful in these cases. I wonder what can be done to make them more effective. The problems seem to be 1) if participation is coerced, people do not want to interact with the newbies and 2) if it isn’t not enough mentors are available.
I’m pretty sure a fascinating study/trial/experiment is waiting here but I’m in no position to tinker with it.
I have started trying to outline the process for candidates on their first interview, to hopefully make them more comfortable with the process. I’m not sure about maintaining a written document of it in general.
However, I do think that the described process of expecting the candidate to have a development environment set up on their local system that you can collaborate with them on something in is not a very good idea. If you do choose to do that, the candidate should have a written description of what is expected of their setup well before the interview. In general, this sounds like a great way to spend all of the time you expected to spend on coding and debugging on troubleshooting their development environment setup instead. Either that, or turn off half of the candidates by expecting them to spend several hours getting a dev env setup to very specific details just to do an interview.
Any coding collaboration should take place on a pre-configured environment. Any of the interviewer’s actual device, a standard environment like repl.it or coderpad.io, or maybe some standard instance spun up by CloudFormation is fine. Spending the time of both the interviewer and candidate troubleshooting environment setup is a waste of everyone’s time.