And no, they can't determine how awesome you are based on a normal interview process. Nobody can.
I've interviewed people with "20+ years of industry experience" who will swear up and down they can hack the Linux kernel but then can't reverse a string in place or write a function that determines if a word is a palindrome or not.
Having someone write some code, any code is meant to weed out those muppets. Just show me you can actually write a loop. With an 'if' statement somewhere. Please. That's all I ask. You have 15 years+ experience with SQL server? How about a simple JOIN statement? Please?
Now, companies like Google take that too far and I'm 99% positive that the day-to-day job for more than 19/20 people who work there does not involve suffix trees or reverse-printing a linked list through recursion or implementing a stack with two queues, but those are meant to shrink the pool of potential hires from the thousands to the dozens. Nobody wants to sit through a normal interview with thousands of people, better to stump most of them with idiotic, useless quiz questions and interview only a few dozen in person. I get it.
I think interviewing for software jobs is horrible everywhere, period. We just have no way to determine if someone is good or not - you can put anything on your resume and it's hard to verify and compare/contrast with other candidates.
I believe the solution is to hire someone temporarily for a few months on reduced salary/benefits (which would still be considered an amazing deal for 85% of the work force in the US) and see how they work out - can they actually produce? If so - full time, if not - bye.
That's a feature. They get the good, undervalued talent early.
"If an interviewer is not capable of determining my knowledge level by a normal interview that tells me right away something up, and I probably don't want to work with them because they aren't too smart themselves."
News flash, all companies are horrible at determining knowledge level by a "normal" interview. The only ones that have a hope are those that use some sort of test or have existing work to review.
*who are just as likely to leave for another company as soon as something better comes along?
I'm not sure I understand this. A dev who valued their time very much would already be working at a job they liked enough not to be looking. As job satisfaction declines, time opens up to work on whatever you want to call this, a technical feeler, perhaps. A dev who values their time wouldn't get snowed under by a ton of these because they wouldn't be applying willy-nilly, only to those places they want to work.
I applaud their decision to pay for correct answers, as it balances the "cost" bourne by the applicant and employer. Employers who send out tests en masse have an asymmetric advantage -- they can force many candidates to incur a cost without incurring much or any cost of their side. This causes bad behaviours.
Traditionally in interviews, companies "paid" with their time, but online exams skewed that. Paying something per correct answer at least makes them think twice before inviting hundreds to the exam that they have no real intention of ever interviewing.
It's all just ways to filter. If I can filter you through our mutual network, I'll do that - if I can't, open source code; if I can't, coding test.
Edit: thinking more about this, it's good to see that it's a paid puzzle, so even if you don't get an interview, you are still compensated for your time.
Having a broader perspective - its maybe only in programming that the hiring process is so much easier. For almost any other job you need the right technical skills, years of expensive schooling, unpaid internships and have done a lot of networking ( cough nepotism cough ) - its only in programming that raw skills can get you anywhere.
Now, what do you suppose happened next? I never heard from them again and all of my attempts at communication were ignored. I'm starting to think my age is becoming a factor (mid 30s) -- and also these kids have no sense of respect and professional courtesy. I'd like to say this was an isolated incident, but that would be a lie.
Stupid me just spent his Saturday doing another such project, though at least this one presented a more interesting problem. I swear, if I find out I had my time wasted again I'm going into consulting. Or maybe I'll go to truck driving school. Or open a cafe. Screw this "employee" stuff.
The fact that so many employers treat candidates like this tells me that the whole "it's hard to find good developers" line is a lie.
Don't give up. Most established companies aren't run by 20-somethings. If the seniors are already in their mid-20s and lack professionalism, then most likely there are other issues going on at this company. You may have dodged the proverbial bullet.
Wish I could upvote this twice! Every rejection I've ever received came with an information-rich sideband that told me more about the prospective employer than an acceptance would have. In at least half of such cases I said to myself: "phew, that was a bullet I was lucky to dodge... imagine how it might feel to work with these people!"
So it looks a bit weird to them and the thought process is something like "this guy is talented, what is wrong with him that he's a walk on? I'm not willing to find out, pass."
Yeah, I dunno. I mean, some have poor soft skills, definitely. But I would argue that engineers in many companies are simply insulated more than other groups. The biggest reason for this is that Engineering is thought of as a cost center, which has a number of resulting consequences.
Other groups like Product are exposed to many other groups (Sales, BD, Exec, Engineering) and so naturally their networks are larger and more diverse.
More established companies will probably have 30 to mid 30 as the median age, and will have much more professional hiring process (relatively)
Also there is a saying that goes around: A's hire A's, B's hire C's
There are cases where you will be declined as "overqualified" or "no cultural fit" when they mean "will replace my job or at best make me look bad" and "too old" respectively.
I wouldn't give up yet. There are a lot of software architect positions if you have the relevant experience. Median age is higher than 30 I'm pretty sure.
But the "we don't have enough developers" is a blunt lie, "we don't have enough excellent developers" is also a lie. "We don't have enough rock star developers who are ok not being paid enough and have no aspiration to become team leads and just want to code all their career and work overtime" is probably more accurate.
Even after than many interviewers look at your resume like 10 minutes before the interview there is no chance that they would read through your code on github. github as your resume is overrated.
I am curious to know if people hire or get hired purely based on their github profile without a technical interview.
* If you don't provide a link to your github profile, I'm not supposed to look at it. This an HR requirement. Other companies may use this same policy.
* I definitely look at github, but it's not always easy to tell if a project is original or not. Quite often I'm presented with either 30 forks, or a few projects that seem like they started as some boilerplate.
* Don't just provide github, also provide a specific project to look at. Even better, point out a particular section that you are proud of.
* Even with a well-stocked github, I will still ask you to code. This likely isn't to tell if you can code, but to figure out what it would be like to work with you.
So far, there hasn't been one candidate that had anything resembling a portfolio online, but we don't hire all that often and i've only been doing it for a bit over a year.
Last time this happened I was informed that Russian and Indian are races. Talking about my coworkers by their country of origin (I was saying how refreshing it was to work with a broad array of people in SF vs what I normally work with [white male] in Oklahoma.)
Russian is a race. Seriously.
HR employees are worthless in my experience (~35 years in the labor force).
Probably that's exactly why you were ignored. The guy was scared of competition. (Maybe they were looking for a tech lead and he felt threatened by your expertise.)
I can certainly still program, but interviewing...I'm tired of it. Tired of being asked picayune questions like I just graduated. Maybe I should I change my CV title from 'Senior Software Engineer'... that actually implies 30-something, late 20s. but what? "Part time CTO and dog's body for a few small startups/companies"?
I know I can do most anything I put some effort into, the relearning process is not hard. But everyone wants a warm body they can immediately plug in. I get interest due to my CV, but they want to stick me into jobs I'm too senior for. I need to figure out what to change... or tell recruiters, no absolutely not, no more front end work, ever!
well, my advice is start planning your career change now - I wish I had 10 years ago, instead of merely idly thinking about it.
There are no shortage of companies that need someone your age who have been around the block and can bring professionalism in addition to a wealth of experience. Don't sell yourself short. Even if they called you back after a month of ignoring you would you really want to work for them? Probably not. Generally ding dongs like that are only capable of hiring other ding dongs(confirmation bias), hold out for working with adults. You age is an asset not liability.
Unfortunately, this seems to be par for the course these days - I have a lot of friends who complain about the same thing. It's just indicative of a total lack of professional courtesy, and you should consider yourself lucky that you didn't end up working with people like that.
You know, the thing is there's nothing new, you're just seeing today what the illusion of the paycheck prevented you to see before. Take this as an opportunity to move your life forward : no matter how exciting your next job is, give to yourself a deadline to bootstrap a SAAS business as a nightjob and have enough customer within 6 months to - at least - replace your salary.
Also, in these cases, I'd recommend you simply call back yourself. Think of it as the opposite of the judicial system (for the US and most of Europe, at least): the burden of proof is on the prosecution. In this case, it's on the job-seeker. You're the one who has to show you want the job and that you're the best fit. The company's role is to find a good fit (and to do so by using their resources in a reasonable way).
That being said, I wouldn't advise on doing "homework" assignments that are exceedingly long.
For the record, when I am on the recruiting side of the fence, I always do a phone screening first, with live coding in a shared editor. Only then might remote homework or on site coding come up, and I always tried to make sure the effort is minimal. It's hard to find something that fits all people and minds though. Try to design a recruiting scheme, and let me know how it works out and if it doesn't piss anyone off. :)
The courtesy thing is another issue entirely, of course, and obviously a lot less defendable...
That is correct. The market is so flooded with workers that ageism is easily affordable.
You can keep trying if you want but the suggestion "it will all work out if you just try harder because the system is ultimately rational" is inaccurate and unproductive. If you glance around the work place and count the percentage of people 10 years older than you, you can guesstimate the odds of continued employment.
dfraser992 advice is, unfortunately, they way the world really works: neither ageism nor the flood of workers is going to be widely admitted to let alone addressed in the foreseeable future.
I'd say in this particular case the guy felt threatened and/or you were too expensive(or assumed to be too expensive)
Maybe it depends on the company, but for smaller companies and startups it's not only if you can do what they need it's if you fit in and the other employees like you and want to work with you. You don't want to hire or work with a jack ass, especially smaller teams. You could be the best developer/programmer/engineer in the world, but if no one wants to work with you, well, they probably won't contact or hire you.
It could be for the better and I'm not saying you are a jack ass. You might start there and after a month or 6 decide you don't fit in, feel miserable, and don't like the environment and decide to leave and have to go through this all over again.
Keep at it. Eventually you will find a company that wants your expertise and you enjoy working for and like people you work with. Both sides have to ultimately decide on a good balance. Technical abilities are not the only factor and I wouldn't jump to the conclusion that it's an age issue.
As an aside I have not come across any issues with age and I'm in my lower-30's. I think it has less to do with age and more to do with how your present yourself, act, work, and communicate. No one believes I'm even nearing 30 when I interview or am being interviewed for example and it's never actually been brought up or mentioned for me that I recall.
My current company was getting some poor candidates who passed the phone screen (the phone screen was the usual 1 hour code something in a google docs while we both look at it) type of screen. So we added a homework problem that takes a couple of hours to pull off. I found when I interviewed I had no interest in coding or following each companies stupid and arbitrary interview process. I do worry that it's too much of a pointless pain - but we have been able to reject a few people at the "homework" stage because they were just atrocious.
If someone has been a public github contributor, that should be even better than a homework problem.
Indeed, I agree
When they have someone hiring not based on what's best for the company but what's best for their own career goals, you know you're going to have issues.
Welcome to the world of tailoring yourself for the job. I'm in my 40s, so it gets worse. Can't wait until I'm over 50!
It seems like someone could get a pretty good staff if they targeted all the late 30+ people.
I would have asked them to look at that code and ask me any question they have about it. If they are not willing to do that I wouldn't have bothered continuing the conversation with them.
> the mid 20-something lead developer
Okay I am going to do something I don't like to do which is judge somebody on their age but a "lead developer" at around 25? Sorry but unless that person is some rockstar programmer (conceived with a copy of K&R in the womb) I find it very hard to believe somebody 3-4 years out of uni has the experience to be a "lead" at very much.
> told me he thought I was a better programmer than him.
Well that is something I guess, at least he didn't think he was God's gift to the programming world!
> Now, what do you suppose happened next? I never heard from them again and all of my attempts at communication were ignored.
Yes drives me insane. It is so fucking rude.
> I'm starting to think my age is becoming a factor (mid 30s)
Could be, hopefully not but a company that puts a mid-20-something as the "lead" developer might only be interested in getting young and therefore cheap employees.
> and also these kids have no sense of respect and professional courtesy.
Very true. That is partly why I don't think a mid-20s person can be a "lead" for much as they don't have the professional experience to lead. A lead developer isn't just a great programmer but also a great leader. Somebody for the regular staff to look up to and rely on for mentorship.
> I'd like to say this was an isolated incident, but that would be a lie.
It happens to us all. Some companies (IT and other) are shit. It is just the way of the world. Don't dwell on it too much, it is just more mental energy wasted and they already wasted a whole Saturday of your life yet were not even respectful enough to call and say "you were great but we prefer this other person". I mostly hate having that conversation (giving and receiving) but it has to be done, it is about respecting that persons time and even though you are not offering them a job you can offer them feedback so they do not walk away from the process empty handed. Sometimes that feedback is all they need to better themselves in the future.
> Stupid me just spent his Saturday doing another such project, though at least this one presented a more interesting problem.
Live and learn. In the future if you already have demonstrations of your work then ask them to look at that first and if they want to continue the process then you look at doing something specific for them. At least you seem to have found a small positive from it in that the problem was interesting :)
> The fact that so many employers treat candidates like this tells me that the whole "it's hard to find good developers" line is a lie.
A lot of the problems with finding a good dev is just finding a good employee for the company as a whole. You might have a good developer who is an asshole and will only cause issues.
Anyway just move on and forget about them. It is cliché relationship advice but you deserve better than them.
Yes, over half my team members are older than me. However, most of them come from electrical engineering backgrounds and have less professional programming experience than I do. There is no friction, though. They're great guys, and they don't demonstrate any sort of ageist attitudes. There's definitely a level of mutual respect and trust, and I try to foster open communication throughout the team.
Three years out of university, I got an offer to be a senior software engineer and technical lead. It came with a 50% pay raise. I'll admit I had some reservations before taking the position. What if I'm not good enough? What if I fail? The thing is, the people who hired me (I was interviewed by no fewer than 7 different people at the company, all in one day), thought that I had the skills necessary to succeed (otherwise they wouldn't have offered me the position). I took the position and I'm glad I did.
It has been the best job I've ever had. Until now, I'd never worked in an environment that placed so much trust in, and demonstrated so much respect for, its employees. There's a good bit of freedom, and the company is very good at rewarding its employees for good work. My only complaint is that the development environment is less than ideal (Oracle Grid Engine, all work done in the cloud, Perforce, SAP, lots of shitty products to deal with in the development workflow). I'm only willing to put up with that because the nature of the job (and the people I work with) is so good otherwise.
Maybe you're right that the term "lead" is thrown around too much in our industry, but I don't think it's insane to put a young person in such a position as long as they're otherwise qualified. As an aside, if you're ever doubting yourself, listen to what your peers are telling you!
Now, on one hand, I dropped out and been in the industry (gamedev) for the last ten years. On the other hand, I've actually been on designer and producer positions for the first 6. But then again, on the third hand, I was programming non-stop since 8 and turned in MIX emulator (from Knuth's books) as a school project at 15.
So, may be we can at least agree that any broad statements about professional level of huge groups of people united only by their age, race, country of origin or other unrelated stuff are unlikely to be true for everyone in that group, because people are unique and deserve to be judged individually?
Yeah, this is so true it hurts
Not only kids mind you
Don't do these take homework projects. Don't work for free.
It's not a lie, you just forgot the last half of that sentence. "It's hard to find good developers, who are willing to work for the peanuts I'm offering."
To me, the most useful question is this: "here is an example project that we'd be likely to do, how would you build it?" Then you just let them walk through the steps they'd take.
From there you can launch into why they made the choices they made, trade-offs, philosophy, etc. When you hear people explain how they would make something real, you start to learn a lot of things about them without even needing to ask, and so you're less likely to get scripted answers. They're also probably in their comfort zone at this point, so you get to see them in a more real way.
I don't necessarily mind "homework" style projects, but I tend to shy away from that sort of thing as it's not always respectful of the candidates time.
Two questions I usually avoid (but see getting asked all the time): puzzle questions, and language trivia. I don't ask puzzle questions because I've never seen it correlate to something useful. Most puzzles require an "aha" moment where your subconscious bubbles up some kind of answer, but the easiest way to short circuit that part of a persons brain is to put them in front of strangers with a time constraint. Puzzles might give you a clue as to a persons overall IQ and confidence, but it won't tell you a lot about how they can do the job.
Puzzle questions are also "expensive", in that they usually put a candidate on edge, and they set off the candidates bullshit detector. Let's keep in mind that we're going to reject the majority of candidates, statistically speaking, but you still want them to think highly of your company. If they feel like they're being rejected for a BS reason, you've just created animosity towards your company. It's important that the people you reject still feel respected.
I don't ask language or framework trivia, as I don't think it's useful. I might lob a softball about a framework just to make sure they've actually used it, but I'm not going to ask something hard.
I always have turned down homework assignments. It just feels insulting and disrespectful. Even whiteboard crap is useless but I'm OK with it considering they've paid for my travel expenses etc.
If you think about it ... homework assignments are a classic case of B's looking for C's. A's wouldn't need to resort to such silliness. They can identify (as an interviewer) and exhibit (as an A interviewee) with just an intelligent conversation.
I feel like I wasted the half-day I spent on their code challenge. I don't expect a job, but a simple "Thanks but no thanks," would be nice.
If it was about 10 hours, $1K was usually OK. I never had a problem asking for this, but the problem is that so many companies are doing it now that they cannot afford to pay everyone.
When I'm adding to my own team I would rather talk to them about code than have them do these screens. It's more holistic and I get more of a sense of how they think. If I'm going to give them a code challenge like this I wait until after the phone screen so I don't waste people's time.
I've created from scratch: new CRDT data-types for geospatial problems, new highly-available transaction patterns that provide useful causal history and atomic visibility, large-scale messaging platforms (400k ops/sec), high-throughput machine learning pipelines, lock-free lightweight-process mailbox implementations, and an end-to-end build pipeline for generating bare-metal rumpkernels to be parallel deployed to N-number of Minnowboard Max devices. Among other things.
If you asked me to do homework to prove to you that I can "program", I'd have a brief discussion with you about how misguided that seems, thank you for your time, and walk away.
I mean fully "hundreds of connections" to a socket pool? Are you serious? If I submit a solution that can do "hundreds of thousands of connections" that includes QuickCheck tests for your protocol and my implementation, Ansible scripts for deployment and orchestration, and a Makefile that builds it, tests it, bakes it into a unikernel, and drives the Ansible scripts to push it out and start the end-to-end load test, do I get to be CEO or something?
Why is tech hiring so full of strange, meaningless obstacle courses? Do we just collectively not have better ideas?
Using a combination of (semi-)rigorous personality profiling (time constrained), and mapping the abstract problem domain of their prior work to the problems I actually have for them to work on, it's been possible to align new people with the work such that they're intrinsically motivated, and make sure all the bases are covered for the necessary roles (hacker, inventor, finisher, watchdog, etc.) to carry a very large greenfield project from start to finish.
I've never once given a cute riddle, puzzle, or coding challenge as a part of the interview process, and actively dissuade others from doing it as well.
Taking up hours of a candidate's time is excessive, but it seems reasonable to ask for some demonstration of your ability, when so many candidates simply cannot code.
So why not simply ask technical questions during an interview? I'd think you'd be able to determine whether or not someone know what he is talking about by simply asking him a few questions on the matter.
If you were actually looking for a full time position you'd do the interview. It's completely reasonable to require an unpaid interview from a candidate.
Work-sample tests measure the latter.
A worker's experience is a heuristic for programming skill, but a heuristic of a heuristic is like an average of a set of averages: Useless.
I think that's debatable. The quality of your measurement is then simply a function of how well your tests are in the first place. Do you really think giving a person FizzBuzz is any kind of accurate predictor of future success at a job?
A moderately experienced dev will not spend much time to apply, and frankly would probably enjoy the interface better than most job application websites. :-)
A lesser experienced dev will end up spending more time, but really if they are successful we would still want to look at them.
As a intermediate (after so many years, should I just replace that with 'mediocre') dev I think a test like this would be a fantastic way both for a company to judge me and for me to judge what a company would expect from me.
There's a huge variety in dev roles ranging from challenging to code monkey and it's sometimes hard to figure out from a job posting or even conventional conversational interview where along the spectrum the expectations are, but establishing those expectations on both sides is critical.
It does make me wonder how hard it would be to come up with basic challenges for different roles to simply apply to the job using their skills. I guess for some rolls harder than others. :-)
The goal wouldn't be a hard challenge, just one that shows basic competency and problem solving ability within their field.
Still this would take time and effort to create. That said, the last time I hired someone I probably spent 100 hours reading resumes, filtering candidates, and interviewing people.
The goals of a technical interview should be: - Confirm the credentials presented aren't complete BS - Validate they know enough to be immediately helpful - Assess their long term potential (brains, social skills)
Coding challenges tend to be good at the first two points but very questionable for the third. Incidentally, given that I'm seeing a 50% washout rate from a basic SQL code question (supported by confessions from candidates that they fabricated credentials/experience), you would be silly not to include some form of practical test.
The third point (potential) is best measured by talking with them about a project they really cared about. For those who cannot share work examples, pick a good side project. Don't get hung up on the content - focus on their passion. You'll get a better view of my capabilities if you chat with me about building an ad server, mobile optimization, or SEO analytics (real world projects I care about) than with a contrived example.
As for the github profile of code shrugs why? Seems like a bit of a cult to me. I'm happy to sharing anything that's useful (and do so on my blog) but don't have the free time to spend developing code for the sake of "work samples". My work samples run on production servers as commercial projects, thank you very much..... Suspect many other good candidates are the same.
Yes, I'm coming to the realisation that it's idealistic to assume that anyone with N years experience will be at a certain level of ability.
"(potential) is best measured by talking with them about a project they really cared about"
I agree. I've always thought that once you've made sure that a candidate's programming knowledge isn't fabricated, the best way to evaluate them is to get talking about code. Whether that's proprietary code they've written but can't share, or it's on a GitHub profile for all to see shouldn't make a huge difference.
It was super neat. Totally hired that person.
I particularly like how this team iterated on their uploader problem, abstracting it out to a socket server and providing a test suite for it. Reacting to ambiguity by abstracting the problem was clever. And, of course, a great illustration of how a standardized hiring tool can, like any software project, be iterated on and improved --- unlike a free-form whiteboard interview.
Because every method of hiring has its own biases and tradeoffs. Requiring work samples biases against programmers who aren't interested in doing a "homework assignment". For example, I don't enjoy whiteboard interviews but I'd rather write some fragments in front of the interviewer and "think out loud" instead of working on a multi-hour (or multi-day) coding project. Writing on a whiteboard is just not that big of a pressure cooker to me.
One could argue that the majority would prefer self-paced work samples instead of whiteboard interviews and you're optimizing for a wider candidate pool. That's fine but it's still a tradeoff. I think you're running a smaller scale boutique firm so work samples makes sense for you.
For a company like Google Inc who is more selective[1] than Harvard University, I don't see a compelling need for them to rely on work samples. That company is so desirable for programmers that any "work samples" Google tries to standardize on would get leaked and endlessly discussed on stackoverflow (see FizzBuzz for precedence.) If Google has to keep changing out the work samples to stay ahead of the street knowledge, you've lost the ability to compare work samples over the years which was one of the motivations to use that method in the first place.
At their scale and selectivity, the "study your algorithms book and prepare to be grilled on the whiteboard" seems to work best for them. Yes, they reject a lot of false-negatives but it's offset by ... their scale and selectivity. They can afford to reject false-negatives. If their screening methods were truly terrible, I don't see how the label "ex-Googler" would have the currency it does in the marketplace.
[1]http://thenextweb.com/google/2010/09/14/one-half-of-one-perc...
Selectivity is only good if it selects for traits you want, and, in practice, what you want is not a uniform skillset. So being selective for one trait, any trait, is already a bad idea.
Even the basics of the interview format make a difference. At other companies, all coding interviews are timed at 45 minutes or so, including the problem statement. It's a bit like going to an episode of Chopped. It's certainly selecting for 'can you think under pressure' along with 'are you friendly enough that your interviewer will help you when you are getting something wrong without docking your score'. But that's not good for a careful candidate that is trying to build sturdy, reliable code. So guess what: The company's codebase has few tests, things fail often when deployed to production, and reliability is a problem. It's not that they are willingly selecting against careful programmers, but it's a consequence of the interview process.
The moment you are hiring a lot of people, and you think you have a single model that works, you are hiring from a cookie cutter, and you'll get gingerbread men.
Companies that do work samples minimize on-site coding interviews, because the whole point of offsite work sample testing is that most candidates can't provide an accurate picture of their aptitude in an on-site coding interview.
No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge.
The problem developers have with "homework problems" is really a problem with bullshit companies that won't provide timely feedback on their submission. Nobody wants to do homework that goes into a black hole, only to find out 6 months later that they were in consideration for the role. That's a problem with all hiring companies, and it is orthogonal to the structure of the interview itself.
Nitpick, but I'd love to see a citation on that. Google, like every technology company on the planet (modulo a small error value) goes to great lengths to recruit and hires lots and lots of people.
So far, I have completed around 12 1 hour phone coding tests, the same amount of 30 min chats with recruiters, I have 8x 5 hour on-sites scheduled, have spent about 4 long days on one take-home assignment, 6-8 hours on another, and have two more assignments to complete, both of which I estimate will take over 8 hours each.
I haven't had a weekend for the past 2 weeks because I've been working on assignments and I'm pretty stressed and exhausted.
This process has made me consider changing careers because it's so exhausting. When companies give you take-home assignments I don't think they realise how many things you have going on at the same time.
Additionally, I've found that a one hour coding test has allowed companies to move faster in the process with me than those who have given assignments. When I receive an offer from a company I am happy with then I will tell those companies with assignments I haven't finished that I won't be moving forward with them and they will miss out on a great candidate!
Me too. I'm so put off by the entire process but it seems that to stay relevant, you have to get lucky and end up at a place that keeps your skills up-to-date with opportunities to learn and use the latest tech, or you jump ship every 2-3 years meaning you're once again dealing with this insane pressure of interviewing. Throw in ageism once you get past your mid-30s or so and the mere thought of staying in the industry starts to look quite depressing :-/
Furthermore, after providing ZERO feedback in the past when I have provided github links, offline code samples, personalized cover sheets, etc. to prospective employers this also will not be done. I'm not going to worry and beat myself up because you can't be bothered to provide feedback even when requested to do so.
Homework for programming jobs is just like homework for school: it is not used to judge competency but to demonstrate that your time is not your own as it belongs to someone else. In the case of programming jobs the homework assignment also acts as a filter to weed out employees who will not be properly subservient to the employer.
I was surprised how a couple really basic concepts evaporated from my head during the in-person white boarding. The questions though were reasonable and the interviewers were friendly. All in all a positive experience just an incredible investment of time it seems for all concerned.
The take away is I need to practice solving problems on a white board with just 3 hours of sleep. The sleep deprivation part might be the most important factor to simulate.
Hm. Maybe bourbon? Or a good cider?
In practice, it means I spent 20 hours on my last piece of sample code I submitted to a job I was excited about. Only to be told no thanks, with the feedback of:
"Your app meets what we spec'd out, but it differs from our style."
And to be clear, after I repeatedly asked for what they were looking for in this code, they replied "we are purposely providing nothing except functional requirements to see what you produce".
I could have given them exactly what they want, but I guess they'd rather just wait and hope that someone magically codes the same way they do?
Honestly I should have billed them after that.
I was very suspicious of being an actual feature development. I've said I would only do that if they would pay me to.
They answered that they feel very sorry for me because a lot of the candidates feel the coding challenge very challenging because they can learn new stuff and they love it
go figure
In comparison, a YC company (who eventually got acquired) actually responded very positively to my suggestion that I get paid to do the test they required, not dissimilar to bringing in a freelance contractor for a day.
Is giving out an 8+ hour programming project as part of the application process really considered good hiring practice? If you apply to five jobs, you're expected to spend an entire unpaid work week writing code that doesn't benefit anyone? If a company receives 20 applicants, their ideal candidate selection wastes a collective work month?
I don't really understand this ideal. What's the point of maintaining an online portfolio and a github profile full of code if companies prefer to waste your time writing a pointless uploader?
On pair programming tasks, I had a pair programming session with a guy, he gave me an empty project and a poorly specified brief, verbally, then gave me 15 minutes to crank something out. It was pathetic. I didn't get the job and the feedback was, "he didn't know some of the keyboard shortcuts I'd expect." In hindsight, I'm glad I didn't get that one but at the time things were getting desperate.
The best process was the one where I finally got a job. We talked on the phone for an hour and a half and by the end you could just tell we had that, "developer bond". His approach was the best I'd seen. He just talked through some of the problems he had, I proposed solutions and we talked through pros and cons. He treated me as an equal from the start. After that we had the face-to-face HR questions (how do you resolve conflict, etc.) which they have to ask because it's a big company, and another one with another manager but by then it was pretty much a done deal.
And I think that's the way to do a decent hiring process. Don't behave like an authoritative dick, and use phone interviews to screen candidates. Programming projects don't work because it's going to take you forever to review them, and pair-programming doesn't work because there's not enough time, and it's kind of horrible for the candidate.
My best job experiences are exactly as you describe.
The worst have been companies that sought me out (I didn't apply) and then wasted my time during the phone screen (having background conversations with other people in the room, asking me to repeat answers to questions because they weren't listening)...I'm looking at you, Uber.
I've had the same experience, and I absolutely agree. Just about all my best interviews were with someone where we just hit it off and talked deep tech for an hour. On most of these we had to consciously cut the conversation off because we went long. I don't think that, when this sort of interaction occurs, you know the person is going to be good at writing production code. But at least you do know they're the "sort" of person you would expect to be good at it, and frankly none of the other methods discussed do a better job at providing that assurance.
1. Phone screen amounting to about 45 minutes.
2. Skype interview with small code samples between two interviewers at 45 minutes each.
3. 2-week paid trial doing real work.
I had #2 yesterday and am currently waiting to hear back from them about moving onward.
There exists a continuum of hiring practices which place more or less burden upon candidates. I would encourage HNers with input into their company hiring practices to choose less burdensome approaches over more burdensome approaches, particularly when less burdensome approaches also yield additional signal about ability.
A thing you can expect to be asked in 2016: you can expect to be asked to have an on-site interview in a city you do not live in. (How many people will be asked to do this for the SFBA or NYC? Literally jumbo jets full, this week.) For some candidates, this will involve more than 16 hours on planes, a (minimally) overnight stay in a business hotel, and six solid hours of interviews in the course of an 8~10 hour day. This requires minimally 2~3 days of these candidates' lives.
Most companies keep "conversion rate between onsites and job offers" very close to their vest. To put it mildly: it is not guaranteed that if you're flown out you will get an offer.
If you are hypothetically designing your interview process, and you replace the onsite with even an excessively long project, that's a win. The project can be written at the candidate's own pace and schedules conveniently around their other obligations. They do not have to arrange child care, take off time from work, or make tradeoffs like "Do I do the project or do I attend a friend's wedding?"
If you fly across an ocean and start bombing an interview, that's a terrible result for everyone. If you happen to be doing a project and discover "Oh, wait a minute, I've really miscalibrated here: this is far above my level of expertise with $FOO and honestly if this is the character of the work then I'm not sure I want to do it", then you have an easy option: simply close the window and, maybe, send a two-sentence email to the person who you were talking to.
Smart use of projects as a filtering mechanism can minimize costs to candidates and the company of administering high-cost testing (e.g. onsites, long projects, etc) to candidates who will ultimately not be successful at receiving offers and/or defer the high-cost assessments until the anticipated chance of receiving an offer is "very high."
... To put it mildly: it is not guaranteed that if you're flown out you will get an offer.
..., and you replace the onsite with even an excessively long project, that's a win. The project can be written at the candidate's own pace and schedules conveniently around their other obligations. They do not have to arrange child care, take off time from work, or make tradeoffs like "Do I do the project or do I attend a friend's wedding?"
All true but my observation is that the companies that put candidates through multi-day-out-of-town interview processes can afford to miss out on the candidates that can't do it. Tellingly, the type of companies like Google and Microsoft that put a lot of burden on candidates hire heavily from a pipeline of fresh college graduates. Not surprisingly, a lot of 22-year olds don't have existing jobs or kids they have to juggle to commit to intensive interview processes. Sure, they also interview older middle-aged candidates but the benchmark tolerance for hoop-jumping is set by the 22-year olds therefore you won't get sympathy from employers about disrupting your life to stay in the running. For those companies, even if they are flying you out, you're still in the "evaluation" stage and could be 50/50 accept/reject.
Contrast that with boutique consulting firms that hire from the 30+ age bracket (often by poaching other consulting firms' employees.) A lot of their candidates already have existing (lucrative) jobs. Most of their evaluation is done on multiple phone interviews. If the company decides to fly you to their headquarters to interview, you basically have the job unless you unzip your pants and urinate on the interviewer's desk. The onsite interview is not a technical screening but a personality sanity check. At that stage, you're 90/10 accept/reject.
One company in Amsterdam, just last week, I went through a four step process, the last one being the onsite interview. I did really well in the first two, but then in third I went with a wrong approach to the problem and couldn't get my mind in the right position again. The person judging me just kept putting pressure. I got really nervous and couldn't do any more interviews that day... my mind really got completely blocked for the rest of the day.
That happens and, really, the company spent so much time of me (and me on them) for everything to be decided on that? feels wrong..
I'd say 8 hours is too long. I always strive for a 4 hours, but I've seen that 4 hours chop 16 hours off of the candidates time and more than 32 off of the companies.
> What's the point of maintaining an online portfolio and a github profile full of code
The vast, vast, vast majority of candidates do not have an online profile full of code. Either because their code is IP restricted or they do not have time outside of work to maintain that. I view using online profiles as a decided anti-pattern in hiring on the company side as it restricts your candidate pool to a tiny subset of the community that I've seen no evidence provides any more value in outcome and its much more prejudicial to the candidate population than any coding assignment can ever be.
It's not perfect, it'd be great if everyone could have a work sample but as you say that's just not the world we live in.
The reasons I don't like long coding assessment projects and the reasons I don't already have an example code profile are the same. Reinventing all the same wheels in different programming languages just isn't as fun for me as it once was, and I don't have as much time to dick around with any specific side project, especially ones that don't have any immediate utility to me or my family.
Does anyone ever ask about how I spec'd, designed, built, installed, and maintained my DIY entertainment center? No. Same methodology as building software, you know, except the problems are solved with different tools from a different toolbox.
If you're truly really looking for someone "T-shaped", you have to realize that the tittle on that T might include things entirely outside the realm of software or computer hardware, like how to hang a bear bag when camping, or how to fly a small single-engine aircraft, or how to train cats to use regular toilets, or how to run for political office, or what to do when you get a flat tire, or how to hold someone else's baby, or how to hit a gong target from 300m, or how to make a longbow for under $10 at Home Depot, or how to report a pothole so the city will fix it, or how to repair a pothole when the city won't do it, or how to play "Flight of the Bumblebee" while slowly rotating your B-flat concert tuba through 360 degrees.
All those miscellaneous, general-purpose skills do, in fact, make someone more effective at quite a lot of software-related tasks, sometimes in unexpected ways. But they are never going to appear on a resume, or crop up in the answers to any of the stock interview questions. When you include a criterion that specifically selects for people whose after-work hobbies also involve software, you are implicitly selecting against those who do other things, because there is much, much more to life than writing code.
There was only a very narrow slice of time when I actually wrote code for fun in my free time, from the ages of 15-25. It basically stopped after I got laid off from my first software job, and interviewing for software jobs became my next full time job. That's when I realized that I needed to do other things in my life, because it didn't matter how much I loved software if it didn't love me back.
So if you think need a portfolio to get a job, you might want to build one up that includes more than just code samples. The software industry does not love you back. It will move on to someone younger when it gets bored of you.
The difference is that we do this as paid work. Whatever their going rate is, we'll match it.
A surprisingly high number of candidates interview quite well and look promising on paper, but fail horribly in a "real world" coding test.
What company are you talking about hiring for? I'm looking for work as a programmer, and I'd prefer to apply to places with a hiring process like this. You can find some code I've written (a server clone for www.stockfighter.io/) at https://github.com/bcoburn3/forex
My email is bcoburn3@gmail.com if you'd prefer to respond that way
As developers, we often take a 5+ hour whiteboard interview on some of the fundamentals of CS, but presented as challenging problems. We may also have to do a take-home "project" which can be viewed as a "practical" component of a comprehensive.
I don't object to this per se. What I dislike about it (as I've mentioned on HN before) is that we take these exams without the protocols that evolved over centuries in exam-heavy institutions (universities, professions) to safeguard against abuse ensure the process is fair and decent to the people taking the exams.
The exam must not be capricious, it must be relevant and consistent across candidates, it must be created and assessed by competent members of the profession, there must be an associated study path, the content of the exam should't be a huge surprise to the candidate, candidates are provided with feedback should they fail.
And, perhaps most importantly, the process of taking and passing the exam provides the candidate with a certain stature, a lasting credential that is widely respected in the profession. The candidate doesn't have to re-take this exam over and over every time he or she interviews (in many ways, that is the point of the exam).
In many ways, I feel that programmers experience the downsides of this sort of professional entrance exam but without the positives.
I'm glad to see this discussed on HN, because I really do think that software "interviewing" as entrance-exam is one of the things that eventually drives people out of the field (or causes them never enter it in the first place). It's not a good thing for our field.
I'm not saying it's an easy question with an easy answer, just that our current approach is failing.
It seems pretty simple to me, if you consider the entire protocol as what it is: a negotiation, with one side asserting their dominant position.
Please excuse me hn for beating this horse to death, but for God's sake, Programmers of the World, Organize.
A surprising amount of people don't maintain a very impressive public profile (me included, tbh). These people need the opportunity to showcase their skills and the only way to do so is by spending some time coding a nice solution.
We try to minimize the candidate's overhead by providing general guidance in the challenges we issue (like "please demonstrate the SOLID principles").
Then we do a code review on the solution, in which we also spend some time. We point out issues, suggest possible improvements and give props on stuff we consider well done. At the end, if the candidate doesn't progress they at least learned something useful. We hope that this way our recruitment process might always be worth the time.
You're on the phone with them, you can ask them if they'd prefer a little challenge to showcase their skills, or whether they'd like to provide a portfolio example instead.
Maybe a bright self-taught college student switching tracks into software would pick #1, a parent switching jobs would pick #2.
More generally, I think the target should be to make the work sample test take a similar amount of time to the in person interview you'd have to do instead.
That's just shabby and disrespectful, regardless of how many other candidates they're talking to, or how they evaluated this particular candidate.
However I really liked the Thoughtworks challenges and couldn't resist coding for eight hours. It's better than spending one hour on-site for a badly designed 'challenge'.
I could be wrong, though.
He is saying that even though he was working long hours at his current job, he was so enticed by this interview challenge that, even after a long and difficult day thinking about a (programming) problem, he couldn't keep it off of his mind on his train ride home.
> What's the point of maintaining an online portfolio and a github profile full of code if companies prefer to waste your time writing a pointless uploader?
There are a few problems with using GitHub or BitBucket profiles. First, not everybody has them, or they don't update them frequently, or whatever. Second, it's pretty easy to fake a GitHub profile by copy/pasting code from other places, using other people's code, or pushing broken stuff that doesn't really work. And third, a lot of people's GitHub profiles are cluttered up with a bunch of forked repos that they haven't even pushed code to and don't really contribute to at all.
I'm not at all worried about 8 "unpaid" hours.
It's better than a 5 minute brain teaser question. Any job worth having is worth spending 8 hours applying for. Anyone who views this as "free work" probably won't be a good hire for other reasons.
Instead I would have a Mock PR in a github style discussion forum. Have it be a contrived example of some things that could be improved or some things that could spark really good discussion. Give the mock PR link to the candidate and ask them to Peer review the code. Make the discussion and comments of the the candidate the basis for which you determine their aptitude. If they have a lot of depth in their critique then you can be relatively confident how they would interact with the team in a real work scenario.
As a candidate going through the job search process now, though, I have to say that it gets tiring to do a project or programming test for every different company. I can juggle more traditional applications (phone screens, on-site interviews) at a time than applications that require coding projects as I'm limited by the number of 4-hour (or 8-hour or whatever) blocks of time I can devote to completing a project for each one.
Mine is crafted so a really competent developer could get it done in 30 minutes, and intermediate 2 hours and a junior probably not finish. I tell them to send what they have in after two hours that I'm as interested in seeing the structure and thought process than the final result. It seems much better than having someone do it at the office or one a whiteboard for accessing basic competence.
Yes it sucks, but after you get bit once or twice by hiring people who knew all the right words but can't actually produce something useful you get a lot more open to it. I'll gladly take the time to take you out to lunch to discuss the job and code assignment and give feedback afterwards, investing a couple of hours into finding your next job shouldn't be this huge ordeal and gives off a diva vibe I don't want in my organization anyway.
While this seems like a good idea on paper, you know that people are not going to stop after 2 hours unless you force them to (i.e. by doing the assignment on-site).
>get it done in 30 minutes, and intermediate 2 hours and a junior probably not finish.
What kind of exercise could a junior programmer not finish? Give up or produce miserable code sure, but not being able to finish? Do you require some really strange domain-specific knowledge?
PS: The website in your profile doesn't seem to be working.
To me requiring me to waste that much time indicate the company being a diva, something I wouldn't want in my employer.
I've only hired tens of people, and while that is not a massive sample size, I'm still astonished by the simple questions we ask that people get stuck on. The one that continues to shock me:
"In any language of your choice, write a function that takes an array of ints and returns the sum of those ints (If you use a language such as php do not use array_sum)"
I'm just looking for something like:
function sum($ints) {
$sum = 0;
foreach($ints as $i) {
$sum += $i;
}
return $sum;Then we follow up with something like: "lets say your input array contains [4,-7,0], walk me through the code"
And we finally ask "talk to me about some things that could go wrong at runtime that might cause issues with this function". Expecting people to talk about overflows (maxint?) or if its a dynamic language like php, checking for non-integer values.
I estimate that around 50% of people get ruled out during the "coding" exercise mentioned above. It is astonishing that these people even apply for developer jobs.
Now the entire lot apply for jobs at your company, and you hire two of those who can code. Within 3 months the rest of the good ones have found jobs, but 30 others have temporarily been unemployed and none of the bad ones have been unemployed.
So you interview again and roughly 40% of the programmers you interview can't code. But that doesn't mean that even 5% of the programmers out there can't code, it just means it is the same bad programmers that interview in lots of places.
It is the same when employers say they are getting ten or twenty job applications for every open position - that doesn't mean anything because everybody who is unemployed applies to more than one place, but from only one side of the fence it sure looks like that.
Not trying to be a smart ass, but being average is not only the developers fault, it could also be the company's.
However, I'm happy to work on any real task for a reduced or limited fee. It's a win-win: the company gets to know the candidate under real conditions, has an actual task solved at a reduced price, and the developer does not give away his/her time for free. Plus, if it works out, the candidate has learned already the first steps about the company's system and process and can directly build on it.
I'm always wondering why not more companies do this.
If you're dealing with too many candidates, issuing a simple 1-hour coding challenge will weed out the uninterested (and won't favor people that have 4-8 hours to devote to a huge coding challenge).
* The 2nd guy I've interviewed with was completely non interested on doing it. He was checking the phone all the time and getting off and on. I felt so awkward because of his lack of interest.
* I didn't get _ANY_ feedback at all, just got refused. After 6hours in their office...
Yeah, either you pay me for that time, or I'll just look elsewhere.
(And granted, that might exactly be what the company is looking for: a way to reduce the amount of applicants they have to sift through)
Timed coding tests are just a waste of everyone's time, whether it's a weekend take-home thing, or a 30 minute whiteboard thing, or anything in between. They do not account for individual developers' needs, like privacy, their own editor or IDE, and they exist in this ether between bullshit trivia and an outright working internship that ought to be paid.
The other huge thing is that in a lot of firms (I doubt Digital Ocean is like this, but many firms are) "programming" is a low-status, junior activity. In these companies, if someone asks you to write code in an interview, especially if you are an experienced candidate with a GitHub profile, references, and project experience, then even merely asking you to code is more like saying "dance, monkey, dance" and setting the whole atmosphere of your negotiations and interviews in such a way where you are the lucky low-status person who should be so grateful as to receive a job.
Unless you get a really great cultural feeling from speaking with technical team members first, the best general advice is to simply reject employers who ask you to write code. If they ask you to write code before even speaking with you, absolutely reject. Full stop.
I also think all candidates should fully reject internet-based timed "exams" as well. Things like HackerRank are designed to commoditize software labor, which is a creative design activity and if it even can be commoditized at all, it surely can't be boiled down to data structure trivia that you have to code around in a browser-based IDE with a literal clock ticking down.
Anything like HackerRank immediately screams "quantity not quality" and is straight rejection-worthy, no questions asked.
Sure, you would think that would be a trivial task for a professional coder. But it is amazing how much you can accomplish without ever having to do anything other than model some data, write some business logic and security around it, and build a front end. Frameworks FTW. The downside is that they don't know how to code without the frameworks.
Here, do the T branches apply only within computing, like knowing more than one software tool? If so, I think that's not what Tim Brown meant.
Presumably an interview seeking signs of "T-branching" would propose higher level questions, like business acumen or domain curiosity or spontaneous Q&A to better understand or elaborate the requirements needed to solve a representative problem. Otherwise the "T" just equates to broad software skills.
Being able to take a Sunday to work on a challenging problem in my own editor / computer / dev environment sounds great! I wish that all companies added in their job ads something like 'if you want to skip the whiteboard send us your solution to this problem together with your resume' where the problem is a representative problem of the type of work they do, then you spend the interview discussing your solution as opposed to playing algorithm-roulette.
It would also cut down the uncertainty when you see a job ad where they ask for all sorts of different languages / skills, if you have fun doing the coding test, it's likely you'll enjoy working there, and vice-versa (in which case you might decide not to even apply)
If you're applying to just 5 companies, that's a full (well 40-hour) work week of effort for a small chance of going forward with the next stage of the interview/hazing ritual. Might be good if you are already unemployed, but incompatible with candidates who already work.
First out of the 4 I did what was asked but got refused because I didn't clean up the code afterwards ( I thought I'd been cool for demonstrating some lesser known functionalities of the language and API I was dealing with). If I've spent 4 hours doing it, I don't want to spend 2 hours making it really pretty.
Second out of the 4 I misunderstood the instructions so I went in and 'fixed' their code to make it work they way I thought they wanted it ( was maybe too tired since it was late at night after a day of working on a personal project) This was actually a job that was close to one I really, really want.
Third out of the 4 I can't remember anything about it now.
Fourth out of the 4 they really liked what I did and we had a great interview, and then I got turned down because they thought I wasn't really that interested in their company (which was true, I was just fulfilling a job search requirement while getting my startup going)
Aside from that I interviewed at a social analytics startup one time and we ended up talking data mining and they asked me to do a 2 weeks project with them to do a POC of sentiment mining Twitter/Facebook. I gave them what my consulting fees would be, but they seemed really interested in me doing it for free as conditional for pursuing employment there. So I never got to try that coding exercise.
I chose Clojure since I was learning it at the time. The problems were easy and I made working solutions, but the framework wasn't working. I gathered some call stack data and sent it to the people that make the tool. They thanked me for the feedback and later fixed the bug.
I sent the completed code by email to the company with a note about what had happened. Showing clearly that my code works in the form of some tests.
Then, on the basis of this they didn't proceed.
Incidentally, this is exactly how the "Sun Certified Java Developer" certification was structured. You were only allowed to use java.* and javax.* packages provided as part of the JRE, and even among those things like the SQL packages were off limits. Instead of sending a test suite, they provided an interface you needed to implement and then when you submitted it, they had some sort of test suite that tested your code for conformance to the spec (and if it failed, you failed). If it passed, someone would manually review your program to make sure it made sense with respect to the requirements (which were intentionally somewhat vague, like real requirements) and if you passed that step, you had to write an essay about WHY you made certain design decisions (like sockets+serialization vs. RMI, etc).
This was by far the most challenging and fun task of its type that I've done, and to this day if I see that someone has that certification I know that they have what it takes to get things done. This methodology should really be utilized more, although for many companies the overhead of designing such a challenge would be way over the top. Makes me think that things like https://www.stockfighter.io/ have a future in our industry.
I try to ask questions that aren’t completely ridiculous, but definite tests of knowledge. And in my mind I judge correctness not so much on remembering obscure syntax but on how they approached the problem, and how much time it seemed to take them to start doing something. I always ask about things like how they approach debugging, testing, etc. because these are important too and they tell you a lot about how likely the person is to be able to handle any problem you come up with.
Codility.com is a software as service company that automates this.
it also takes very little time to introduce and solve which is a plus since we prefer to give it out in-office. but we do tell the candidate beforehand that there will be a 15 coding challenge so they don't panic.
You just have to determine whether I am a liar--or, more generously, simply unable to assess my own abilities accurately.
- how is this worse then rewriting the wheel? write code only when you must
[0]http://blog.codinghorror.com/we-hire-the-best-just-like-ever...
I doubt Digital Ocean does this since they want good people, but a lot of firms absolutely design their hiring process to create an upper hand and lower your status before you even walk in the door -- especially if you're an experienced engineer.
Short timed tests or whiteboard hazing are the worst version of this. These are the most blatant attempts to commoditize software labor down into a fixed set of "primitives" like data structure trivia or riddles. This is what organizations like HackerRank exist to do: allow big companies to suppress wages by creating these sorts of commodization filters. They don't attempt to capture the value of creative problem solving at all -- because the company is not pricing the value of creative problem solving into the budget for the position, since it's a rank-and-file commodity job.
For this reason alone, you are better off flat out rejecting anything like a HackerRank test or similar online, interactive, short timed test. I would absolutely go so far as to even refuse to write code on a whiteboard if asked to do so in an in-person interview. It's fine to talk about how to solve a problem and spec things out. But the minute it becomes focused on actual fucking syntax, it's game over. You are now a cog.
Longer-form tests are a lot harder to evaluate from the candidate's point of view. Now you are asking for a significant chunk of my time, without paying me. And I am still at the mercy of whatever you happen to think constitutes a valid test. I might look at your take home test and thing, "wtf? this has nothing to do with real world work." Where does that leave me? Of course I want to impress the hiring staff, but I also don't want to get roped into a bad job, and a team that hires me to do real world work by using contrived coding examples is probably not a good place to be.
Personally, I think it's a lot more useful to talk about code that already exists. Either example code form the candidate, or example code that you give to them along with some time to study it.
Engineers read code more than they write code anyway, and right when you hire someone, even if you're a bleeding edge start-up, their short-term impact is a lot more predicated on their ability to read code and quickly learn a new system, not so much writing a bunch of stuff from scratch.
It's also pretty hard to fake competency when reading and discussing actual code. If you don't know how something works, you just don't know. You probably can't just google how the internals of some highly-specific ad hoc code works, unlike data structure trivia (which is yet another reason why it just doesn't matter how much data structure trivia you have memorized).
Basically, my overall conclusion is that when someone asks you to code in a short, timed setting, they are basically lighting a cigar, fingering their handlebar moustache, kicking their feet up on the table, and saying "dance monkey dance."
Unless you are literally desperate for the job, you should reject it right away. You are being positioned so that no matter how well you do on the test, you are but a lowly code typist and they will not take your attempts at negotiation seriously.
Whiteboarding, sure. Homework assignment that takes 8 hours, as the author experienced? No way. I'm good, my hourly rate reflects that, and I don't work for free.
Or, they haven't. Which is why articles debating interview coding policies show up on HN almost every day. There is no "one" way.
>But if you're any good
And yet it's also well known that companies just can't get the engineering talent they require. Where is the discrepancy occurring?
First, why is it useless? Because it is an artificial and contrived exercise and not real work. Even if you design your requirements to mimic your real work environment, there's something key missing; the candidate has no knowledge of your team and your environment. How I would write code for my current team vs. how I would write code at any other job I've been at is different. You're basically asking the candidate to take a guess at what kind of paradigms your code reviewers like and what they don't like and hope it works out. One team might find use of closures smart and great, and another might find it unintuitive and adding unnecessary complexity. Your applicants have no way of knowing and just have to hope they write code your team likes.
On top of that, one contrived exercise is not a good way to get an idea of a persons' actual skill and knowledge. I'd much rather have a 30-90 minute conversation with someone where nobody writes any code than to review a contrived example. I get the appeal of the programming task, it can be done asynchronously and thus doesn't require any developer time until you go to do the review. But is it really saving you much time? Anyone who's code doesn't pass unit tests or any other automated level of screening wouldn't probably make it very far into a conversation either.
If I have an applicant spend 1-4 hours writing a code example I've had them use at least as much and probably more of their time for far less benefit than if I had simply called them up on Skype and talked to them about programming. The conversation will reveal not only a lot more to me about their actual skill set, but also their personality and how they might fit into my team. Now I realize teams doing exercises aren't skipping the conversation step, but I'm advocating for skipping the programming task step and going right to the conversation if someone's resume is solid and they can intelligently answer some basic questions (a handful of questions that should take no more than a couple minutes to answer, not an essay.)
Second, why would I say it drives off good candidates? Because I know a lot of really good developers (including myself) who skip any job posting that requires writing code as part of the application process. Why do I do that? Because it tells me the team behind this application is immature. They haven't yet gotten to the point in their careers where they realize these exercises are a waste of everyone's time. That means there's probably going to be a lot of other young dude bullshit in the team that I'm not interested in dealing with.
Even with whiteboard interviews, you still need to prepare for them. I would say I probably spend at least 8 hours preparing for them mainly because of its arbitrary nature. I have no idea what they will be asking.
With a take-home programming challenge, there is less uncertainty. By looking at the exercise, you can make a good estimate on how many hours it would take and see if it's worth doing.
After those 4 weeks, I didn't get the job. Around the 3rd week I felt like my time was wasted. I want to work for this place, but if I want try again later in life, I probably won't because it took up way too much of my time with little to no value.
It sucks that I'm required to sacrifice my personal and vacation days to find potential new employment.
We detached this subthread from https://news.ycombinator.com/item?id=11290180 and marked it off-topic.
I guess I should be grateful that I look older than I am because of my rapidly receding hairline.