| I think the tech screens are the worst part, they're often so artificial and unlike the actual job that they result in a lot of false negatives. Here's how I rank the methods I've seen recently from best to worst: 1. FizzBuzz, quick and easy for anyone who can actually code. Honestly #2 is about as good, but this is quicker, so I put it first. 2. A code review - this is something most jobs will actually entail. Coming at some bit of code or a PR cold is something you'll do on the job. Spotting
problems is something you will really need to do. It's not quite coding, but I'm going to google half the things I need to do, tweak someone else's working code and move on. To quote my favorite manager, "I love lazy programmers, they're the best!" 3. Pair programming to improve some already or nearly working code. This isn't too bad lets you feel out if you can work with the other person too. Writing whole algorithms from scratch is something that I'd google first anyway, so testing on that is silly. 3. Take home coding challenge - Awful and wildly burdensome. Can be a big time expenditure as they're often not trivial. 4. Live coding in a browser - Awful! Nobody actually works like this. So you're not testing for reality at all really. And having someone watch over your shoulder as you code can bring even the best and the brightest down to "can't write an if statement". Wild amounts of false negatives. 5. Outsourced, proctored, coding exercise. I halt the process at these now. Ridiculous practice. Using #3-5 is a major red flag to me about the company. They don't know how to hire and/or have industrialized the process so how good can my team be? They already see developers as cogs. |