-- Dave, ITA cofounder and creator of some of the puzzles, including my personal favorite, “Rebus”.
"When implementing the server, aim for scalability and robustness. (Many submissions fail due to lack of robustness!) Your submission should include a description of the steps you took towards those two goals. Keep in mind that the client may be buggy, or even malicious. For example, if a client connects to the server and sends an infinite stream of the byte 'X' with no line break, the server should deal with this case gracefully. Please do not use an existing networking framework (e.g., Twisted or asyncore for Python, ACE for C++, etc.) to implement the server."
Not only no, but fuck no. I settled for a job in the IT section at a bank working with COBOL and EJBs because of this shit, until I'd finally had enough, co-founded a company, moved to San Francisco and implemented a SANE hiring process that treated candidates like professionals. Most of us did, so I guess in a way these horrible and misguided hiring practices were partly responsible for the next resurgence, because we'd finally had enough.
Please do not use an existing networking framework (e.g., Twisted or asyncore for Python, ACE for C++, etc.) to implement the server.
...would be a massively positive signal to me as a candidate. Places that truly value "full stack" abilities like this seem to be hard to track down.
If I want to see code, I'll tell them beforehand that I want to build a little project together with them (less than 50 LOC) that does this one trivial thing, and that they can write beforehand if they want to. Then when they come in, we either build it together if they haven't done it beforehand, or we change the specs if they did. And no, no bonus points for doing it beforehand. That's just so that they can feel more comfortable in the codebase if they feel it's necessary (being nervous in the interview and all). I'm most likely not going to compare their code to others; I'm only interested in whether their code meets the company standards.
I've also fired many people. It's not hard to do, nor does it cost much.
So many of these recruitment processes are predicated on the principle of "what if someone lies to us?" for fear of hiring the dud. But in reality, it's so hard to bullshit someone knowledgeable that the actual risks are tiny.
Yes, I've encountered people who couldn't code. I've had such resumes passed to me by people (usually non-technical, or recruiters) telling me how awesome this person is (because they don't know enough about the subject matter to tell the difference). But it takes very little conversation about any topic one is knowledgeable in to sniff out someone's bullshit.
Think of it this way: You have a leak in your house and hire a plumber. The guy comes and tells you that you need this and that. How do you know he's telling the truth? Now imagine that you're a plumber who's been asked by a friend to sit in on the conversation. How long do you think it would take before you can confidently call bullshit on what he's saying?
If YOU know your shit, you can tell when other people don't. And if you DON'T know your shit, you're going to have a hard time no matter how much code they throw at you.
I'm in Europe, so it's not easy to fire wrong hires after trial period, but I have never even seen anyone admit that they made a wrong hiring decision.
As an interesting case, one company I worked at hired an architect who had failed their rather trivial coding test but interviewed well. That person, together with company management, ended up driving away several competent engineers.
I won't work any more for employers who don't require a programming test. Your experience may be different.
On Wall Street everybody uses coding puzzles to screen candidates. There is really no other way.
But the online coding-puzzle sites they use are mostly really terrible.
It has also been my experience (20+ years) that sociopaths and egotists (the ones who will try to bullshit you beyond a few ham-fisted attempts) are in such a minority that they're not worth basing your interview process around.
The only cases of hiring engineers who couldn't code that I've ever heard of directly from colleagues over my entire career (that weren't third-hand re-tellings) have been where he either was not interviewed at all, was only interviewed by someone non-technical, or was hired by someone non-technical over the objections of someone technical.
TBH I think this is a manufactured problem.
However, from the linked page:
> To be considered for an interview, you may need to solve one of the programming puzzles below.
In fairness, they used the word "may". But I wouldn't call that "explicitly NOT required".
These are fun puzzles but terrible interview questions.
These appeared during the post-dotcom bust pre-startup boom period of 2004-2008. If you look at CS enrollment rates of the time you’ll see they were at record lows. Software paid well, but not that well and most engineering jobs were really bad ones resembling Dilbert comics. The culture of treating engineers well, giving them good tools, snacks, unlimited pto didn’t happen until later.
At the time people solving hard problems and keeping up with changes in programming languages and tech were doing it because they loved it. Nearly everyone doing tech was doing it because they where obsessed and passionate about it. This is because if you weren’t there where much more pleasant ways to make about the same money.
These ITA puzzles were a way of signaling “hey! we’re a company of people that love to code and work on hard puzzles too! If you’re the type of person that sees puzzles like this and can’t get it out of your head for the rest of the day, you should check us out!”
These puzzles were not a leetcode like gates (in fact they very explicitly were NOT required for applicants), but rather a way of advertising to programmers that ITA was not just another boring big corp that would suck your passion for coding away.