8 ms·
Software engineering interview questions
- eeeemmm 12y agoI never asked any of these question, a good engineer is not a mathematician.
- PublicEnemy111 12y agoReciting 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
- AYBABTME 12y agoA 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.
- csallen 12y agoThe 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.
- jghn 12y agoThe 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.
- wehadfun 12y agoi guess you have to buy a book to use the website. Interesting monetization policy
- atrilumen 12y agoI would love it if it supported more languages. I'm currently obsessed with learning Haskell, so I'm tempted to attack all these problems with it.
- jschulenklopper 12y agoTry Project Euler, https://projecteuler.net/ 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.
- BigChiefSmokem 12y agoBest 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.
- daniel-cussen 12y agoIt'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.
- IndianAstronaut 12y agoI 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.
- ionforce 12y agoWhat if both the hiring company and the applicant have lives on the weekend?
- soperj 12y agoHonestly, as someone who would have to quit their current job to go work for another company, why on earth would I agree to that instability?
- 12y ago
- MoOmer 12y agoSites 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.
- IndianAstronaut 12y agoI used to use Python/Pandas for up to 9gb files.
- kyllo 12y agoiterating 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.
- justizin 12y agoYeah, 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. ;)
- fragmede 12y agoI'm surprised at this list of questions. Didn't everyone get the memo that "brainteasers are a complete waste of time?" from a year and a half ago? http://techcrunch.com/2013/06/22/the-technical-interview-is-dead/ http://techcrunch.com/2013/06/22/the-technical-interview-is-...
- pixeloution 12y agoI 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.
- peeters 12y agoActually 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.
- MaxScheiber 12y agoI 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.
- 12y ago
- doing_engine 12y agoA good engineer is adaptive enough to grok and keep the business goals a priority. Developing systems is just an implementation detail.
- gortok 12y agoThe 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. The proof is in the pudding: https://twitter.com/gortok/status/547468794160238592 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.
- cheapsteak 12y agoI 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.
- sfbushstreet 12y agoSadly, 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)
- disjointrevelry 12y agoI 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.
- sfbushstreet 12y agobtw, 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.
- lightblade 12y agoTrue, but I didn't expect someone post it on Hacker News. It's supposed to be a secret weapon. Not so secret anymore.
- matthewmacleod 12y agoI'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.
- sfbushstreet 12y agoThis is how companies like google, facebook, and linkedin interview candidates. It's not effective, but it's the common practice
- Kurtz79 12y agoIt'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.
- 12y ago
- icecreampain 12y agoWhat 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.
- wbhart 12y agoThe 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.
- vvoyer 12y agoI am not able to answer any of these easily and still get a lot of job done and job offers every day/two days. 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.
- barrkel 12y agoI 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.
- aercolino 12y agoFor 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.
- barrkel 12y agoHumans 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.
- jschulenklopper 12y agoFrom 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/ 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.)
- sfbushstreet 12y agoThe original title was not "Software engineering interview questions" ... Administrator of hacker news changed it ...
- sfbushstreet 12y agoThe 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.
- jschulenklopper 12y agoWell, 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.
- aercolino 12y agoIf 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.
- general_failure 12y agoThese 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.