I can figure out in 5 minutes how someone is going to do. Just based on the resume alone in most cases.
What do you do with the remaining 4 hours and 55 minutes?
The take home test tells me little. I don't know who did the work, how long it took. I know they must really need the work because they gave away 2 hours of free work, that might be a red flag. If they guessed the coding standards we use then we pass them?
If you care about seeing their code ask them for a sample. Some people people github profiles with code on their resume. Use some of the time you have: the 4 hours 55 minutes and check yourself. It will be more representative of their work.
> I can figure out in 5 minutes how someone is going to do. Just based on the resume alone in most cases.
Just on resume? Are you aware how easy and common it is for candidates to lie on the resume?
> If you care about seeing their code ask them for a sample.
Same as above. Most candidates can't share code sample from their current/previous employer. For open source projects, it is again very easy to fake authorship.
> Just on resume? Are you aware how easy and common it is for candidates to lie on the resume?
If you can't figure out a candidate lied on their resume in a half hour conversation, you aren't going to figure it out in a four hour conversation either
More data absolutely helps, many people can fake it for an hour but not for 5. Work doesn't end after the first hour, so if they can't keep it up for less than a full day they wouldn't be able to during the real work either.
The truth is that, if a candidate competent enough to work for us, then they can get hired by a firm thirty miles down the road who pays way better than we do. Thus, one line of questioning during the interview process is figuring out why the candidate wants to work for US instead. Usually it's because they want more exciting work or are interested in the work we are specifically doing. If someone just wants ANY job, it's a red flag that they've applied to the wrong place.
Or a sign that the market sucks, so they've been applying for a while.
Or their interview skills suck.
Because I'm not a fan trying to puff myself up by blowing flowery smoke at people, I've previously felt that I should _like_ the one true answer to "Why do you want to work /here/?" to be "Because I need a job, and you're hiring.".
But I suppose a nicer, more compatible answer would be something like "Because our requirements and interests seem to align.". I guess that would sound a little like "interested in the work we are specifically doing" without being some sort of gushing false enthusiasm that anybody would perceive as either an exaggeration or a lie.
Remaining 4 hours and 55 minutes - is for getting person to talk to different people on the team. Management, QA other devs to get the feel of what kind of people we are, presenting company and having time for this person to present his\hers personality.
First 1 hour with management - the important part is to clarify persons requirements and getting to clarify what company requires to make sure he is not going to quit in 1 month - even if it is not entirely preventable and happens.
Then after 1st get to know we send out take home (for applicant to spend up to 2hr not more of his time, but usually we give task that for experienced person is max 30-45 mins) - if we like the person - the same if we send out take home and person doesn't like us or we don't match expectations, he doesn't have send it back or spend time on it.
Then during second interview (1 hour) technical part with devs (if solution is of course good enough but doesn't have to be perfect) is scheduled so person changes his own code so I can see how person uses the tools. If someone claims he is a senior and struggles changing his own code or doesn't use tooling in a proficient way that is what I check. Other part is that I ask for changes and see if person has any improvements or I propose improvements and see how person reacts - is person defensive, is person not having any ideas how to improve code, is it a person that thinks his code is "perfect" in all ways and everyone else is stupid.
Last (1 hour) one is confirmation that we are still on the same page with requirements on both sides then meet&greet to get to know one of business analysts someone from QA to get a feel and second opinion on the person personality - if we don't have red flags anyone rising we make an offer and that is take it or leave it, because all expectations should be already ironed out, we can of course wait so no pressure but if someone is not responding for a week we go for other candidate.
I would be the one hiring, replacing you in this made up scenario. Regardless of the position you are hiring for you would hire me under your process because I can talk your ear off for hours and can outsource the take home. My point is I shouldn't have to have such unrelated skills.
You know that I use take home to ask for modifications on the spot during technical interview. First hour is soft talk to see if there is any communication issue, then you go home do take home, if you don’t like us you don’t have to do the take home.
If someone is reluctant to do changes in his own code it is a no go for me.
Main point of take home I give is so that candidate has his own code to modify while we are on the second round, not to waste time and stress people with something they didn’t wrote/know.
What do you do with the remaining 4 hours and 55 minutes?
The take home test tells me little. I don't know who did the work, how long it took. I know they must really need the work because they gave away 2 hours of free work, that might be a red flag. If they guessed the coding standards we use then we pass them?
If you care about seeing their code ask them for a sample. Some people people github profiles with code on their resume. Use some of the time you have: the 4 hours 55 minutes and check yourself. It will be more representative of their work.