It is better to hire fewer employees that last. That is, more effort should be spent on retention and less on acquiring as many disposable employees as possible.
Most of the big companies treat their employees like trash and lose them rapidly. They think "Well we pay a lot so we have tons of people banging on our door to work for us, so we don't need to worry about getting new employees." This is a bad mentality.
New software engineers need to always be interviewed by those who are senior to the level at which the employee is being hired for. You will never be able to reasonably determine candidate level if you don't have more experience than they do.
The notion of "always hire employees smarter than yourself" is cute, but you don't have any way to determine rapidly that someone is.
Some recommend take home projects. I don't think those tend to work well for various reasons...
Things I do think work to find good employees:
* Give adequate time for whatever task is assigned during the interview. I nearly always see that the interview is rushed because there is inadequate time given for what is being done. If time is not available, just do a portion of the tasks and quick fail if the candidate does not pass that portion. If they succeed schedule additional interviews.
* Require open source contributions of meaning for higher level candidates. Have an interview ( an entire interview ) centered around reviewing their contributions with the candidate and discussing them.
* An interview ( 1 hr ) of the following type: Tell the candidate "Convince me why I should hire you. You have 30 minutes to present your case. I will say nothing that whole time. Afterward Q&A about what you said for 30 minutes.
* Ask questions of the candidate and don't bother with all the trickery. Bring me any software engineer and let me just ask them about random stuff freeform and I'll tell you if they suck or not within an hour. Don't demand some specific stupid process for interviewing them. You have to trust those you use to do the interview process and give them the authority to determine what the next best questions are always. The moment you turn the process into some "by the book" shit, you will get a shit process.
* If a coding test must be done, it needs to be just like on the real job in that full access is given to use websites to rapidly acquire the information needed to give the best result. Also, let candidate use their own IDE setup, and have them ready to go ahead of time. If anything, give a loose idea of what the coding task will be without details, to give the candidate time to prepare in whatever way makes sense for them to be able to tackle a task of that time.
* Give more time to accomplish tasks. So so so many of the stupid tasks I've been assigned in interviews cannot be reasonably and cleanly done within the 20-30 minutes usually given max to do them. Creating quality software takes time. Rushed software = crap software. Be real.
Most of the big companies treat their employees like trash and lose them rapidly. They think "Well we pay a lot so we have tons of people banging on our door to work for us, so we don't need to worry about getting new employees." This is a bad mentality.
New software engineers need to always be interviewed by those who are senior to the level at which the employee is being hired for. You will never be able to reasonably determine candidate level if you don't have more experience than they do.
The notion of "always hire employees smarter than yourself" is cute, but you don't have any way to determine rapidly that someone is.
Some recommend take home projects. I don't think those tend to work well for various reasons...
Things I do think work to find good employees:
* Give adequate time for whatever task is assigned during the interview. I nearly always see that the interview is rushed because there is inadequate time given for what is being done. If time is not available, just do a portion of the tasks and quick fail if the candidate does not pass that portion. If they succeed schedule additional interviews.
* Require open source contributions of meaning for higher level candidates. Have an interview ( an entire interview ) centered around reviewing their contributions with the candidate and discussing them.
* An interview ( 1 hr ) of the following type: Tell the candidate "Convince me why I should hire you. You have 30 minutes to present your case. I will say nothing that whole time. Afterward Q&A about what you said for 30 minutes.
* Ask questions of the candidate and don't bother with all the trickery. Bring me any software engineer and let me just ask them about random stuff freeform and I'll tell you if they suck or not within an hour. Don't demand some specific stupid process for interviewing them. You have to trust those you use to do the interview process and give them the authority to determine what the next best questions are always. The moment you turn the process into some "by the book" shit, you will get a shit process.
* If a coding test must be done, it needs to be just like on the real job in that full access is given to use websites to rapidly acquire the information needed to give the best result. Also, let candidate use their own IDE setup, and have them ready to go ahead of time. If anything, give a loose idea of what the coding task will be without details, to give the candidate time to prepare in whatever way makes sense for them to be able to tackle a task of that time.
* Give more time to accomplish tasks. So so so many of the stupid tasks I've been assigned in interviews cannot be reasonably and cleanly done within the 20-30 minutes usually given max to do them. Creating quality software takes time. Rushed software = crap software. Be real.