My biggest issue with the work sample tests is the companies that waste your time with them. I've had 3 cases over the years where I was asked to work on something, I did it quickly, with quality and exceeded the specs and I was still turned down at that point (I confirmed that the code was good in at least 2 of the cases). As a senior technical person at this point in my career I simply have very little stomach for…
Same for me. I did a 6-7 hour homework project. I have no idea how I did, the company didn't get back to me for a month, and then it was just a call from a recruiter. Never again.
The Hiring Post
111–120 of 266 posts
Re: The Hiring Post
#112Re: The Hiring Post
#113> The majority of people who can code can’t do it well in an interview. Major citation needed. I don't have any real data either way, but I find this extremely hard to believe.
Do you think any majority of people are good at interviews? I don't have a strong or well informed opinion about it, but I would not be shocked if the answer is no.
Re: The Hiring Post
#114Re: The Hiring Post
#115Re: The Hiring Post
#116We went through the phase when we gave candidates a problem and let them work on it remotely. It was in an embedded C shop that did a lot of kernel work. Basically, we'd give a short programming task (say, to write an intrusive AVL tree container in C) and 24 hours. Guess what? HALF of candidates cheated. Meaning that when the got called for an in-person interview, they stumbled to explain how "their" code worked. To…
I'm not sure the conclusion here is that remote tests are bad. It's also possible that your screening methods didn't do a good enough job. (As a disclaimer, I'm a terrible interviewer, but...) I believe that by the time a candidate gets into a room with me, that my team and I should have a good idea about whether this person will work out or not. If I make them take time out of their day, and I take time out of my da…
There are the hired.com models where independent experts thoroughly vet the candidate, but that involves a lot of manual interaction.
Re: The Hiring Post
#117There are a lot of 'hiring is broken' posts and this is a decent one, but I don't think I'm alone in feeling that none of them convincingly identify the problem, let alone solve it.[1] So I'll do that here. Hiring isn't broken because people use the wrong interview questions. It's broken because firms are engaging in a zero-sum battle for talent. But if what you're doing is worth a damn, it should be worth a damn whe…
I think hiring is broken for a different reason: workers, whether in software or any other industry, are viewed as less-than-equal ("second-class citizens"). Except in rare cases the entire hiring process in software especially, from start to finish, just about everywhere I've ever interviewed, seems to me designed to find reasons to reject candidates, and as a side-effect is (perhaps unintentionally) also designed t…
Re: The Hiring Post
#118Earlier quoted context omitted.
> If you can do that reliably, you should be making zillions of dollars. I disagree to a degree; I've met many people who were simply fantastic with figuring out problems but didn't know much software development and they ended up being awesome software developers. It's certainly doable and I don't think it's so difficult that someone who can do it should be making an obscene amount of money but they are not cheap ei…
I think you're more wrong than right, and it's selection bias that gives you confidence here. There are people from all sorts of backgrounds that can become very good developers, but their common feature seems to be that they were already the sort of person who could become a good developer, not any methodology used to train them. For example, I'm confident most talented physics Ph.Ds[1] can make decent developers of…
I don't think anyone was saying a random person but someone wanting to get into the field or is already in the field but perhaps not in the right spot when you pick them up.
I can't imagine anyone would mean a random person here, that wouldn't make sense as development is a skilled position. not everyone can do it and OP was talking about interviewing developers not random people.
Re: The Hiring Post
#119Earlier quoted context omitted.
Very good post. Thank you for sharing it. I've been interviewing applicants quite a bit lately, so have been thinking about these issues. Two questions for you. What is your experience hiring fresh college grads? Is the process different? Since one of goals of the process seems to not arbitrarily adjust it for every candidate, but rather stay consistent, do you think it makes sense to adjust it for someone who just g…
Everyone has exactly the same process, with the exception of interns. Interns have an abbreviated interview (shorthand: we switch from assessing aptitude to assessing enthusiasm ), and any time one came back looking for a full time job, they got fast-tracked. I'm not saying that was the best policy (it did keep us from collecting some extra data), but by the end of an internship you had a really good idea that you wa…
Don't get me wrong, I understand and agree with your reasoning. I'm just curious how transparent it is to the other side.
Re: The Hiring Post
#120Earlier quoted context omitted.
Everyone has exactly the same process, with the exception of interns. Interns have an abbreviated interview (shorthand: we switch from assessing aptitude to assessing enthusiasm ), and any time one came back looking for a full time job, they got fast-tracked. I'm not saying that was the best policy (it did keep us from collecting some extra data), but by the end of an internship you had a really good idea that you wa…
It's interesting that you make an effort to not read resumes. Do you explain that to people you interview during the first call? The reason I ask is that, if a hiring manager asked me things that are already written on my resume (e.g. what did you study in college?), I would definitely be annoyed, as my default expectation is that they should read the resume before the interview. Don't get me wrong, I understand and…