SoylentNews is people
SoylentNews
from the prove-Fermat's-last-theorem-using-only-a-protractor-and-straight-edge dept.
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: 3, Interesting) by Thexalon on Wednesday March 08 2017, @02:04AM (2 children)
Having been on that side of the table, I've found that the simplest FizzBuzz problem more often than not trips up the truly unqualified candidates. Because, as you point out, they don't understand loops, rarely really grasp if-elseif-else constructs, and in some cases even variables. The difference in a nutshell: A qualified candidate came in, took one look at the problem, said "Really?", typed out a correct answer immediately and handed the laptop back. An unqualified candidate came in, read the problem, and spent 15 minutes wracking his brain, with me giving him a significant hint about 10 minutes in, and he still didn't get it.
And I completely agree that hiring an unqualified candidate is approximately the most dangerous thing you can do. I've seen the aftermath of hiring the proverbial Paula Bean [thedailywtf.com]: There were moments in the code where you could tell "This coder just began to understand the concept of an array!" and similar moments of epiphany.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Snotnose on Wednesday March 08 2017, @02:27AM
Yeah, when I interviewed people I started with easy questions and got progressively harder. Fizzbuzz was usually the 3rd/4th question, about 10 minutes into the interview, and it was the biggest weeder I ever found.
Of course, that was before google was so popular, now I expect every incompetent idiot to google "interview questions" and learn fizzbuzz.
When the dust settled America realized it was saved by a porn star.
(Score: 3, Insightful) by SomeRandomGeek on Wednesday March 08 2017, @03:33AM
I've worked with some of the Paula Bean's of the world, and the mind does boggle. But they are not the worst developers to work with. The worst developers can spend an afternoon arguing with your team's otherwise most productive developer, then go back to their desk and inject a defect, to be found later at great expense. By comparison, doing nothing at all hardly seems that bad.