A Method I’ve Used to Eliminate Bad Tech Hires

I am 100000% behind this - I point blank refuse to do code tests because they are asinine and I probably have the exact same one in a private GH repository from one of the million other unimaginative tech hirers.

You want me to prove my worth? Fine, you can pay me for it and get something useful out of it at the end, as a senior developer I really shouldn't have to "Write a palindrome detector" to prove that I can code, I have a degree, we did that shit repeatedly!

Nice to see other people are coming around to this way of thinking

Do you also fundamentally oppose to contributing to FLOSS software because that's most certainly being used by for-profit companies. Or is that ok because others that don't profit from it can also use said software?

I do something that I enjoy and throw it away afterwards or whatever I tend to do with little programming puzzles and project Euler stuff or I do the same thing and a company profits off it. The profiting doesn't really hurt me so I don't mind it. I'd also argue that if the intention of a company is to profit off my interview code I'm hopefully filtering them out (as they tend to be pretty boring)...having people write code for you by pretending to offer a job is also all kinds of horrible strategically so I don't see the potential for a mass exploit.

I can understand your point of view but I hear the dreaded "but my time is too valuable" more often than "it's unfair that they profit of it". My argument was mostly that...if you want the job, your time probably isn't too valuable to try to get it :)

> Furthermore, turning problem solving into a theatrical event

That's a very interesting perspective actually.

If this process prevails then only a certain personality types will be able to work at companies which conduct such interviews.

The danger is that when the biggest and most successful companies (who's founding members didn't go through the same process, on the contrary were most likely solitary coders) conduct such interviews, the smaller and actually very nice places to work tend to copy the same.

I am somewhat in favor of the likes of Google and Facebook who need to filter an ocean full of applicants following this process.

But I have seen smaller companies copying the same process assuming they will find the similar hires as G and Fb. The funniest/hilarious part is when the recruiters start saying "we have a very bar" with so much conviction. Yes, you are a startup, you have a "very high bar" and you need to hire people who will scour the internet and integrate the various bits they find because they need to take the product from A to B YESTERDAY !!!

Although having said that, I think I may be a bit different from what you described. I actually don't mind whiteboarding or coding with pen and paper and I noticed for me it is a lot easier to "talk my thoughts" while whiteboarding. On the contrary, I get seriously annoyed if I have to talk while actually writing code and if it is during a job interview, I just choke.

> Expecting some kind of portal into someone's mind while they solve an unfamiliar and maybe tricky problem strikes me as overindulgent and voyeuristic. It is a flaw in the current technical interview process and the only way to mitigate its effects is to just get more comfortable interviewing.

Yes. We are problem solvers after all. A way shall be found.

I've used dozens of libraries professionally over the past year or so. Some of them I use every day, others I only need to touch once a week or once a month. Why would I be expected to memorise all of this when it takes only a few seconds to look it up?

I use Python, Clojure, ClojureScript, C++11, Javascript and bash regularly. I remember all of the standard library functions and third party libraries that I use a lot. But even after 15 years of using Python, I still have to look up, for example, the datetime module or what functions exist in the collections module. I still need to look up how to use the C++11 chrono library. I still haven't memorised the entire Clojure core functions (there are so many of them!) I still need to look up the DOM API for javascript (but then, I don't use JS that much).

I'm sure part of it is the context switch: if I were using one single language 100% of the time, perhaps I could memorise its core libraries. But why bother when it takes 3 seconds to look up and every professional job I've ever had its perfectly fine (expected even) to look up online documentation on the job.

So why not during an interview too? If your interview isn't testing me on what I'll be doing when I'm on the job for real, then whats the point? Testing my memory isn't a good reflection of my skill when working on real tasks.

Now, when I learned to program, I didn't have internet and worked completely from offline documentation (I learned Visual Basic, C++ and Python this way), so its not that I'm completely incapable of it, but it seems like a terrible use of my resources.

Being able to code under pressure when the world is burning is also different to working under pressure of a deadline. Or rather, being on the last day of a 30 day deadline isn't the same kind of pressure as being told you have an hour to complete a complex task.

Not everyone needs to be able to work well when the world is burning. Its not part of many jobs. However, if it is part of your job (eg your the guy who has to fix stuff at 4am) then I see nothing wrong with asking candidates to do timed work in an interview. I just think most jobs don't or shouldn't require this.