Facebook Engineering Puzzles(facebook.com)
facebook.com
Facebook Engineering Puzzles
http://www.facebook.com/careers/puzzles.php
13 comments
The Facebook puzzles are pretty easy. That being said, I hate puzzles too. I think it's pretty degrading to ask a well-established researcher/engineer to do that kind of stuff. On interviews I typically ask people to give a talk about their previous projects in detail. A lot of nuances arise during these talks that allow you to quite easily judge the level of the candidate.
Why is it degrading? I would think it would be perfectly acceptable for companies to ensure that their new hires (experienced or not) pass their basic heuristics. This comes in the form of tests, resume checks, social compatibility, etc.
(I ask this from the perspective of a young, inexperienced developer.. so excuse the thoughtlessness!)
(I ask this from the perspective of a young, inexperienced developer.. so excuse the thoughtlessness!)
I don't know... I would personally feel a bit weird asking, for example, an experienced compiler developer with a CS PhD to reverse a linked list, or words in a string, or something like that.
So get them to solve something more difficult than reversing a linked list. A good programmer will enjoy a good puzzle, especially if it is new to them.
I think the attitude of a lot of companies, especially the ones hiring fresh grads, is that the ability to think is more important than the ability to code (the latter of which can be taught far more easily than the former).
I don't mean to imply that you are unable to think, of course - the puzzles are surely an imperfect heuristic - but that's my understanding of their aim.
I don't mean to imply that you are unable to think, of course - the puzzles are surely an imperfect heuristic - but that's my understanding of their aim.
How are these puzzles hypothetical? They look better written in specification than specs in the real world:
If the questions were more like "How would you move Mt. Fuji", then that's certainly hypothetical.
(selected few and summarized...)
Hoppity Hop!
Input: filename as arg from command prompt, file contains a number
Output: Some variation on the word "Hoppity" repeated
Simon Says
the gist: Connect to some server, call some api's in a certain order.
Battleship - write a client that connects to some server that plays battleship...
Find Sophie - read some data,build some data structures/run algorithm,output result
Input: filename and specifications of the file format
Output: result
If the questions were more like "How would you move Mt. Fuji", then that's certainly hypothetical.
Hoppity Hop is basically the Fogbugz for-loop question + no brainer file parsing
Why not give me a real world use case, with a code base to work off of? Put up a codebase on github, provide a set of user stories and requirements to satisfy (ie, "add a real time search using this data set and code base which works cross-browser and degrades in IE"), and ask me to add it, thus basically mirroring a normal development process.
As someone who has had to interview programmers before, that would tell me infinitely more than their ability to re-iterate the word "Hoppity" on the command line.
Why not give me a real world use case, with a code base to work off of? Put up a codebase on github, provide a set of user stories and requirements to satisfy (ie, "add a real time search using this data set and code base which works cross-browser and degrades in IE"), and ask me to add it, thus basically mirroring a normal development process.
As someone who has had to interview programmers before, that would tell me infinitely more than their ability to re-iterate the word "Hoppity" on the command line.
Because the people you want most aren't going to waste a ton of time jumping through hoops? The nice thing about puzzles is that they're self-contained and can be understood and solved in a few hours. When I was applying for a Facebook internship, I wound up spending ~6 hours over a couple of days finishing two of the puzzles. This already seemed like a significant time investment. A problem that involved "a real world use case, with a code base to work off of" would necessarily take a lot longer to understand and implement. I was pretty busy that month, and if the puzzle questions had been more time-consuming I might have skipped Facebook and applied to other companies instead. (As it happened I wound up at Google)
Puzzle-based interview questions are meant to be a rough cut to weed out the people who are clearly unqualified for the position. They're not meant as a substitute for more in-depth discussion of skills, work experience, etc. If the filter is too time-consuming, it's going to weed out some of the best people who are confident they'll get offers from other companies. And a large company like Facebook doesn't necessarily want to test specific skills because they may not have yet decided which position you'd be hired for, and in any event you're likely to work on multiple projects during your time with the company. For entry-level positions (which is presumably what these questions are designed for), it's better to hire the smartest guy you can find and train him on specific technologies than to hire a guy who already has a specific skillset and then discover he's a one-trick pony.
Puzzle-based interview questions are meant to be a rough cut to weed out the people who are clearly unqualified for the position. They're not meant as a substitute for more in-depth discussion of skills, work experience, etc. If the filter is too time-consuming, it's going to weed out some of the best people who are confident they'll get offers from other companies. And a large company like Facebook doesn't necessarily want to test specific skills because they may not have yet decided which position you'd be hired for, and in any event you're likely to work on multiple projects during your time with the company. For entry-level positions (which is presumably what these questions are designed for), it's better to hire the smartest guy you can find and train him on specific technologies than to hire a guy who already has a specific skillset and then discover he's a one-trick pony.
That's confusing to me, 6 hours is more than enough time to implement a small but significant feature. I think it's possible you're assuming the request would be a particularly large one.
"Why not give me a real world use case, with a code base to work off of?"
Because they want you to be good enough to do it without that.
(I'm saying this as an about to be new grad who is studying these subjects to not have that much help and have to do it on a whiteboard in an interview
and also working on these puzzles and similar ones from a lot of other companies)
Because they want you to be good enough to do it without that.
(I'm saying this as an about to be new grad who is studying these subjects to not have that much help and have to do it on a whiteboard in an interview
and also working on these puzzles and similar ones from a lot of other companies)
As someone with a lot of industry experience: It's great to know how people solve puzzles and tackle algorithms. It's even better to know how they can fit those solutions into a bigger picture, how they structure, comment and document their code, and how they interpret a use case and user stories.
Dealing with things in the abstract, stripping it of context, interface, interaction, and real world requirement, seems to be an incomplete way to understand the capabilities of the person you're potentially hiring.
Unless, of course, you're hiring for the position of Junior Abstract Puzzle Solver. In which case, by all means, Godspeed.
Dealing with things in the abstract, stripping it of context, interface, interaction, and real world requirement, seems to be an incomplete way to understand the capabilities of the person you're potentially hiring.
Unless, of course, you're hiring for the position of Junior Abstract Puzzle Solver. In which case, by all means, Godspeed.
Please don't ask me to review your "massive amounts of code" - I guarantee you will not come out ahead in that evaluation, if I even have time to properly evaluate it (according to Code Complete, you can properly review code in a high-level language at about 100-500 lines per hour).
If you consider the fact that:
- It is unlikely I am well-versed in the problem domain of your code,
- I am unlikely to be aware of external design constraints or coding pressures,
- I am probably going to randomly select the worst section of code to review,
- I have no context for how the code evolved
the chances that I walk away with a negative impression are high enough that it should give you pause. If I do manage to walk away with a positive impression of your code, it will be offset by the perception that you believe your time is more valuable than mine (why else would you send me a massive amount of code and ask me to review it to determine your suitability for a position) - and you still haven't answered the other big question I need answered which is whether you are a good "fit" for the team from a personality/cultural perspective.
If you really want to impress me, go ahead and send me a list of your projects and contributions and then slice a relevant sample of code from it. Describe what the problem was and how you solved it so I can understand the context. Try to make it relevant to the position, but failing that describe how you could utilize that experience in the relevant domain. Keep it small enough that I can review it in under an hour or two.
Is it a lot more work for you? Absolutely, but if you do this I guarantee you I will look at your code and will likely call you for an interview because you are demonstrating a high level of competence and professionalism while still respecting my time and needs.
If you consider the fact that:
- It is unlikely I am well-versed in the problem domain of your code,
- I am unlikely to be aware of external design constraints or coding pressures,
- I am probably going to randomly select the worst section of code to review,
- I have no context for how the code evolved
the chances that I walk away with a negative impression are high enough that it should give you pause. If I do manage to walk away with a positive impression of your code, it will be offset by the perception that you believe your time is more valuable than mine (why else would you send me a massive amount of code and ask me to review it to determine your suitability for a position) - and you still haven't answered the other big question I need answered which is whether you are a good "fit" for the team from a personality/cultural perspective.
If you really want to impress me, go ahead and send me a list of your projects and contributions and then slice a relevant sample of code from it. Describe what the problem was and how you solved it so I can understand the context. Try to make it relevant to the position, but failing that describe how you could utilize that experience in the relevant domain. Keep it small enough that I can review it in under an hour or two.
Is it a lot more work for you? Absolutely, but if you do this I guarantee you I will look at your code and will likely call you for an interview because you are demonstrating a high level of competence and professionalism while still respecting my time and needs.
You're assuming that I would "send you" massive amounts of code. I wouldn't. I'd have a link to my github on my resume, along with a description of the projects I've worked on.
It's presumptuous that I would be asking you to do a full code review (my Appleseed project is tens of thousands of lines of code, for instance), and that I wouldn't recognize the impracticality of such a request.
I would find it problematic, then, if you responded with tests and puzzles, without any interest or questions about my code. Or if the test and puzzles couldn't be skipped once I mentioned my experience level and accomplishments. This is often what interviewers have done, and I find it to be a good indicator of a workplace I'm not interested in working in.
The best workplaces let their developers take some time to comb through the best parts and the worst parts, and have a conversation about what I've done, my goals, how I did things, etc.
It's presumptuous that I would be asking you to do a full code review (my Appleseed project is tens of thousands of lines of code, for instance), and that I wouldn't recognize the impracticality of such a request.
I would find it problematic, then, if you responded with tests and puzzles, without any interest or questions about my code. Or if the test and puzzles couldn't be skipped once I mentioned my experience level and accomplishments. This is often what interviewers have done, and I find it to be a good indicator of a workplace I'm not interested in working in.
The best workplaces let their developers take some time to comb through the best parts and the worst parts, and have a conversation about what I've done, my goals, how I did things, etc.
Asking me to look at code on github is not that different from just sending me all the code (other than the fact that you aren't cluttering my inbox with it). What code do I look at? Why is it interesting to me? I understand your point about having a discussion about your code, but you are again asking me to find those interesting bits that are relevant to the position I want to fill. You are familiar with the code base already - it is not difficult for you in your cover letter to indicate that I might be interested in x,y,z in project foo because they demonstrate a,b,c, and I can find the code on github. Now I know what to look for, and I am very likely to go and look for it. That may lead me to explore some other things and will lead to an interesting interview. Even if I don't consider the code interesting and relevant, it still lets me ask about why YOU thought it was. If you don't point me to that, I may just flip through a couple of methods and never find anything that interests me enough to talk about it.
And for the record, I don't like "puzzles" either - even if I know the "trick" to the puzzle, sometimes my brain doesn't work right and I can't think of it after a long day of interviews. I would much prefer to be evaluated on how I work in a real environment, seeing my real code and my approach to real problems as opposed to impossible problems whose solution hinges on an obscure bit of semantic parsing in order to arrive at the solution. But as an interviewer, I don't have unlimited time to evaluate candidates so if you want me to do something, it helps to make it as easy as possible for me to do it.
In the end, I don't disagree with you, but I can understand interviewers that don't make the effort if you don't also make an effort.
And for the record, I don't like "puzzles" either - even if I know the "trick" to the puzzle, sometimes my brain doesn't work right and I can't think of it after a long day of interviews. I would much prefer to be evaluated on how I work in a real environment, seeing my real code and my approach to real problems as opposed to impossible problems whose solution hinges on an obscure bit of semantic parsing in order to arrive at the solution. But as an interviewer, I don't have unlimited time to evaluate candidates so if you want me to do something, it helps to make it as easy as possible for me to do it.
In the end, I don't disagree with you, but I can understand interviewers that don't make the effort if you don't also make an effort.
it is not difficult for you in your cover letter to indicate that I might be interested in x,y,z in project foo because they demonstrate a,b,c, and I can find the code on github.
I think it's fair to assume that after my years in the industry, that I would not simply hand you a link with no context, nor that I would be applying for a job which didn't relate to the work I had done, and I don't feel these arguments apply to the situation I presented.
But as far as I'm concerned, my preference would be to hire based on established code and real world tasks, not abstract puzzles. Not only are puzzles like these faddish, I've met too many programmers who excelled at puzzles, but were severely lacking in more mundane (but all too necessary) departments, so in terms of what kind of things I would use to weed people out, I'd do a set of real world tasks like the one I mentioned above, well before I'd ever give a list of clever puzzles to solve.
Assuming the applicant didn't contribute to open source, which would always be a huge plus in my book.
I think it's fair to assume that after my years in the industry, that I would not simply hand you a link with no context, nor that I would be applying for a job which didn't relate to the work I had done, and I don't feel these arguments apply to the situation I presented.
But as far as I'm concerned, my preference would be to hire based on established code and real world tasks, not abstract puzzles. Not only are puzzles like these faddish, I've met too many programmers who excelled at puzzles, but were severely lacking in more mundane (but all too necessary) departments, so in terms of what kind of things I would use to weed people out, I'd do a set of real world tasks like the one I mentioned above, well before I'd ever give a list of clever puzzles to solve.
Assuming the applicant didn't contribute to open source, which would always be a huge plus in my book.
The reality, for better or for worse, is that a lot of the companies that are using puzzles like this prefer false negatives over false positives. In other words, they would rather pass over the occasional excellent engineer than accidentally hire a mediocre engineer. This is the case at Google, Amazon et al, and likely at Facebook and others as well. It very well might be the case that you're just an unfortunate casualty of this sort of hiring practice.
I think you hit the nail on the head, but here's my issue: It's not so much companies like those that have a problem. I've been recruited by all the big guys on the strength of my open source work (save for Facebook, but that's probably due to a major conflict of interest, considering what I'm working on), but the real problem arises when you have smaller companies latching on to this approach, without the recruiting power of a Google or an Amazon. So now I get contacted by a small startup who all of a sudden wants me to take a quiz because they fancy themselves the next Google.
Most of the time anyone with solid engineering background, industry experience, programming contest medals, or entrepreneurial streak would have no problem landing an interview.
However, that leaves a whole lot of candidates out of the picture. Faced with limited recruiting resources, puzzles are about the next best thing to serve as a recruiting filter. Plus some people send them in without being told to, which is usually a plus, as it implicates coding in their spare time is something they enjoy doing.
However, that leaves a whole lot of candidates out of the picture. Faced with limited recruiting resources, puzzles are about the next best thing to serve as a recruiting filter. Plus some people send them in without being told to, which is usually a plus, as it implicates coding in their spare time is something they enjoy doing.
These FB puzzles test your algorithmical capabilities; and being able to develop new algorithms is not always necessary (though always useful) for a programmer. So you can have lots of programming experience and still not be too good at algorithms.
But it is important for Facebook - so that's what they test.
But it is important for Facebook - so that's what they test.
Well, its certainly more fair than giving puzzle/coding questions during an interview. This way you are under no pressure and can work on your own machine in your own time.
Facebook seems to be following the same trajectory that Google did. I remember ~10 years ago Google used to put out such puzzles; if you solved them, your chances of getting hired at El Goog went up significantly.
In another, say, 5 years, expect to hear about Facebook giving out massive retention bonuses to top engineers who are defecting en masse to a hot new startup... :-D
In another, say, 5 years, expect to hear about Facebook giving out massive retention bonuses to top engineers who are defecting en masse to a hot new startup... :-D
Its the circle of (extraordinarily successful startup) life.
Here is why the puzzles can be very effective, especially for a company in no hurry to hire:
1) The people who submit them are most likely interested in your company, took the time to solve the problem, and have a mind that works well. That already saves a lot of time screening people you wouldn't want for those top positions.
2) It attracts other smart people because you wouldn't refer puzzles to stupid people -- notice how we posted it on Hacker News. On a similar note, if you google for Node.js like I did, you'll find a sponsored result from Meebo offering you to apply to their "secret jobs!" -- because not just anyone searches for Node.js, but rather people who are interested in the new technology, which they are probably using or looking into.
3) Psychology -- people feel like they want something they worked towards. They committed time to facebook, so they will take it more seriously, and when someone from facebook talks to them, and asks them about their background AFTER solving the puzzle, they will feel a sense of accomplishment and engage back.
4) Notice how many of these puzzles have specified the exact outputs. They can screen the initial applicants with an automated test suite to see how well they did. Cheapest first round candidate evaluation ever :)
5) The puzzles are hopefully related to the kinds of architectural and social challenges they actually have to solve at facebook, so this prepares the candidate for that kind of thinking. If the candidate doesn't like thinking in this way, perhaps it's better to find out as early as possible, and before even SPEAKING to the candidate is pretty early!
If anything I would definitely set this kind of thing up for the top (architectural, etc.) development positions at facebook. They were recently named the best place to work at in 2010, so they can afford to do this.
1) The people who submit them are most likely interested in your company, took the time to solve the problem, and have a mind that works well. That already saves a lot of time screening people you wouldn't want for those top positions.
2) It attracts other smart people because you wouldn't refer puzzles to stupid people -- notice how we posted it on Hacker News. On a similar note, if you google for Node.js like I did, you'll find a sponsored result from Meebo offering you to apply to their "secret jobs!" -- because not just anyone searches for Node.js, but rather people who are interested in the new technology, which they are probably using or looking into.
3) Psychology -- people feel like they want something they worked towards. They committed time to facebook, so they will take it more seriously, and when someone from facebook talks to them, and asks them about their background AFTER solving the puzzle, they will feel a sense of accomplishment and engage back.
4) Notice how many of these puzzles have specified the exact outputs. They can screen the initial applicants with an automated test suite to see how well they did. Cheapest first round candidate evaluation ever :)
5) The puzzles are hopefully related to the kinds of architectural and social challenges they actually have to solve at facebook, so this prepares the candidate for that kind of thinking. If the candidate doesn't like thinking in this way, perhaps it's better to find out as early as possible, and before even SPEAKING to the candidate is pretty early!
If anything I would definitely set this kind of thing up for the top (architectural, etc.) development positions at facebook. They were recently named the best place to work at in 2010, so they can afford to do this.
I contacted the like a little guys and they sent me back 2 puzzles before they would even speak to me. The first one was dead simple and took about 14 seconds to write the code and another 7 for it to run and give me the answer.
"A 7 digit number consists of 7 distinct digits (from 0..9 ofcourse); The product of the first 3 digits = product of central 3 digits = product of last 3 digits; Find the middle digit."
"Middle Number: 2" "Set: 1892463" "Common Products: 72"
The next question I did not understand; I just figured I was not smart enough because I have no college and I am just a hacker that makes shit not a "software eng.". I sent it to a friend of mine that teaches Econ. at a top college and he said he had no idea what they were even asking. (see question below)
Given a list of N line segments on the X axis: (x1[i], x2[i]) where i = 1 to N; And then a list of M queries. Each query inputs one x-coordinate and you need to output the number of line segments that overlap this point. Assume M & N are very large. (So O(M*N) is really bad.)
I asked for clarification and got none so I guess they figured i was just too stupid to respond to which is cool but it made me wonder if when people talk about programmers that cant program do they mean people that cant answer these types of questions? I spent 5 or 10 min or it and gave up. But even though I didn't answer this I can code like a MF and if this question had been a programming challenge I think I could have done it.
My point is that companes should really think before sending out stuff like that to potential developers because they might pass up on some really good talent. I am not saying that I am very talented but I do know how to code and build cool products. I made digest.io and it uses clojure, ML, MapReduce to learn about your diet and help manage digestive conditions and it has paying customers that are happy. I made that and it works well so im not a rookie but I still have no idea what that 2nd question is asking.
BTW: Even though i hate these puzzles the FB puzzles are simple and I have always been able to complete them quickly.
"A 7 digit number consists of 7 distinct digits (from 0..9 ofcourse); The product of the first 3 digits = product of central 3 digits = product of last 3 digits; Find the middle digit."
"Middle Number: 2" "Set: 1892463" "Common Products: 72"
The next question I did not understand; I just figured I was not smart enough because I have no college and I am just a hacker that makes shit not a "software eng.". I sent it to a friend of mine that teaches Econ. at a top college and he said he had no idea what they were even asking. (see question below)
Given a list of N line segments on the X axis: (x1[i], x2[i]) where i = 1 to N; And then a list of M queries. Each query inputs one x-coordinate and you need to output the number of line segments that overlap this point. Assume M & N are very large. (So O(M*N) is really bad.)
I asked for clarification and got none so I guess they figured i was just too stupid to respond to which is cool but it made me wonder if when people talk about programmers that cant program do they mean people that cant answer these types of questions? I spent 5 or 10 min or it and gave up. But even though I didn't answer this I can code like a MF and if this question had been a programming challenge I think I could have done it.
My point is that companes should really think before sending out stuff like that to potential developers because they might pass up on some really good talent. I am not saying that I am very talented but I do know how to code and build cool products. I made digest.io and it uses clojure, ML, MapReduce to learn about your diet and help manage digestive conditions and it has paying customers that are happy. I made that and it works well so im not a rookie but I still have no idea what that 2nd question is asking.
BTW: Even though i hate these puzzles the FB puzzles are simple and I have always been able to complete them quickly.
They probably didn't answer because if you need clarification on the question, you have no hope of producing the answer. And incidentally it IS a programming challenge. (Which is why the econ prof had no clue.)
You have a collection of N intervals. And a collection of M points (which they call queries). For a given interval and point, that point can be in the interval or not. For each point you are supposed to find out how many intervals it is inside of. And you're supposed to make the code fairly efficient.
From the way you've written it, the intervals look like open intervals. So x1[i] is not in the i'th interval. That is a minor but significant detail, and I expect their test data to check it.
The naive solution is to write a function that takes an interval and a point, and says whether that point is in that interval. Then you just loop over all points and intervals. This works, but the number of times you run that comparison is N * M. Which, if N and M are large, is going to be painfully slow. In fact there is a notation to discuss how slow, and that notation would say O(N * M). They don't want any variant on this solution.
The solution they are probably looking for is O((N + M) * log(N)). One solution is to try to first find and put into sorted form all of the intervals where the answer is going to be constant across the interval, and then do a binary search for each point to find what interval it falls into (and therefore what the answer is for that point).
My guess as to their thinking is that anyone who can't figure out something like this won't have any clue when they cause scalability problems. This matters for larger sites.
If you don't understand any of what I just said, that's a hole in your background. To fix it go off and learn about little-o, big-O, and some basic algorithms. A short list of algorithms to learn could include quicksort, merge sort, hashing, binary search and how a BTree works. That combination will solve most problems pretty easily.
You have a collection of N intervals. And a collection of M points (which they call queries). For a given interval and point, that point can be in the interval or not. For each point you are supposed to find out how many intervals it is inside of. And you're supposed to make the code fairly efficient.
From the way you've written it, the intervals look like open intervals. So x1[i] is not in the i'th interval. That is a minor but significant detail, and I expect their test data to check it.
The naive solution is to write a function that takes an interval and a point, and says whether that point is in that interval. Then you just loop over all points and intervals. This works, but the number of times you run that comparison is N * M. Which, if N and M are large, is going to be painfully slow. In fact there is a notation to discuss how slow, and that notation would say O(N * M). They don't want any variant on this solution.
The solution they are probably looking for is O((N + M) * log(N)). One solution is to try to first find and put into sorted form all of the intervals where the answer is going to be constant across the interval, and then do a binary search for each point to find what interval it falls into (and therefore what the answer is for that point).
My guess as to their thinking is that anyone who can't figure out something like this won't have any clue when they cause scalability problems. This matters for larger sites.
If you don't understand any of what I just said, that's a hole in your background. To fix it go off and learn about little-o, big-O, and some basic algorithms. A short list of algorithms to learn could include quicksort, merge sort, hashing, binary search and how a BTree works. That combination will solve most problems pretty easily.
From the explanation you just gave I sovled it in 7 minutes but i guess thats no challenge since you did all the thinking and I just had to code it. But I see what you mean; i feel like I should have known that and will definitely go look into the things you suggested.
--Thanks
--Thanks
use an interval tree
I took each x axis line segment
x(1) -> x(6) for example
and hashed it at 1,2,3,4,5,6
and did that for everyone
then it would simply be a question of iterating each M point and looking at the hash table
Probably a stupid way to do it but it worked.
I think the issue was that I did not know points == queries
Probably a stupid way to do it but it worked.
I think the issue was that I did not know points == queries
Hashing is indeed the wrong way to go.
Yea, i just wanted to solve it quick so I didn't feel like such a dumb ass. I did it again using your solution and now i see what you mean about scalability because your way is much much faster and more efficient. I had to run my solution on my db server using memcache because it was taking too long and too much memory but yours ran on my laptop.
Here are some challenges from Quora, the Q&A site:
http://www.quora.com/challenges
http://www.quora.com/challenges
I really like these puzzles. After you get through the first few trivial ones. The submission process is a little frustrating in that you have no idea if your code failed because it's wrong or because it simply took too long.
Taking too long is a real problem with a few of the puzzles (eg breathalyzer). If you read the comment threads there are some astoundingly fast solutions out there. My C breathalyzer solution was pretty quick but I was running it on an Ubuntu VM running inside Windows 7 and that did impact performance (particularly I/O). I've been meaning to run it on a real Ubuntu setup but haven't gotten around to it.
Anyway it all became moot as I ended up getting a job at Google but I did find it an interesting exercise.
Taking too long is a real problem with a few of the puzzles (eg breathalyzer). If you read the comment threads there are some astoundingly fast solutions out there. My C breathalyzer solution was pretty quick but I was running it on an Ubuntu VM running inside Windows 7 and that did impact performance (particularly I/O). I've been meaning to run it on a real Ubuntu setup but haven't gotten around to it.
Anyway it all became moot as I ended up getting a job at Google but I did find it an interesting exercise.
Meh, perhaps I've grown crotchety, but I'm not jumping through hoops for you (theoretical employer), sorry. I can solve puzzles just fine, but I'd rather spend the holidays implementing new PostgreSQL driver.
[deleted]
I'm confused, what exactly do they mean by this bit, "If you compressed your solution, any Makefile/build.xml files (and the executable file itself) need to be uncompressed and/or built into the same root directory as the compressed archive itself or your submission will result in a build error."
Are they saying that the archive shouldn't have any directories in it period or that it should all be in one directory?
Are they saying that the archive shouldn't have any directories in it period or that it should all be in one directory?
Sounds like neither. A prebuilt binary (or the makefile and resultant binary) should be at the top level. You could have other files in subdirectories if you liked.
Is it considered a deal breaker if interviewees are unable to solve such puzzles during interviews?
The puzzles posed in interviews at Facebook (and at Google) have a lot less B.S. It's more geared toward data structures/algorithms. Failing to solve these puzzles is a deal breaker.
here's a kind of medium example from Fog Creek: given a list of elements in lexicographical order (i.e. ['a', 'b', 'c', 'd']), find the nth permutation
I'll add that they'll give you a certain amount of guidance if you require it, but beyond a certain point they're just helping you to make it less awkward.
here's a kind of medium example from Fog Creek: given a list of elements in lexicographical order (i.e. ['a', 'b', 'c', 'd']), find the nth permutation
I'll add that they'll give you a certain amount of guidance if you require it, but beyond a certain point they're just helping you to make it less awkward.
There is also Facebook Hackercup on the way: http://www.facebook.com/hackercup
Why have I been downvoted? Facebook suggests to practice with the puzzles linked by OP before registering for Hackercup, so these are very well connected.
Uh, maybe I'm just failing the first puzzle, but how do you submit these?
The instructions are below the list of puzzles - "Follow all of the following directions or your submission may be considered incorrect."
It's automated grading, so it's nitpicky about the submission format, etc.
It's automated grading, so it's nitpicky about the submission format, etc.
You have to be very careful about spaces and returns on some of them as well. Fortunately they tend to have short and precise output specifications.
I do wish their grading script could give a little more indication of what failed, as I'm not sure it will even tell you the difference between a build error and a test failure. If it does, great. I struggled with that a year ago when I first worked on them.
I do wish their grading script could give a little more indication of what failed, as I'm not sure it will even tell you the difference between a build error and a test failure. If it does, great. I struggled with that a year ago when I first worked on them.
I hacked up a simple script to automate submissions (https://gist.github.com/757221). It handles a single file per puzzle, so an executable or an archive.
Bah! No Lua :(
I think one of the reasons I don't do well on these is because my brain doesn't seem to work well for hypotheticals. I need real world use cases or else it's exceedingly difficult for me to work out a solution for a problem that is too abstract.
Maybe I'm unique amongst other programmers with my level of experience. It's possible that other programmers love doing puzzles like this, but I tend to get discouraged if I'm looking at a company, and they use tests and puzzles to gauge my capabilities.
Especially (and I wouldn't accuse Facebook of this, but it happens much too often), if those tests and puzzles are substitutes for looking at the massive amounts of code I've written.