I tend to look for developers now that have a better sense of modeling and api design. One interview that works really well is modeling a chat app and going through all the edge cases. Also a fan of Rob's Pairing Interview that is executed by pivotal. Build an array or perhaps a set from scratch and pair on building it where the interviewer is a driver and the interviewee as the navigator.
In the same vein: why are algorithms preferred over discussing data structures? Knowing a lot of data structures, when to use them and how to combine them is probably much more broadly applicable than knowing a lot of algorithms.
I've never seen a project that went off the rails because the people on it failed to understand algorithms or the proper time to use a deque but almost every project I'm handed to work on has a data normalization issue.
Alas the Google cargo culting will probably continue...
Actually, there is. And it's quite simple, really:
"Thanks very much for your time, but I've gone through many, many rounds of questions like these, and have come to the conclusion that, while interesting and to some extent topically relevant, ultimately the ability to regurgitate answers to them on the spot has extremely low relevance to the work that one actually does as an engineer. And BTW I noticed your statement of the problem was not only very muddled, but English-wise, barely readable. And actually, as presented, the problem isn't actually tractable, math-wise. And like, you brought me in here to solve the knapsack problem on a quadrillion integers in 2K of space or whatever and yet, you couldn't even think to stock the whiteboard with fresh markers? Or clean it first, for heaven's sake? Really, what's up with that? And gee, isn't the vibe in here, like, really really starting to suck now, given that at one of the interviewers is starting to fumble with his phone already, indicating that he would clearly very greatly prefer to be somewhere else, doing just about anything else - like you know, actually productive - than what you've forced the poor sap to do for you right now?
"But we don't need to dwell on that. The point is that we have different perspectives on these things, which is of course perfectly fine. So if you don't mind, howabout we part ways and do something else with the rest of our respective afternoons?"
You have to do them.
Beyond tending to basic needs (shelter, clothing, food, etc) you don't "have to" do anything.
You may not get to work for those companies (and it is a great many, unfortunately) that have bought into the whiteboarding cult. And that may seem to kind of suck. But it's not like you "have to" work for those companies (as much as they would dearly, dearly like for you to implicitly and unquestioningly believe exactly that).
With a large amount of experience, we as interviews, should be asking much more about past projects and issues people have run into. I find it much more valuable to understand what real world problems people have faced, and how they solved them. Sometimes you even get to a point where someone actually has a good story about using the wrong algorithm, and so you still get to talk about algorithms.
This tends to also tell you a lot about the candidate’s abilities to work in the environment you are thinking of placing them into. Algorithms questions should be a fallback only when you can’t discover this while running through questions about their experiences.
https://i.imgur.com/kE2ElEv.png
Switch it to auto and it will look a lot cleaner.
Otherwise cool site
If one can "crack" these interviews by spending a couple of hours on some interactive tool... then shouldn't that be an indication to those conducting these kinds of interviews that, fundamentally speaking, they might not be all that useful in the first place?
And not only that - but perhaps counterproductive? In that they explicitly reward not the thoughtful, disciplined engineers you want to hire -- but the drudges and go-getters who think, "Gots to get me into a top company - just tell me what I gotta do to pass the test!"
Shouldn't it now?
Do you really think that we're going to just look for correctly memorized answers to rote shibboleth questions and then tell the hiring committee "sure, $CANDIDATE would be a great programmer!" ??
Btw, engineers love algorithm & data structures questions because they're easy to judge and learn. Not because they're good at judging candidates.
Doing well on CS puzzles is and probably still be required for a long time to come. More of a hazing ritual. What I think should be allowed is for the interviewee to pose the same kind of ridiculous question to the interviewer, if the interviewer fails, the candidate takes their job.
If I ever really needed another job, I guess I'd have to suck it up and refresh myself on that stuff. That's a shame.
It has nothing to do with Rust, of course.
