1. 6

  2. 6

    I got my dander up this morning at a particularly poorly planned interview test:

    To apply check out our github maybe make some PRs. You can also start by doing this coding sample (allow 20-40 min).

    Please do all your coding in that text box not an external editor. It is timed so please take it all in one sitting and do all your typing in the box. Unfortunately, because we have been getting a lot of applicants, we will not be able to respond to everyone but will reach out to folks who we want to interview within 2 weeks. You can also send an email to jobs@stellar.org

    “To apply: give us free labor, jump through this hoop, then maybe we’ll acknowledge you.”

    Also, I disagree with the conclusion of the article. In hiring there’s a risk that the new employement doesn’t work out. For the employer, the is the cost of HR processes and the risk of employment/discrimination lawsuits, but customers still pay and hiring rolls on. These costs are small and managageable, especially for large companies. But the employee puts up is salary lost while finding new work, damage to reputation after quick termination - but now the employee is not getting paid and has a harder time finding work. The employer risk inconvenience, the employee risks insolvency.

    There’s also a saying: if you take a job after an interview that any idiot could pass, you will work with any idiot who did. Most companies are not great at evaluating their employees and removing incompetent ones. If you get the “polite chat” interview the author describes, you can’t know if the company will filter employees any better after hiring than before.

    So I think there’s definitely a place for tests in hiring, but it has to be done well. Employers must respect applicants' time, use tests predictctive of job performance, and evaluate promptly, fairly, and consistently, This is hard, important work - but as a bonus, if you do it right, it’ll help remove subtle discrimination from your hiring process.

    1. 4

      This one died with the word “Agile”, if not before. Programming interviews are broken, but let’s not get stupid and throw them out entirely. Also, whatever “Agile” was supposed to be, it produced the unforgivable horror known as Scrum. Fuck Scrum.

      Part of the problem is that interviewers are often poorly trained or untrained (often, the training is, “talk to this guy and form an opinion”) and interviewees are (understandably) under stressful conditions that cause atypical reads on both sides. The process is often haphazard and errant. It’s hard to replace this with “take home” tests because then you get selection bias: the people who are really good, generally, won’t do them.

      We’re in the late stage of a bubble and there’s amazing incompetence everywhere– junior engineers and principal engineers, executives and founders and investors– and it’s easy to look at the horror show that is the typical interview and assume that it’s just a waste of time, talent, and morale. It’s not. It just needs to be done better. Right now, the industry is so polluted with unqualified people that it’s easy to mistake inadequate people for a failed process.

      One thing that irritates me about hard code interviews is that there seems to be no upside. One time, a few years ago, I put in a ton of work into a take-home code test and I was told that my solution was one of the best ones they’d ever seen (and this was a company that gets a lot of CVs). I still got a junior-level offer. Wall Street pays $250k out-of-college to IMO medalists who’ve never written a line of code, and fast-tracks them to high positions (or out), basically recognizing that some people are wasted in subordinate, low-level positions. In software, though, you can kill the coding test and still get slotted in at a junior level. (I’d probably be upper-mid level now, because I’m older and more experienced, but still…) So what’s the fucking point? It seems like difficult pre-work only offers downside.

      Since I think take-home tests are a lost cause, here’s an idea for how to improve the in-office experience, although it’s hard to cram into a 45-minute session: instead of making the person white-board some algorithm that she’d probably look up in a book and code just fine in the real world, ask her about something that she would like to do, for that company or some other. Then ask her how she’d design it. Keep focusing at lower levels. Eventually, zero in on a code-level component. “Interesting. So how would you implement that?” But let her drive instead of trying to shoehorn her into a made-up problem. That would have far better results, and while it might take longer (90 to 120 minutes) to do thoroughly, it would probably give you more signal than the 4x45 or 5x45 format. The problem? 90 percent of software engineers, and probably still 70% if you’re looking at senior ones making $300k++ at marquee companies, aren’t smart enough to conduct that kind of interview. So the cookie-cutter commodity-programmer interviews will go on.

      I really hope that whatever chickens-coming-home-to-roost event comes at the end of this bubble will purge the incompetence without tanking the compensation for people like me who actually know what they’re doing. (Maybe we’ll even be better off because we don’t have to compete with people who have better sales skills but who think that C++ is a bra size and Haskell is a fad workout.) Either way, ensuring that someone knows how to code before hiring that person is definitely not a waste of time, because there are plenty of people who can “talk technical” but have no practical experience or aptitude. The problem isn’t the concept of a programming test; it’s that we are, as an industry, bad at them.