Software engineering interview questions
oj.leetcode.com
oj.leetcode.com
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.
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.
Asking questions in an interview, no matter how clever or insightful they may be, has been and will forever be a crap shoot.
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.
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!"
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).
And yet companies will still let good engineers walk out the door because a competitor is willing to pay them 20% more.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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?)
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.
Along those lines, most people feel that their programming jobs don't fall into that category.
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.
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.
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.
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"
However, in the last 30 years, I needed to process expressions at work and by myself exactly zero times.
I'm currently obsessed with learning Haskell, so I'm tempted to attack all these problems with it.