Saw this discussion on Reddit, and thought it might be of interest here, too (as such things perennially are):
I've been a successful software engineer for 10 years at various startups and small businesses. I do a lot of contracting on the side too. I've recently had cause to start looking for work again.
What the hell is up with these interview questions? They don't really have much to do with the ins and outs of clean code, architecture or collaboration. I had hoped they'd stop with this bullshit already. There's a lot of companies that promise 'No whiteboard interviews' like Triplebyte, only for that to be a complete and total lie.
They're more like annoying riddles I'd find in an Sierra adventure game or D&D. I'm just not very good at these types of 'riddle questions'. I know they always wind up having to do with binary trees, graph algorithms or something like that, but the dress-up and time constraints are unrealistically stressful.
I honestly wasn't very good at these questions when I'd graduated and I'm still not good at them now. How screwed am I? Are companies willing to hire based on projects and seeing live code?
I'm always careful to speak with my employers and convince them to write a 'portfolio' clause in my contract that allows me to keep code for the purpose of seeking further employment.
I really don't want to spend 3 months of my life learning how to solve riddles just to get another job.
I also suck at these kinds of questions, despite having designed and written a lot of software and systems. What say you, Soylentils, are these kinds of interview questions necessary to find good software engineers?
(Score: 2) by bradley13 on Wednesday March 08 2017, @07:09AM
At a guess, part of this is trying to establish basic competence. You have 50 applications for a position, all with beautifully crafted CVs and apparently good references. Of those 50, 25 are people the last company was glad to be rid of.
If you have letters of reference, maybe there is a hint, and maybe not. I once had a letter of reference, where the only positive thing was that the person kept their desk very clean. That's unusual, though. So how do you tell who's competent, and who is bullshitting? You don't have time to wade through 50 portfolios of code, so you have to narrow the field, ideally by eliminating the "programmers" who can't actually program.
So the idea of a couple of simple technical problems is to provide a first filter. The old FizzBuzz wasn't a bad example: it didn't require you to remember trivia, but did require a bit of thinking on your feet, since it's not as easy as one thinks at first. If it knocks out a couple of the competent people, because they're bad at riddles, that's life. The real goal is to knock out all of the incompetent ones, and it will do that.
That said, I agree with what another poster wrote: small companies are different. They are more likely to take time to understand your history, your portfolio. They may actually call your references. It's a different (and, imho, better) world to live in.
Everyone is somebody else's weirdo.