3 ms·
My biggest pet peeve with these types of tests is this: there are a lot of companies out there, and I’m sending out resumes to each one that I can find. That's
by edw519 17y ago
My biggest pet peeve with these types of tests is this: there are a lot of companies out there, and I’m sending out resumes to each one that I can find.
That's your first mistake.
Why should a company take you seriously if you don't take them seriously? Every resume you send out should be custom written and carefully crafted to address their requirements, not yours. Do you do any research into the companies you're applying to? You should.
Rather than sending out 50 stock resumes, you'd probably be better off picking the top half dozen or so opportunities and do everything you can to stand out. This includes a custom cover letter, follow up emails, thank you notes, etc., whatever it takes to make the connection.
I simply do not have the time to write fifteen code samples a day, just because you want to evaluate me against your coding test. Period.
There's your second mistake. Misdirected attitude. Again, you should be focused on their needs, not yours. If you don't have time to do 15 poorly, then just do one or two very, very well. No employer or recruiter gives a damn that you've chosen a shotgun approach.
Give of yourself without expectations of something in return. You may be surprised at the "unexpected" dividends you'll reap later.
FWIW: I have conducted over 2500 technical interviews and every single one of them has had to code, regardless of experience or background. What good is a programmer who doesn't want to code at the one point when it would provide the most benefit to everyone involved? In my experience, the best programmers were the most eager to give it a shot.
- fogus 17y agoExcellent comment. You've elucidated my whole interviewing philosophy in a way that I was never able to. Thank you.
- rdrimmie 17y agoI'm in agreement with everything except that it's not a matter of focusing on the company's needs. If you're sending resumes to 15 companies a day you aren't even focusing on your own needs. Figure out who you want to work for and then figure out how to communicate with someone there who is going to want to hire you.
- scott_s 17y agoI agree that sending out resumes as fast as you can email is a bad idea, and I agree with the attitude you proscribe, but I think you're disagreeing with something the author never said. He did not say "don't require coding as a part of the interview process." He did say "don't require fully functional, complete applications as a part of the interview process." I've never heard of anyone asking for that, but the author claims he has.
- tomjen2 17y agoYou should send out letters with the goal of maximizing the opportunity you get a job offer. Thus it might be very valid to spam a lot of companies with a generic offer. This doesn't apply if you want to work of a few select companies, such as Frogcreek or Google, but most companies have so similar that they aren't worth customizing for.
- deleted 17y ago[deleted]
- m0th87 17y agoFrom my experience, I've seen a huge difference in the quality of developers between companies that conducted strenuous coding tests and those that didn't, although I'm not sure if the relationship is causal. It certainly does help weed out candidates like the author, who is clearly not passionate about the companies he's applying to. I once took a class in Industrial and Organizational Psychology. The professor moonlighted as a consultant for corporations. His advice was for companies to give real-life problems in interviews, as it's the most effective indicator of future job performance. The equivalent in our industry would be coding tests.
- larryfreeman 17y ago2,500 technical interviews? That would mean that you've been interviewing someone every day for 6 years straight. Assuming 3 interviews per day, that would be 2 years straight including Saturdays and Sundays. I don't doubt you but having been a manager myself for 7+ years, I real have trouble believing that "every single one of them has had to code". I've done 500+ interviews myself and most have focused on coding questions but not all. I personally think that focusing on code 100% is really a big mistake in interviewing. Of course, if you mean by "interviews", interviews done by a team where some someone on the team focused on code, then I agree with you. I would often find myself focusing on character questions or past experience while other members of my team focused on the coding questions.
- tom_b 17y agoHow deep have you taken interview coding? Have you found that pseudo coding at a whiteboard is as effective as giving a candidate a test assignment on a box in the office? I've also wondered about the effectiveness of reviewing candidate-submitted code samples vs some type of coding during the interview. Any thoughts there? Have you found any other strong correlations between finding the best programmers in interviews other than the eagerness to tackle a programming problem? I'm about to start searching to fill two positions now - I've struck out in my personal network, mainly because at this point I know people who are more senior and the positions I have are on the junior side, both in pay and responsibilities.
- edw519 17y agoDiscussed before: http://news.ycombinator.com/item?id=89669 http://news.ycombinator.com/item?id=89669 http://news.ycombinator.com/item?id=834513 http://news.ycombinator.com/item?id=834513 http://news.ycombinator.com/item?id=835092 http://news.ycombinator.com/item?id=835092 Hope these help.
- tom_b 17y agoThanks!