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: 1, Insightful) by Anonymous Coward on Wednesday March 08 2017, @07:50AM (2 children)
I'd really enjoy it if we could go a few months without this "those darn interview questions are hard!!!" posts.
I friggin LOVE the whiteboard section!
This is a chance for not only the company to interview you, but also for you to vet the company.
This is the part where you're in charge and it's probably your first and last chance to seize control of the interview process and turn the tables.
You're going to find that the whiteboard interview boils down into 2 camps.
#1 "specific skills", they're looking to see if you know the tools you claim to know how to use. They want to see you reference at least some of the syntax of the language. The interviewer in this case is probably just someone from HR and has no real skill themselves. In this case, you just bluff your way through it, it's a breeze, there's something in the job description and they want to see and to prove that you need to know the right buzz words. If they have no basis of reference you can literally make shit up here. Just appear confident, be confident, because the interviewer just wants someone who's confident and can pronounce the right buzz words on the check list. The answer here was in the job description, so memorize that ahead of time.
#2 "analytical skills", in this case the interviewer is someone you'll be working with, possibly every day. If they're doing this right, then what they're looking for is not a specific algorithm, but the thought process you go through in order to come to an answer. They're also deciding if they want to work with your scraggly incompetent unconfident ass. This is an incredible opportunity for you!
The person interviewing you is someone you'll be working with, the question is going to be related to something they're tussling with whether they're aware of it or not. I usually turn this into a collaborative whiteboard session and use the time to demonstrate my ability to lead by getting the interviewer to give me the answer. How? By turning the tables on the interview process. This person either knows the answer already, or you're helping them figure out the answer. Either way, no matter what answer you provide, it's not going to be good enough.
You need them to give you their answer and you do this by asking questions as you go through it.
Then as they start giving you the answer they want and you start seeing the bigger picture, then you just say things like "you know your answer is great, but have you considered .... ?" or "Wow, my answer would have been .... but honestly your answer is better. Even if I don't get this job today, I've learned something new, thanks for that."
So the real answer here is don't lock up like you're 16 again, it's prom night it's your first date ever and the head cheerleader is your date!
Go into the interview with the mindset that no matter what the job is, who it's with or how much it pays. You don't need THAT job, hell you don't even need A job, you're looking to fill idle time or you're in the process of deciding whether to leave your present employer because they've offered a smaller raise than you wanted or your deciding whether or not to go back to a 9 to 5 from contracting because 20hr days are the norm while contracting.
Either way, keep in mind that the whole interview is about 2 things, confidence and competence and competence really is a secondary concern because no matter what your background you're going to have re-learn everything their way. Just be flexible, adaptable and confident everything else takes care of itself.
(Score: 2) by theluggage on Wednesday March 08 2017, @01:30PM
I friggin LOVE the whiteboard section!
It sounds to me that there's an important distinction between the "whiteboard programming challenge" (write me a simple sort routine -> now tell me why it is shit -> what would you do if you had to sort a table with 100 million entries*?) and the "whiteboard compsci trivia quiz" (write down the algorithm for Fullers's Tangential Dropsort).
I'd also use "Here's 100 lines of code - how many bugs can you find?" - and if the first words out of their mouth are "brace style" or "it isn't written in Haskell" show them the door.
* Correct answer: use an existing library designed for big-data DBMS, or at least look up an algorithm written by someone who did their whole fucking PhD on sorting large datasets. Or did you want me to sit in my cubicle for a few weeks re-inventing the wheel?
(Score: 2) by VLM on Wednesday March 08 2017, @03:00PM
They want to see you reference at least some of the syntax of the language.
That aspect makes me nervous sometimes. I use emacs, the last time I typed and indented a right parenthesis was ... a long time and a couple languages ago ...
Also I'm lazy and paranoid so I put all the brain cells on testing and system level stuff and I'll look something obscure up online every single time. two decades screwing around with mysql and I still occasionally pluralize INTERVAL types despite having made that mistake a zillion times, but I never do anything really dumb, however. Oh here's another good one, you'd think after 20 years I'd have memorized that DAYOFWEEK() result index starts at 1 is Sunday but every time, including typing this post, I have to look it up, or I do something dumb like Monday=0 or whatever. Hilarious. I suppose I wouldn't want a lower level job where my only thinking task is remembering that Tueday=3 or WTF anyway.