Perhaps the next thing will be AI driven coding interview robots. Why bother with people when you can optimize the whole process without human intervention? Call it Being Interviewed As A Service.
Heck, it might be easier to train an AI for the task of passing coding interviews as opposed to you know, actually replacing real software engineers at their jobs.
I always hated algorithm interviews when it came to applying for web development jobs. I've been a developer for 8 years now and I have only had to use any algorithms once in my career. I get it that for facebook, google, and what not these could be representative of the work you do but I don't think this is a good interview.
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.
> I tend to look for developers now that have a better sense of modeling and api design.
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'd rather interviewers asked about database/relational theory.
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...
Well... I'm smart enough to stay the hell away from work where I have to deal with databases (and lucky enough to not having to had to deal with them so far). So I guess I'm saying that I agree.
But the fact of our industry is there is no way around these interviews.
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).
You are right, you don't "have to" do anything, as long as you don't want to get a job at one of these companies. :-)
The truth of the matter is that, at the end of the day, some companies can afford to tell you no, even if you are talented, because they will get other people who want to do what you don't "have to" do. And it works quite well for them, as you can see.
My way of looking at is: "Are these people dealing with me in a way that makes me feel respected and valued, both as a potential colleague as a human being? And above all, trusted? Maybe in a 'trust-but-verify' sense, but fundamentally - trusted? If not, then who they are, what they're doing, how successful they are or how many people are supposedly all ga-ga to work for them -- none of that can begin to matter."
This is not true. You have to do them if you don’t have much experience, i.e. straight out of college. With no experience, these stand in for an understanding of your CS understanding. Organizations that put very experienced candidates through algorithms questions show that they don’t value experience, and I wouldn’t want to work there.
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.
Fresh out or not, a good interview process will involve technical problems. Some organizations will bias to "take home" style, others will do a whiteboard session either on a whiteboard or with a computer.
Good questions are going to be more than, build a linked list in JavaScript or a bubble sort. Those are pure algorithmic questions, but you still need to walk the walk not just talk the talk.
This has been my experience interviewing past couple of months . I have over a decade of fulltime experience. I still had to do tons of these whiteboard/algorithm interviews. And not its not just clueless companies doing them, everyone from google to local software consulting show down the street doing this.
If you have a high paying position that doesn’t require a license or certification to work in then you’re going to attract a lot of frauds, so these kinds of interviews are necessary.
Doctors need a license, and even so, you still hear about people who are found out to be frauds years later.
If software development didn’t have technical interviews the field would be full of people who wouldn’t know anything about programming, but who would call themselves developers anyway.
The trouble with "nice discussion about past projects" interview style is that it is super easy to pretend way more experience and skill then you really have. You are literally measuring how smooth talking that person is and whether has good idea about what opinions are cool now.
That is what fizz buzz or basic algorithms are for. Because really,smooth talking incapable collegus do more harm then normal incapable ones.
I disagree. I suggest you read about the behavioral interview. By using pretty well known techniques you can quickly get people into a situation where they feel comfortable in telling you about what they did or did not do.
For example, I recently had someone run through a distributed system's set of questions related to kafka and some AWS services. It became obvious through this questioning that what he had built was not capable of guaranteed message delivery, i.e. the system was lossy.
The rest of the interview was about this system and how he would rebuild it to make sure there were no messages lost between all the handoffs of the system. We got into many very detailed areas about persistence, atomicity, idempotentcy, etc.
It should not be a shoot the breeze conversation about buzz words, it should be a very detailed process of getting down to the most complicated piece of software someone has worked with. It becomes very clear, very quickly, if they are bullshitting you, and then you don't hire them.
Sadly this is very true. I had been working with a colleague who was a perfect talker about best practices and what not, and first to criticize the offshore team for bad coding, yet himself he was as well doing a lot of crazy things and sloppy coding, and breaking the build and shipping regressions on a regular basis.
Unfortunately I don't have a good solution to this problem.
I'm wondering how interviews in other professions look like. For example when you're a director of a hospital and want to hire a surgeon. I guess you don't ask him to come one day to make a little surgery for free.
Surgeons are heavily credentialed. You have to have school and residency and subsewuent tests what not. I don't think same would be appropriate for coders.
Fizz buzz etc. might detect complete frauds, and at the other end some heavy algorithm questions might falsely reject good candidates who simply haven't applied that stuff in a long time. I think small at-home coding challenges are a sweet spot. They too reveal total rejects, but allow the rest to demonstrate their broader level of understanding and organization. And they make great follow-up discussion items.
Is the industry staying focused on algorithms written in imperative Object Oriented languages for interview quizzes, or has anyone seen more functional styles being used? I know Facebook does a lot with OCaml so I wonder if they are strict about requiring proficiency in OOP patterns, or if it depends on what you put on your resume.
Engineers have used Coderust to crack the coding interviews at Google, Amazon, Snapchat, Uber, Dropbox, Lyft, Facebook, Microsoft, Netflix, Zenefits, Pinterest, eBay, Twitter, Cloudera, Salesforce, Tableau and many others.
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!"
Kindly consider, please, the predicament of the extremely experienced engineer who has been obliged to present a solid hire/no-hire opinion after conducting a technical interview.
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!" ??
The quote is a fancy marketing line to sell a product. Good companies don't use a coding test to straight out determine hirability. Or at least they shouldn't.
They aren't 100% determinative, of course. But by and large, many companies do place a great deal of emphasis on ones performance on these tests (perhaps being only partly conscious of the extent to which they're doing so).
Yes but no one actually gathers the proper metrics. Moreover, no one is large enough to gather meaningful metrics. Finally, for those that are and potentially do, they still seem to gravitate to "implement this algorithm which we could get a trained monkey to learn by memorizing" only "cleverly" encoded in a "question."
Btw, engineers love algorithm & data structures questions because they're easy to judge and learn. Not because they're good at judging candidates.
Interviews have more to do with signaling than actual ability to do the job, in all the dimensions that are necessary.
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.
This doesn't align with my experience. I just interviewed with Amazon a few days ago, just testing the waters to see what's going on in the rest of the world, and it was very 'leetcode'-ish. So much so that I ended up just telling the recruiter I wasn't interested in the position anymore. One question more or less required me to code up a BST from scratch and traverse it. I felt like I was back in my undergraduate algorithms class.
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.
Is coding a BST and traversing it that big a deal?
I routinely code tree traversals at my work, so my judgement may be clouded here, so I am genuinely curious here to know if most people here think that it is unreasonable to expect someone to code a BST from scratch.
In my opinion, BSTs are one of the easier things in programming, with a complexity that is maybe only a little above a for-loop. Most often, in real world, the more complex stuff happens in the business logic, or API contracts, or that sort of thing outside tree traversals.
Yes, I think you're lucky to be in a somewhat unusual position that let's you regularly work with problems like that.
I'm merely a junior level developer working on database engines. Most of my day-to-day involves maintenance of decades old code where the 'hard problems' have long been solved. I imagine my codebase ancestors might have needed thorough knowledge of trees at some point :)
Exactly. That's the name of the game today: You need to spend a week refreshing your algorithms and data structures and you can certainly "crack" those interviews.
I never got the point of it, but I see it as a ritual...
The grass is always greener. I switched to software dev from academia. There, instead of whiteboard tests, it was all about networking, letters of recommendation, having the right advisor, etc. I'll take the whiteboard any day!
Good point. Someone was making an argument the other day that a whiteboard algorithm interview is still relevant as it proves that you are able to sit down and learn your algorithms again. (Basically it proves that you are able to learn when needed).
https://www.pramp.com/#/ the ridiculous problems are about 1/3 of it. Interacting and thinking under pressure are the other 2/3. Best to practice exactly how one would perform.
