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, Informative) by khallow on Tuesday March 07 2017, @11:44PM
There are a bunch of things you can do to prepare for such questions and strategies you can employ during the interview to better your odds. Here's my approach:
1) Don't start by throwing code on a board. You can get a lot of mileage without touching the board at all just by describing your mental thought processes and what you're thinking at a given phase of problem solving. Try to connect with the audience via the usual public speaking tricks (like looking at the audience, focusing on one person at a time until they acknowledge you and then moving to the next).
2) Is the problem statement conflicting or too ambiguous? Never make a big deal of this. Real world crap has this all the time and one of the things you're showing here that you can handle this stuff. Even if they accidentally pass you an impossible or poorly constructed problem you can show off your skills at getting reasonable specifications for a project. I'd write the new specifications in a corner of the white board both so that I remember what's going on and to keep everyone honest.
3) Is it a trick question? You're asked to sort balls by color, but there are only white balls. Again, this might be unintentional, but you can then show how you'd do things, if the trick weren't present.
4) Use a standard bag of tricks and algorithms that you are confident in (including being able to write code for) to to specify and solve as much of your problem as possible. It's still progress, even if you can't solve a problem completely with this approach. If you can get away with high level flow or object diagrams, then do so. It's faster and less prone to error.
5) If you can make progress, but don't know how to solve the problem outright, you can still hand-wave strategies you would try ("I'd first attempt to brute force this, but if that didn't work, I'd try...".
6) If you don't have a clue, say so and have a stock answer. "Sorry, as a DB specialist I never had much exposure to DSP. I'd read up via google on how the FFT is used to construct low pass filters, download appropriate libraries, and pray it works as advertised."
7) Get a feel for their development and management style. For example, if they use a development approach that is heavy on test cases, you'll probably want to spend some time discussing how you'd make test cases for your solution from simple data checks to complex use cases.
8) Don't lose it. You will make mistakes, bad things will happen, or you're receive criticism that you don't have ready answers for. Use these as opportunities to show that you can deal with the unexpected and keep going. "Sorry, I just don't see my mistake here on how this list ending is going to blow up. But the runtime program sure will. I'd have to catch this error, debug and step through the linked list code, and see where the faulty linking breaks down."
9) Think about following up. Discussion during the white board interview could be a useful icebreaker for a near future conversation either during the interview process or later if you're looking to network.
Always look at interviews as an opportunity not a burden. You get a chance to visit a place, see a little of its inner workings, and get a feel for whether this is a place you want to work for - meaning this is a two way exchange of information. They're not going to waste employee time with a large number of interviews so it's a high value contact.