Reciting CLRS is not useful. Knowing why a greedy algorithm like Dijkstra's is optimal can be both beautiful and insightful. A fundamental understanding of these algorithms and data structures only add tools to an engineers arsenal. Of course, code should be the medium through which the interviewee expresses these to make sure she/he is not simply a mathemetician
A good engineer should have a good base in algorithms, know which one to use for which problems, and when the algorithms matter and when they don't. And be able to research literature for appropriate ones when the need arise. That's not the end of what qualifies a good engineer, but it certainly is part of it.
CS and math researchers write papers (partially) so that engineers can pick them up and use them to improve on what's possible to build.
The types of "good engineers" that exist are numerous and varied. For many, possessing (and retaining) detailed knowledge of algorithms is a waste of time that will practically never be useful.
The vast majority of programming jobs are such that the people working at them will never need to understand these things. It's a sad state of affairs, but it's how the world is.
Along those lines, most people feel that their programming jobs don't fall into that category.
Try Project Euler, https://projecteuler.net/. It doesn't care the language in which you code the solution... as long as your answer is the right number. Since the problem set starts with some easy ones, it is a great site to try out new languages (or new techniques like dynamic programming) and start with a low problem number.
Best way is to paid-intern an engineer for a week/month and try them out (if they're willing) and see how they fit and might be able to expand on your current culture. That's really the only good way.
Asking questions in an interview, no matter how clever or insightful they may be, has been and will forever be a crap shoot.
It's the only really good way for the company, provided that it doesn't filter out good applicants who would have very good reason to decline leaving a full-time position for a chance at full-time somewhere else. I don't see how it's good for the employee though: the company is effectively shunting the risk of a bad hire from someone who is reasonably positioned to take the risk (despite what entrepreneur blogs may say) to someone who is very poorly positioned to take this risk, and pay them nothing for taking on that same risk.
Sure, it'd be nice if you could hire all your great employees this way, but forgetting for a moment whether it's fair, it's not realistic.
I could see this working if say the company said, let's try this out but let's do remote for weekends only. This way I don't have to quit my current job and they can try me out for a while before they hire.
For me, speaking as a software engineer, I highly agree - if a company tried to pull that on me, that would be a quick way for me to turn down the company. It doesn't make sense if the candidate is working for another company - why would the candidate use up all of his/her vacation for one company if the company isn't serious about bringing the person onboard full-time as a regular employee off the bat?
To be honest, having experienced the tremendous damage done by poor hires (and the amazing difficulty of getting rid of them once they're identified as such), I might see this as a pretty substantial benefit of working at a company that uses this method. Given that, I might be willing to participate in this kind of interview process. It would probably have to be a company I already know and admire for some reasons up front, but I really want to find a place to work where everybody is pulling their weight.
Yes but by doing this they have shifted all the risks to the candidate. Unless the company is super hot or they substantially compensate financially for that risk.
I haven't seen a decent-sized shop where "everybody is pulling their weight". Different developers at are different points in their careers, and have different levels of productivity. As a junior developer, I was very slow when I first started. As a senior developer, I have produced 50% of the work for a project on a team of 8. There are only so many developers that want to work for [insert company] out in the wild.
I do sympathize with the big damage done by poor hires & problems getting rid of them - I have seen similar as well. However, a process like this will select against a lot of quality developers and not necessarily select for the ones you want to work with. It just selects for the developers that that company wants to work with who are willing to jump through such an extra set of hoops. It also tells me as a candidate that the people who are working there don't have the courage to speak out against such a process selecting against candidates not willing or able to go through the process or the leadership is too weak to figure out that this sets up a bias that isn't intended to be selected for, thus being a bad hiring mechanism.
Right, I meant "pulling their weight" in a relative sense, with the understanding that a more experienced and talented employee will do more work or do it more quickly. Maybe my desire is simply to increase the proportion of coworkers who make roughly appropriate contributions to the team effort. I once had to explain how splines worked to a graphics programmer with 20 years of industry experience.
A trial process like this would select against lots of quality developers, true, but that isn't the real question. Instead, I want to know whether the developers who wind up being hired represent a more talented subset. I can't prove that it would, but I feel that this system would be more accurate in letting the right people through.
All that said, I like some of the gray area solutions proposed in this HN thread, including after-hours or weekend remote work on a project already in production. Not a perfect solution, given the inability to evaluate things like culture fit, but it combines many upsides of the alternatives.
>> I once had to explain how splines worked to a graphics programmer with 20 years of industry experience.
Is the knowledge of splines a major predictor of a graphics programmer's success? I don't understand why it appears to be a point of denigration here. The details of your story are foreign to me, of course, so maybe I'm missing context. But it's always helpful to remember that time is finite when compared to the seemingly infinite amount of things to learn. No one comes to work and says, "I want to suck today!"
"To be honest, having experienced the tremendous damage done by poor hires (and the amazing difficulty of getting rid of them once they're identified as such)"
And yet companies will still let good engineers walk out the door because a competitor is willing to pay them 20% more.
and the amazing difficulty of getting rid of them once they're identified as such
Everyone always talks about how "amazingly difficult" it is to get under-performing people to leave, but really, why is that so? I find that simply saying
"You know, we don't think this arrangement is working out for either of us. Can you please do us a huge favor, and resign? BTW if you agree, here's $X, a perfectly respectable severance package that acknowledges that you are human being, and that this was just as much our mistake as yours."
pretty much always works (provided the company is willing to swallow $X, which if they have any integrity they should have no problem doing). You don't have to say the "this was our mistake part" of course, but that's what the $X is for, because it says it implicitly (and in a more substantial way than mere words ever could).
Of course, there's also the task of getting other people to see that someone is under-performing, which can be quite difficult sometimes -- but that's a separate issue (and if it really is especially difficult to have these kinds of conversations with persons of authority in your group, then maybe you should be moving on, as well).
I agree strongly this is the best way to interview a candidate. It's even relatively easy to set up for a new grad or junior candidate who isn't currently working. They should of course also be local or have no family or professional commitments that make a week-long non-work trip difficult.
Sadly, many of the best engineers I've worked with do have families, are working, don't live in the same town, and would absolutely balk at the idea of taking a week away from all that to "try out" a new job.
Of course, there's a wide spectrum between "work together for a week" and "write some C++ on a whiteboard for 40 minutes" that gets dropped from most screening processes. That's the zone where I'm most interested in finding creative evaluation tools.
We've found a good middle ground. Giving the candidate a few days to do a test project that involves fixing a bug on the production site. Its something they can do at night after work, gets them resolving a real-life problem, seeing how fast they figure out the codebase.
In demand DevOps candidate here. I had multiple six figure offers from companies, and still picked the job that required a 4-6 hour project I completed over 2 weeks in the evenings (that I was paid for).
Provide the right work environment and perks, and people will "jump through hoops" if they think its worth it.
The job with the best team. Generally, the job where you have to jump through hoop will have a team who has jumped through those hoops as well. It's all about vetting.
I don't know, if a company asks me to complete a simple test application, I might be more inclined to talk with them, because it means my interview (ostensibly) would be about the code I'd submitted. Which in turn is much more like what a day in the life of a developer would be like at their company (I write code, review with team lead, repeat, or somesuch).
I think really good candidates will enjoy working on relevant issues and not working on silly interview questions. If anything these "hoops" seem like exactly the filter you'd want. You want people who enjoy jumping through those hoops every day after all.
The key is to give this in liu of a 6 hour panel of interviews. So your project should be 4hrs max. And don't add in vague time waster 'bonus points' for doing more details.
it could be done evenings or weekends. i'd make it async/flextime as much as possible. the main point is to try a real project, however small, and pay the person, therefore it's real and fair for both parties. from my observation over a few decades, all other methods are noise and circuses and mysticism and propaganda in comparison. at least, I'm so done letting myself be the victim of other people's theories and guesses and unpaid meta makework.
This doesn't take into consideration the time to bring someone up to speed and their productivity hit from that. There is also cost and slowdown from the company's perspective to bring someone new up to speed (it usually will slow down others involved too).
You should just be sure you need and want to hire someone before they show up for their first day.
The point is, if you want to get an actual job in the actual tech economy -- not the ideal tech economy from your head -- better bone up on your brain teasers. And have a Word-format CV.
This isn't the best way at all – you're going to end up with a candidate who wants/is able to agree to that, instead of a potentially much better candidate who won't.
Since I'd wager that the vast majority of skilled engineers would reject that offer outright, you end up really shrinking your pool of talent.
Even a week or month is short. I've been in situations where it's tough to make a hiring decision based on 10 weeks of (paid) interaction, even when saying "No" means having only 4-5 interviews to decide on a "Yes" for someone else.
This is why hiring people who we professionally interact with (referrals) is so important. And it's a handicap for people with weak networks or internal-only jobs.
How is it that a company could not be able to make a decision after 2+ months of a person actually working for them? If it's not a clear "no," we know that person hasn't managed to destroy the company and can at least get along well enough socially. If it's not a "yes" after that much time, that seems like a management failure. After all, 2 months should be more than enough time to produce enough code to tell whether a person can code and will bring a net positive influence to the environment.
If only competent candidates would agree to doing that. I've offered it to multiple candidates, and only those who were justifiably unemployed for months were interested (and, unsurprisingly, they didn't work out).
There are many more better methods but eventually if a method is better it also means it is expensive. Hiring a paid intern would involve lot of legal crap + lot of time wasted on a person. Also number of interns we can have is super limited and we will need some sort of interview to select interns in first place.
Asking tough questions in interview is not particularly bad because tough questions generally work welll. This strategy has worked well for Google, Microsoft, Apple and Amazon I dont see why it cant work for everyone else.
"This strategy has worked well for Google, Microsoft, Apple and Amazon I dont see why it cant work for everyone else."
The downside to the methods Google etc use is they have a huge number of false negatives. They reject tons of great engineers. This works out well when you constantly have thousands of great engineers applying to work for your company.
It does not work well at all if you are a normal company.
Exactly. This is one of the largest failures of the tech industry when it comes to interviews. They see the current tech behemoth and extrapolate their hiring practices, but the reality is that those companies are fitting their models to a different set of data than 99.9% of the other companies in the world.
When you're a household name and most engineers view your company as a top place to go and you're getting thousands of resumes a day, you have the ability to filter differently than most folks.
Has it? Besides the number of great people they turn down, the great people that refuse to interview at all with them (I don't know anyone willing to waste their time with a process clearly designed to be biased towards their failure), how much deadwood are in those companies? A ton, by all available reports.
There is a difference between what I call 'clever' and 'smart'. There are plenty of people that are fast on their feet at thinking about algorithmic-y type things. That doesn't translate into an ability to think through engineering problems, drive a project forward, cut through red tape, motivate peers, mentor the less experienced, identify market opportunities, behave ethically, build great teams .. I can go on. There is so much to this job other than manipulating binary trees, and swiftness at doing that at a white board is not a particularly good indicator of being able to think hard about novel problems. My best math professor, ever, had to ask the class to do the arithmetic and often we'd have to correct his algebra steps. He was fantastic, he just wasn't great at doing that stuff on his feet in front in front of an audience.
And, of course, not many jobs require novel algorithms; most require all other stuff. I'd give my eye teeth for an engineer that can just plod through and keep a project on schedule and budget. Don't see how the 'tough questions' identify her.
This is too strong a statement. It's an imperfect heuristic, and it's painful for all involved (which makes negative reactions to it be over-represented in online discussions), but it's better than shuffling the deck of resumes and randomly choosing one. You ask candidates what they know about tech, and it quickly becomes obvious who's in the know and who's able to think outside the box, and who isn't. It's more of a crap shoot in terms of gauging work ethic and personality. Week-long trials are simply not feasible for most companies (or candidates, for that matter).
Sites down; but, I wanted to add that at the peak of Hadoop hype, an unnamed company asked how I'd tally up occurrences of a value in a 1gb flat file, where the job would need to be done recurringly on multiple files, quickly. Without wanting to overthink it, I suggested a simple script iterating over the file, incrementing the key/values as they occur.
Apparently the correct answer was a Hadoop job.
Now, given that my experience with Hadoop was limited at the time, and even now only includes use of small clusters, that was surprising. It's sooooooo slow in comparison, and for single 1gb files, it still doesn't quite seem the best tool for the task to me.
Questions/Answers will sometimes be biased based on what the interviewer prefers.
iterating over the file, incrementing the key/values as they occur
Isn't that exactly what the Hadoop job would have to do anyway? The whole point of Hadoop is to process the data in a single pass, which is what your method does. As long as you iterate over the file without reading the whole thing into memory first.
Yeah, if you described an actual fucking program, and their answer was the name of a software package that you could learn in a day and they've been trying to hire an expert in for six months, and you would still just use that software package to run your program, be glad you didn't get the job. ;)
In the general case: if you go to a job interview, and the answer they're looking for on every question is just a buzzword, you don't want to work there.
I didn't see much that qualifies as a "Brain Teaser" - most of these are algorithmic questions. Knowing when do implement a depth first search != brain teaser.
Actually a crapload of efficient algorithms are applications of "clever" tricks. They're not necessarily intuitive, and the people that can recite them in interviews have very often already seen the solution (or the same general pattern applied to a similar problem). In that sense, they are very much like brain teasers.
If every programmer should be able to construct complex algorithms from first principles in a 10 minute window under the pressure of an interview, we wouldn't have so many algorithms named after the people who discovered them.
I don't follow your argument. Candidates for a lot of software engineering roles are expected to know a certain selection of fundamental algorithms, including things like DFS and Dijkstra's. The companies I have interviewed at have been very clear about what is expected knowledge. I don't see how this is at all relevant to being able to construct it from first principles. That's the whole reason you're expected to know it!
If you're talking about "tricks" like the tortoise and the hare solution to detecting if a graph has a cycle, then sure, I can get behind that. However, there is a base of algorithmic knowledge that you are expected to know, and it is entirely irrelevant whether or not you can construct it from scratch.
Ok but the question is why are some of these questions even considered the 'base' level of knowledge for interviews? At least on the front end side we still ask about these algorithms even though binary search trees and Djikstra's have almost no application in our work.
The reason for these questions being considered 'fundamental' seems totally contrived, and that's that everyone studied them in their CS program, not necessarily because that's the kind of knowledge you apply day to day.
Graph traversal is quite relevant to DOM manipulation. More generally, these sorts of "classical" problems come up more than one would assume at first glance.
I believe that understanding the theoretical backing is very important for making correct software design choices, at least at the positions I have held. Moreover, this base knowledge is a proxy for general awareness of complexity analysis and architectural trade-offs (why do we pick this structure over that?). I agree that we needn't consider single-source shortest paths every day when programming, but for companies that want to be sure they are making good hiring choices, this seems reasonable to me. Graphs, for example, come up so often in practice, which is why I refer to them as fundamental. It's not like we're talking about red-black trees here. Again, it's a proxy for one part of what makes a great programmer.
Well, "a lot of software engineering roles" have requirements and knowledge expectations that are far out of line with what the job actually requires. There are some "fundamental algorithms, including things like DFS and Dijkstra's" that simply aren't applicable to a lot of software engineering roles, big and small.
Most of the questions and interview ceremony around these things, especially for the aforementioned positions for which they're largely irrelevant, are exercises in hazing, ego building/busting (depending on which side of the interview you're on), and petty power plays.
The site sure starts out on 'dark pattern' footing. To sign up, you can link your LinkedIn, G+ (who has that?), github, or Facebook accounts (seemingly, not twitter), but once you do that, they claim there may be a username or email address conflict (even though you haven't provided an email address) so they want your email address as well.
They could just say, "Hey, we want your email address." Not "Gee, we don't know who you really are even though you linked your unique account to us; so we want you to provide your email address".
Not a good way to start our our relationship leetcode.
I just signed up via G+ (I may be mistaken, but can't everyone with a Gmail account signin using g+ ?) Did not get any message about email address conflicts
Edit: Just tried signing up with Facebook (which has one of my other email addresses on file), still no message about email address conflicts, signed up and logged me with no issue.
Tried signing up for another account with GitHub and did get a message about email or username conflict this time, but I was using the same email address on G+ as Github so it was a legitimate conflict.
Sadly, each time I want to change job, I have to go through those questions again. No any company (or interviewer) would admit that they decide whether or not to extend an offer to you solely based on how well you solve those programming puzzles. But reality is, your "performance" during the interview session is oftentimes more important than your experience (e.g., your side projects. Even you can demo your projects in front of interviewers, they just don't care -- because they themselves joined the company in the same way -- solving programming puzzles)
I blame it on primate science. Some scientists got some chimps, did some tests, and figured running tests and puzzles on the chimps to gauge their performance must map to humans as well due to a loosely correlated metric, such as genetic distance.
btw, this website is well-known among Chinese and Indian.
It's really really very hard to encounter an interview question that is not on this list nowadays, if you are interviewing with big name companies like linkedin, google, facebook ... It's more like preparing for final exam in college.
I'm not convinced that questions like these work effectively at all. They might give you some insight into a developer's ability to research and implement some specific algorithms (because you're not making them do it on a whiteboard, are you?) but there's a lot more to being an effective engineer than that.
We've had success with a two-hour pairing exercise, in which the goal is "build a miniature version of one of the core parts of our product" with one of our engineers. That's followed by explaining the goals, technology, general approach etc. to another engineer, then a discussion about what would happen next, some of the specific domain problems, that sort of thing. There's no expectation that the project is completed in the time available, and it's more about understanding the process.
This has been pretty effective, and is great for getting a more rounded understanding of the skills of a particular engineer. In my experience, rather softer skills like the ability to clearly articulate the problem, to understand the broader impact on a bigger system, and to be able to identify future issues and challenges are more important than the ability to solve specific technical challenges. Lackluster technical ability is usually pretty immediately obvious when pairing with a developer, in any case.
It's not very effective, but I don't think it's that bad.
In the end as a developer your job is to solve problems, and getting hired is simply another problem (solving which has self-evident benefits, so you shouldn't lack motivation).
It's not like the hiring process for technical jobs is shrouded in mystery: there are tons of resources on the internet about it.
You know what kind of questions will be asked, you know how you are expected to answer, the rest is just study and practice: a successful interview should be at least proof for the employer that you are able to grasp that process and carry out the work necessary to see it through.
I think the point of some of these tests is to quickly distinguish from people who can and can't code solutions for simple problem. The latter has obviously lied in their application and can be dismissed right away, creating time for other interviews.
We're starting to do something similar, although without the pairing (we don't do pairing) but with some engineers in the room playing the role of coworkers who are available to discuss the problem, bounce ideas off of, etc.
The issue that immediately came up is that within the 2 hour time frame it's just not going to be possible to have a truly realistic block of code from our daily work, there's just way too much domain specific knowledge that one would need to bone up on. So then what happened is that we're back to looking at problems that are in the mold of a whiteboard problem but a bit more complex and with a higher expectation in terms of what their output is.
I think this sort of thing works better when a company in the webdev space where companies are using well known frameworks (e.g. RoR) that candidates are going to know how to spin up a reasonable application complete with DB, etc without much effort.
What lovely questions! I didn't see anything regarding "remove all dead code from this method" or "find out why the mail server isn't working" or "ask a client specific questions about an upcoming project to judge the time needed" - which all happen to be real-life problems, not fucking brainteasers that have exactly 0 practical use outside the interview process.
They have no practical use during the interview process either, come to think of it...
If someone would ask me any of these questions during an interview I would just leave. They want people who like quizzes, not solving computing problems.
The hard questions in that list seem much easier than the Google foobar challenge questions. Though of course you have days to solve those, rather than having to solve them during a (presumably short) interview.
I like to give slightly more difficult versions of these questions as take-home problems, rather than interview problems. Give them out after phone screen, but before in-person interview.
And yes, something involving a binary tree order traversal would be the kind of thing that I'd be interested in. Because I want to work with programmers who can code, who at the very least know what recursion is and are able to employ it in the solution to a problem.
Concrete example: the startup I'm at has an expression editor. Expressions are tree structured. Typing an expression tree involves a post-order traversal. If there's an error in the validation, I need the programmer who's working on it to not be phased by these simple concepts. This typing currently happens in an async background task in Java, but it could give a better experience to the end user if it occurred in JS on the client's machine. This stuff just got really relevant after coffee.
But more importantly, I want to see what kind of code - how convoluted or not, how elegant or not, etc. - the person writes. I want to know what kind of code I'm going to see in pull requests, and how much of a PITA it's going to be to get them up to scratch.
Standard engineering stuff like unit tests can be taught. Writing tight, readable and elegant code is much more difficult.
For me it would be much more valuable if the programmer knew that a tree wouldn't be needed at all if expressions were represented in reverse Polish notation.
However, in the last 30 years, I needed to process expressions at work and by myself exactly zero times.
Humans have to read these expressions and understand them for auditing purposes. RPN might be suitable to CS and mathematics geeks, but not everyone in banking has that background.
Thanks for your reply. I understand that the programmers you are looking for are not typical programmers.
What I wanted to point out is that I was frequently impressed in my career by people capable of solving these problems easily and thought of myself a bad or less doable programmer.
While in reality there are a lot of different programmers out there and they will fit differently given the job they need to do.
Sometimes it will be a requirement to know all theses problems well, sometimes even if you know them well you will lack the needed experience to do the actual job.
I am a JavaScript (now you understand right? :D) developer working on frontend/backend websites and I can tell you most of the people I have worked with do not care about me knowing easily how to deal with a "binary tree order traversal"
From the description: "Pick from an expanding library of more than 150 questions, code and submit your solution to see if you have solved it correctly" the Project Euler site tops that number with a similar proposition. Project Euler has almost 500 problems at https://projecteuler.net/.
OK, perhaps it is more targeted to the mathematically inclined, instead towards engineers on their route to a technical coding interview. Nevertheless it has a very interesting set of (challenging) problems, and I see a number of similar problems at LeetCode.
Project Euler is also a great environment for trying out new programming languages, as the code is not part of the submission. As long as you come up with the correct answer (which is always a number), Project Euler considers it solved. You might solve the problem with C, Python, ACL, Ruby, pen-and-paper, Ada, Mathematica, Wikipedia... Euler doesn't care. So, sometimes I solve some problems multiple times, just to try different concepts or algorithms in other languages.
(By the way, the title "Software engineering interview questions" is a little broad. It is a set of (mainly mathematical) problems that may be solved by writing some code, but it doesn't address other relevant software engineering experience/aspects.)
The original one was like "Most engineering interview questions of hot companies". My point was, very few companies are innovative for recruiting. Interview questions can be practiced, which only test a small subset of skills for software engineer position.
Well, I can see the reasons for a title change then; the page does not really explain the claim in the original title. It is an interesting collection of problems applicable for a coding interview -- which is not the same as "most interview questions" -- and it doesn't mention the companies (hot or not) that asked them. Nevertheless, it's a good find and a relevant submission to HN.
OK, the administrator could have been a little more precise then. Unfortunately the LeetCode page also does not contain a clear title for the page, which make the administrator's job harder. Changing the title on HN is probably done after a quick one-time impression at the site.
(I don't think that we can see the original title as posted to HN?)
Oh, forgot to add that after a hack in June and a period of limited functionality, Project Euler seems to be fully operational again since end of September. New progress can be registered again, and solution history has been restored (if you remembered your account). Happy for them, and for the community.
If you want to see how they code, why do you want to see their own algorithm? In normal conditions, They would Google the problem and find its algorithm on Wikipedia (with lots of additional information to peruse) and some interesting implementations on stackoverflow (both to choose from and to learn about related issues).
Programming in the wild has very little to do with knowing beforehand or being able to invent on the spot an algorithm.
But the real reason why software engineering interviews are being done that way is because programming is not perceived as an art anymore. Engineers' scope inside the company was greatly reduced, while their number increased. They are now commodity workers: Not only they must be replaceable, but also expanded and shrunk as soon as possible, much faster and cheaper than before.
These days I dont even bother with such interviews. I talk directly with people in power and skip all this bullshit. All positions like VP, director, manager roles have way more real influence compared to an engineer. None of thrse positions require you to answer these questiins and yet give more pay and influenve on the final product. Unlike an engineer who has to work from the bottom to drive change. Unless you are a colleve noob i would really ask you to reconsider your job position if these are the questiins you are answering. Talking of 90% of the software companies here. I do know real engineers do tremendous stuff.
97 comments
[ 3.0 ms ] story [ 175 ms ] threadCS and math researchers write papers (partially) so that engineers can pick them up and use them to improve on what's possible to build.
Along those lines, most people feel that their programming jobs don't fall into that category.
I'm currently obsessed with learning Haskell, so I'm tempted to attack all these problems with it.
Asking questions in an interview, no matter how clever or insightful they may be, has been and will forever be a crap shoot.
Sure, it'd be nice if you could hire all your great employees this way, but forgetting for a moment whether it's fair, it's not realistic.
I do sympathize with the big damage done by poor hires & problems getting rid of them - I have seen similar as well. However, a process like this will select against a lot of quality developers and not necessarily select for the ones you want to work with. It just selects for the developers that that company wants to work with who are willing to jump through such an extra set of hoops. It also tells me as a candidate that the people who are working there don't have the courage to speak out against such a process selecting against candidates not willing or able to go through the process or the leadership is too weak to figure out that this sets up a bias that isn't intended to be selected for, thus being a bad hiring mechanism.
A trial process like this would select against lots of quality developers, true, but that isn't the real question. Instead, I want to know whether the developers who wind up being hired represent a more talented subset. I can't prove that it would, but I feel that this system would be more accurate in letting the right people through.
All that said, I like some of the gray area solutions proposed in this HN thread, including after-hours or weekend remote work on a project already in production. Not a perfect solution, given the inability to evaluate things like culture fit, but it combines many upsides of the alternatives.
Is the knowledge of splines a major predictor of a graphics programmer's success? I don't understand why it appears to be a point of denigration here. The details of your story are foreign to me, of course, so maybe I'm missing context. But it's always helpful to remember that time is finite when compared to the seemingly infinite amount of things to learn. No one comes to work and says, "I want to suck today!"
And yet companies will still let good engineers walk out the door because a competitor is willing to pay them 20% more.
Everyone always talks about how "amazingly difficult" it is to get under-performing people to leave, but really, why is that so? I find that simply saying
"You know, we don't think this arrangement is working out for either of us. Can you please do us a huge favor, and resign? BTW if you agree, here's $X, a perfectly respectable severance package that acknowledges that you are human being, and that this was just as much our mistake as yours."
pretty much always works (provided the company is willing to swallow $X, which if they have any integrity they should have no problem doing). You don't have to say the "this was our mistake part" of course, but that's what the $X is for, because it says it implicitly (and in a more substantial way than mere words ever could).
Of course, there's also the task of getting other people to see that someone is under-performing, which can be quite difficult sometimes -- but that's a separate issue (and if it really is especially difficult to have these kinds of conversations with persons of authority in your group, then maybe you should be moving on, as well).
Sadly, many of the best engineers I've worked with do have families, are working, don't live in the same town, and would absolutely balk at the idea of taking a week away from all that to "try out" a new job.
Of course, there's a wide spectrum between "work together for a week" and "write some C++ on a whiteboard for 40 minutes" that gets dropped from most screening processes. That's the zone where I'm most interested in finding creative evaluation tools.
Provide the right work environment and perks, and people will "jump through hoops" if they think its worth it.
At the end of the day, what job/pay/perks do you want?
If jobs require you to jump through some hoops, then they will be jumped through - within reason.
You should just be sure you need and want to hire someone before they show up for their first day.
fuckin' word format resume. That is no longer a thing.
Since I'd wager that the vast majority of skilled engineers would reject that offer outright, you end up really shrinking your pool of talent.
This is why hiring people who we professionally interact with (referrals) is so important. And it's a handicap for people with weak networks or internal-only jobs.
Asking tough questions in interview is not particularly bad because tough questions generally work welll. This strategy has worked well for Google, Microsoft, Apple and Amazon I dont see why it cant work for everyone else.
The downside to the methods Google etc use is they have a huge number of false negatives. They reject tons of great engineers. This works out well when you constantly have thousands of great engineers applying to work for your company.
It does not work well at all if you are a normal company.
When you're a household name and most engineers view your company as a top place to go and you're getting thousands of resumes a day, you have the ability to filter differently than most folks.
There is a difference between what I call 'clever' and 'smart'. There are plenty of people that are fast on their feet at thinking about algorithmic-y type things. That doesn't translate into an ability to think through engineering problems, drive a project forward, cut through red tape, motivate peers, mentor the less experienced, identify market opportunities, behave ethically, build great teams .. I can go on. There is so much to this job other than manipulating binary trees, and swiftness at doing that at a white board is not a particularly good indicator of being able to think hard about novel problems. My best math professor, ever, had to ask the class to do the arithmetic and often we'd have to correct his algebra steps. He was fantastic, he just wasn't great at doing that stuff on his feet in front in front of an audience.
And, of course, not many jobs require novel algorithms; most require all other stuff. I'd give my eye teeth for an engineer that can just plod through and keep a project on schedule and budget. Don't see how the 'tough questions' identify her.
This is too strong a statement. It's an imperfect heuristic, and it's painful for all involved (which makes negative reactions to it be over-represented in online discussions), but it's better than shuffling the deck of resumes and randomly choosing one. You ask candidates what they know about tech, and it quickly becomes obvious who's in the know and who's able to think outside the box, and who isn't. It's more of a crap shoot in terms of gauging work ethic and personality. Week-long trials are simply not feasible for most companies (or candidates, for that matter).
Apparently the correct answer was a Hadoop job.
Now, given that my experience with Hadoop was limited at the time, and even now only includes use of small clusters, that was surprising. It's sooooooo slow in comparison, and for single 1gb files, it still doesn't quite seem the best tool for the task to me.
Questions/Answers will sometimes be biased based on what the interviewer prefers.
Isn't that exactly what the Hadoop job would have to do anyway? The whole point of Hadoop is to process the data in a single pass, which is what your method does. As long as you iterate over the file without reading the whole thing into memory first.
http://techcrunch.com/2013/06/22/the-technical-interview-is-...
If every programmer should be able to construct complex algorithms from first principles in a 10 minute window under the pressure of an interview, we wouldn't have so many algorithms named after the people who discovered them.
If you're talking about "tricks" like the tortoise and the hare solution to detecting if a graph has a cycle, then sure, I can get behind that. However, there is a base of algorithmic knowledge that you are expected to know, and it is entirely irrelevant whether or not you can construct it from scratch.
The reason for these questions being considered 'fundamental' seems totally contrived, and that's that everyone studied them in their CS program, not necessarily because that's the kind of knowledge you apply day to day.
I believe that understanding the theoretical backing is very important for making correct software design choices, at least at the positions I have held. Moreover, this base knowledge is a proxy for general awareness of complexity analysis and architectural trade-offs (why do we pick this structure over that?). I agree that we needn't consider single-source shortest paths every day when programming, but for companies that want to be sure they are making good hiring choices, this seems reasonable to me. Graphs, for example, come up so often in practice, which is why I refer to them as fundamental. It's not like we're talking about red-black trees here. Again, it's a proxy for one part of what makes a great programmer.
Most of the questions and interview ceremony around these things, especially for the aforementioned positions for which they're largely irrelevant, are exercises in hazing, ego building/busting (depending on which side of the interview you're on), and petty power plays.
The proof is in the pudding:
https://twitter.com/gortok/status/547468794160238592
They could just say, "Hey, we want your email address." Not "Gee, we don't know who you really are even though you linked your unique account to us; so we want you to provide your email address".
Not a good way to start our our relationship leetcode.
Edit: Just tried signing up with Facebook (which has one of my other email addresses on file), still no message about email address conflicts, signed up and logged me with no issue.
Tried signing up for another account with GitHub and did get a message about email or username conflict this time, but I was using the same email address on G+ as Github so it was a legitimate conflict.
It's really really very hard to encounter an interview question that is not on this list nowadays, if you are interviewing with big name companies like linkedin, google, facebook ... It's more like preparing for final exam in college.
We've had success with a two-hour pairing exercise, in which the goal is "build a miniature version of one of the core parts of our product" with one of our engineers. That's followed by explaining the goals, technology, general approach etc. to another engineer, then a discussion about what would happen next, some of the specific domain problems, that sort of thing. There's no expectation that the project is completed in the time available, and it's more about understanding the process.
This has been pretty effective, and is great for getting a more rounded understanding of the skills of a particular engineer. In my experience, rather softer skills like the ability to clearly articulate the problem, to understand the broader impact on a bigger system, and to be able to identify future issues and challenges are more important than the ability to solve specific technical challenges. Lackluster technical ability is usually pretty immediately obvious when pairing with a developer, in any case.
In the end as a developer your job is to solve problems, and getting hired is simply another problem (solving which has self-evident benefits, so you shouldn't lack motivation).
It's not like the hiring process for technical jobs is shrouded in mystery: there are tons of resources on the internet about it.
You know what kind of questions will be asked, you know how you are expected to answer, the rest is just study and practice: a successful interview should be at least proof for the employer that you are able to grasp that process and carry out the work necessary to see it through.
The issue that immediately came up is that within the 2 hour time frame it's just not going to be possible to have a truly realistic block of code from our daily work, there's just way too much domain specific knowledge that one would need to bone up on. So then what happened is that we're back to looking at problems that are in the mold of a whiteboard problem but a bit more complex and with a higher expectation in terms of what their output is.
I think this sort of thing works better when a company in the webdev space where companies are using well known frameworks (e.g. RoR) that candidates are going to know how to spin up a reasonable application complete with DB, etc without much effort.
They have no practical use during the interview process either, come to think of it...
If someone would ask me any of these questions during an interview I would just leave. They want people who like quizzes, not solving computing problems.
Interviewing for a frontend Facebook job is all about doing an Array.map/reduce no more.
What matters is what you can do.
Few engineers really need to learn and master "Binary Tree Level Order Traversal" every day after coffee.
And yes, something involving a binary tree order traversal would be the kind of thing that I'd be interested in. Because I want to work with programmers who can code, who at the very least know what recursion is and are able to employ it in the solution to a problem.
Concrete example: the startup I'm at has an expression editor. Expressions are tree structured. Typing an expression tree involves a post-order traversal. If there's an error in the validation, I need the programmer who's working on it to not be phased by these simple concepts. This typing currently happens in an async background task in Java, but it could give a better experience to the end user if it occurred in JS on the client's machine. This stuff just got really relevant after coffee.
But more importantly, I want to see what kind of code - how convoluted or not, how elegant or not, etc. - the person writes. I want to know what kind of code I'm going to see in pull requests, and how much of a PITA it's going to be to get them up to scratch.
Standard engineering stuff like unit tests can be taught. Writing tight, readable and elegant code is much more difficult.
However, in the last 30 years, I needed to process expressions at work and by myself exactly zero times.
What I wanted to point out is that I was frequently impressed in my career by people capable of solving these problems easily and thought of myself a bad or less doable programmer.
While in reality there are a lot of different programmers out there and they will fit differently given the job they need to do.
Sometimes it will be a requirement to know all theses problems well, sometimes even if you know them well you will lack the needed experience to do the actual job.
I am a JavaScript (now you understand right? :D) developer working on frontend/backend websites and I can tell you most of the people I have worked with do not care about me knowing easily how to deal with a "binary tree order traversal"
OK, perhaps it is more targeted to the mathematically inclined, instead towards engineers on their route to a technical coding interview. Nevertheless it has a very interesting set of (challenging) problems, and I see a number of similar problems at LeetCode.
Project Euler is also a great environment for trying out new programming languages, as the code is not part of the submission. As long as you come up with the correct answer (which is always a number), Project Euler considers it solved. You might solve the problem with C, Python, ACL, Ruby, pen-and-paper, Ada, Mathematica, Wikipedia... Euler doesn't care. So, sometimes I solve some problems multiple times, just to try different concepts or algorithms in other languages.
(By the way, the title "Software engineering interview questions" is a little broad. It is a set of (mainly mathematical) problems that may be solved by writing some code, but it doesn't address other relevant software engineering experience/aspects.)
(I don't think that we can see the original title as posted to HN?)
Programming in the wild has very little to do with knowing beforehand or being able to invent on the spot an algorithm.
But the real reason why software engineering interviews are being done that way is because programming is not perceived as an art anymore. Engineers' scope inside the company was greatly reduced, while their number increased. They are now commodity workers: Not only they must be replaceable, but also expanded and shrunk as soon as possible, much faster and cheaper than before.