4 ms·
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 minut
by ipaddr 2y ago
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.
- krat0sprakhar 2y ago> 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.
- SoftTalker 2y ago> Are you aware how easy and common it is for candidates to lie on the resume? Ask them a few probing questions about some of the technology and experiences listed. It's not too hard to pierce a veneer of bullshit. And does anyone check references anymore?
- bluefirebrand 2y ago> 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
- Jensson 2y agoMore 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.
- captaincaveman 2y agoThinking you can figure out someone in 5 minutes makes you a no hire from me ;)
- johnnyanmac 2y agoI think "figuring someone out" and "figuring out if someone can do a job that needs to be filled" are very different topics.
- ipaddr 2y agoI 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.
- Jensson 2y ago> you would hire me under your process because I can talk your ear off for hours and can outsource the take home Which is why all of the biggest tech companies does on site technical tests.
- ipaddr 2y agoFor the biggest tech companies you spend time practicing leetcode. I don't know if that's any better.
- ozim 2y agoYou 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.
- camdenreslink 2y ago> I know they must really need the work because they gave away 2 hours of free work, that might be a red flag. Needing to work might be a red flag? What?
- ipaddr 2y agoToxic attitude where you need to be working to find a jib.
- camdenreslink 2y agoI'm not sure I understand. Somebody really needing the work being a red flag during a job application process is nonsensical. Of course the need the work...that is why they applied for a job...
- rprospero 2y agoThe 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.
- IIsi50MHz 2y agoOr 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.
- ozim 2y agoRemaining 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.