Get that job at Facebook (2012)(facebook.com)
facebook.com
Get that job at Facebook (2012)
http://www.facebook.com/notes/facebook-engineering/get-that-job-at-facebook/10150964382448920%22
173 comments
Facebook needs to be asking candidates just 2 questions.
(1)Can you increase the number of minutes per hour your mom spends on Facebook?
(2)How much do we need to pay you to feel comfortable doing that?
I wish more companies shared their hiring process for developers. Anyway, I hope they do not stick too much the puzzles.
I'm looking forward for the time I'll be able to solve their problems, too.
I'm looking forward for the time I'll be able to solve their problems, too.
Does facebook still use PHP?
Yes, but no. Since moving to HipHip which is a translated/compiled version of PHP, we have been able to fork the language to clean it up. We have a strongly typed version, Generators, etc.
Syntactically it looks a lot like PHP and is backward compatible for many thing, but it's not really PHP anymore. The HipHop team has done a ton to make the language a lot more enjoyable to work in.
Syntactically it looks a lot like PHP and is backward compatible for many thing, but it's not really PHP anymore. The HipHop team has done a ton to make the language a lot more enjoyable to work in.
I did not know you went to such extent. At that scale that makes sense. Do you plan to open source it?
https://www.youtube.com/watch?v=Dwek7dZDFN0 is a pretty good talk about everything coming down the pipe. Generics, Strict typing, Collections, etc.
Too my knowledge (I'm not directly on the Hip-Hop team) it will be open sourced, additionally we also generally present a PHP patch as well to allow it in future versions of standard PHP.
Too my knowledge (I'm not directly on the Hip-Hop team) it will be open sourced, additionally we also generally present a PHP patch as well to allow it in future versions of standard PHP.
They do (according to a post I saw on here a couple of months ago). But for people who don't know, they have an open source VM called HipHop (https://github.com/facebook/hiphop-php) that consumes the PHP.
Yes, if the .php extensions on most of the URLs is any indication.
Hm, I clicked all around the site and wasn't able to get a .php in any of my URLs. They were all "clean" or "pretty" URLs, as I would expect from a profesional, large web app. I wonder why we have different URLs.
When I click "Home," I just get https://www.facebook.com/. I wonder why you get the php urls.
That's most likely just an endpoint named 'home.php' which now leads to some controller instead of actually loading a file called home.php
The redirect url for outgoing links has .php at the end.
Hm, I looked a lot of the links in my news feed and they were all direct.
I didn't realize Facebook did tech talks, I'm glad to see they do and they're linked from this site:
https://www.facebook.com/media/set/?set=vb.9445547199&ty...
My only complaint is I wish they were on Youtube, I'd like to make playlists and watch them on my TV.
https://www.facebook.com/media/set/?set=vb.9445547199&ty...
My only complaint is I wish they were on Youtube, I'd like to make playlists and watch them on my TV.
Why? Work 70 hours a week finding new ways to put more ads in people's lives.
Don't trivialize Facebook. There's no other place online that so easily melds chat, messaging, wall posts, and general keeping up with those closest to you (even when they're not close to you physically). Despite its problems, Facebook provides a lot of utility for many people without having to be cynical about it. I'll put up with all the ads that are somewhat relevant and are not so obtrusive to the extent that they are popups.
I don't think anybody who trivializes Facebook is speaking to the problems they have to tackle at the scale they're at. I think the real cynicism comes from the real added value coming from Facebook at the cost to society it brings (i.e. lost time, ad sales, impact on human interaction, etc.).
Impact on human interaction is a concern in the age of social media. We will always find a way to lose time. I'm not sure if any generation is/was immune to that.
I'm not sure why this is such a common misconception. I almost never work 70, or 60 hour weeks. 50, often, but that's usually my own fault for making promises to others I want to keep.
I've managed inside Engineering at Facebook and am now back to just being a straight Engineer, and my advice to everyone I work with is the same: Don't kill yourself working 70/80 hour weeks. We pay you to give 40 solid hours, and that is what I want. What I ask of you is that you set expectations for the people and teams around you as accurately as you can. Don't make a bunch of promises you have to work crazy hours to keep.
The majority of our most successful engineers have a very good work-life balance.
I've managed inside Engineering at Facebook and am now back to just being a straight Engineer, and my advice to everyone I work with is the same: Don't kill yourself working 70/80 hour weeks. We pay you to give 40 solid hours, and that is what I want. What I ask of you is that you set expectations for the people and teams around you as accurately as you can. Don't make a bunch of promises you have to work crazy hours to keep.
The majority of our most successful engineers have a very good work-life balance.
Because it seems like every mainstream news article about engineering at Facebook is written like this one: http://www.fastcompany.com/3005165/how-facebook-survived-34-...
Maybe it's Facebook PR's fault.
Maybe it's Facebook PR's fault.
So we do lock-downs still, but it's not about working crazy hours, it's about focus. Under lock-down you are allowed to push the other stuff to the side for awhile. For instance I typically do 2-3 interviews a week, help with training new interviewers, etc. This can easily be 5-6 hours of total time out of my week. This is part of being an engineer at Facebook. Onboarding sessions, new engineer mentoring, etc. This is all part of normal workdays, unless you are in a lock-down, then you focus on getting whatever it is you need to get done done and not worry about the rest for awhile.
I personally disagree pretty heavily on sleeping in the office and working crazy hours. I find it very counter productive and generally think it leads to bad decisions, bad code, and ultimately bad products. It is certainly the exception, and not something you should be doing if you aren't 22 years old and/or more than a little crazy. I personally haven't worked crazy hours at Facebook since probably 2009.
Talking about this sort of thing from a PR perspective seems has to balance getting people excited about our environment and explaining our goals and day-to-day. I've found it's something the media outlets love to play up. The normal day-in-the-life of an engineer is fun, but chill, and not particularly news worthy.
I personally disagree pretty heavily on sleeping in the office and working crazy hours. I find it very counter productive and generally think it leads to bad decisions, bad code, and ultimately bad products. It is certainly the exception, and not something you should be doing if you aren't 22 years old and/or more than a little crazy. I personally haven't worked crazy hours at Facebook since probably 2009.
Talking about this sort of thing from a PR perspective seems has to balance getting people excited about our environment and explaining our goals and day-to-day. I've found it's something the media outlets love to play up. The normal day-in-the-life of an engineer is fun, but chill, and not particularly news worthy.
I personally disagree pretty heavily on
sleeping in the office and working crazy hours.
I get that you don't have complete control of the press you get, but maybe it'd be worth focusing some attention on these work-life balance issues in the outlets you do have complete control over.
getting people excited about our environment
It does make me a little sad that so many smart and talented people spend their careers making, delivering and working out how to get people to click on more ads.
I don't just mean programmers. The advertising industry hires many of the most talented people in many areas.
I don't just mean programmers. The advertising industry hires many of the most talented people in many areas.
I was thinking of applying, but... is it really 70 hours a week? Because that's not going to fly with me. I don't do more than 45 as a worst-case average no matter who the employer is.
I don't know many Facebook employees, and I don't know any in California, but 40-45 is what I hear, not 70. I don't know if that's representative of what a normal employee does, but 70 sounds implausible.
I'm going to be starting this July. I know a good number of people in my class who interned there, and wouldn't have joined if I'd heard of 50+ hrs/wk being the norm. From what I've heard, it's a place where you may work long weeks on rare occasions, but that would be due to your desire to get something done, as opposed to external corporate pressure. Not being a current employee, I may be wrong, but that's the impression that I get.
Same reason people work at any famous BigCo: money, security, nice benefits. Not going to change the world, but not everyone wants to do that.
Money, line on a resume, scale, connections
One thing I have seen repeatedly in interviews for engineering positions of all levels is people who have not gone back and reviewed the basic algorithms they learned in second year. I know coding questions as posed in interviews are not the best measure of job performance, but they are also one of the few we have that is guaranteed to be sourced from the candidate in question. To perform well at these sorts of questions, you should be familiar with basic algorithms and techniques. It's a common language that you and the interviewer can speak. Not knowing that language is gimping yourself unnecessarily. Don't know what a graph or a queue is? You're gonna have a bad time.
Take a few hours to study up before interviewing at the big engineering-focused companies.
Take a few hours to study up before interviewing at the big engineering-focused companies.
Basic data structures and algorithms are worth noting, but most of these formulaic interviews seem too focus on an academic base rather than an experience base -- probably good for someone who is only a few years experience.
I've turned down a couple of companies that take the formulaic approach. In most cases, I've not been looking. So, if you reach out to me, there is something in my background that is interesting, and I expect contact to be based around that.
As a counter, when I interview a candidate, I mostly avoid typical questions and try and ask questions intersecting the candidate background and what we are up to. If that is a stretch, I prefer focusing in on a passion or project and talking about the design/implementation challenges there.
Google and Facebook seem to have similar approaches, and because of the number of resumes they get have set up a formulaic system. It probably gets a certain level of quality, but probably also puts artificial caps at the high end.
I've turned down a couple of companies that take the formulaic approach. In most cases, I've not been looking. So, if you reach out to me, there is something in my background that is interesting, and I expect contact to be based around that.
As a counter, when I interview a candidate, I mostly avoid typical questions and try and ask questions intersecting the candidate background and what we are up to. If that is a stretch, I prefer focusing in on a passion or project and talking about the design/implementation challenges there.
Google and Facebook seem to have similar approaches, and because of the number of resumes they get have set up a formulaic system. It probably gets a certain level of quality, but probably also puts artificial caps at the high end.
If you agree that these types of questions are not a good measure of job performance, why encourage this line of questioning? Wouldn't it be better for the industry as a whole to discover better ways to determine future job performance?
I don't set interviewing policy at my company, and anyway I'm unfamiliar with any technique that provides better results. I suppose finding it is a direction of research that would be interesting, but I have a full time job just being an engineer.
My comment is only meant as practical advice to candidates. It is not normative.
My comment is only meant as practical advice to candidates. It is not normative.
knowing these are not going to guarantee good performance. But not knowing them is a clear indication of incompetence. A programmer who doesn't know basic algorithms and data structure is a bad programmer.
Obviously more knowledge is good knowledge. And perhaps the bar for being a good programmer involves being able to
1) Implement a red black tree on a white board
I would argue, though, if that's the bar, there are probably other bars that are a bit lower that at least some of the algorithm triumphalists would fail, such as to
2) Throw up a basic and secure Wordpress site on an Amazon EC2 instance
or
3) You're running into an issue where you're getting an error message about running out of file descriptors. Tell me what's the issue here and what you'd do about it
or
4) write a basic, safe script that makes backups of each file in a given directory and its subdirectories
or
5) tell me what the fuck is the clearfix?
Now, if intermediate algorithms is something that people should be able to do, surely you'd agree 2-5 are even lower bars to meet (since they're things that virtually all of those "bad programmers" are able to do). By the same token, though, it's absolutely the case that many hires at the BigCos actually wouldn't be able to respond to 2-5.
I wouldn't say that those people shouldn't have been hired; after all, people learn! But if algorithms are actually part of the everyday job, someone could also learn them, no?
To the extent that you're testing for raw intelligence--which is the most important aspect of any of these types of jobs--algorithms are a good ruler. But to equate the measurer with the measure is somewhat foolish, because it's a means to an end, not the end itself. If you can use other probes of raw intelligence, those function just as well as being able to vomit up algorithms and data structures that, as people point out, any person who spends a month or so studying can get a solid grasp on and then never need again.
1) Implement a red black tree on a white board
I would argue, though, if that's the bar, there are probably other bars that are a bit lower that at least some of the algorithm triumphalists would fail, such as to
2) Throw up a basic and secure Wordpress site on an Amazon EC2 instance
or
3) You're running into an issue where you're getting an error message about running out of file descriptors. Tell me what's the issue here and what you'd do about it
or
4) write a basic, safe script that makes backups of each file in a given directory and its subdirectories
or
5) tell me what the fuck is the clearfix?
Now, if intermediate algorithms is something that people should be able to do, surely you'd agree 2-5 are even lower bars to meet (since they're things that virtually all of those "bad programmers" are able to do). By the same token, though, it's absolutely the case that many hires at the BigCos actually wouldn't be able to respond to 2-5.
I wouldn't say that those people shouldn't have been hired; after all, people learn! But if algorithms are actually part of the everyday job, someone could also learn them, no?
To the extent that you're testing for raw intelligence--which is the most important aspect of any of these types of jobs--algorithms are a good ruler. But to equate the measurer with the measure is somewhat foolish, because it's a means to an end, not the end itself. If you can use other probes of raw intelligence, those function just as well as being able to vomit up algorithms and data structures that, as people point out, any person who spends a month or so studying can get a solid grasp on and then never need again.
If someone doesn't know how to approach an algorithms problem why not get them to show you how they would google around and puts the pieces together.
If they have no idea, they are likely going to google and follow the wrong advice. If they have an idea but have forgotten the specifics they will know where to go and which advice to take.
If they have no idea, they are likely going to google and follow the wrong advice. If they have an idea but have forgotten the specifics they will know where to go and which advice to take.
The utility of google rises exponentially with your pre-exsisting knowledge (at the low end of existing knowledge). If you know nothing about algorithms, then you can still look up and implement, say, a red-black tree. However, if you run into a problem that is simmilar, but not identical to, the problem that a red-black tree solves, you will have a difficult time adapting the red-black tree to your problem.
If, however, you have a strong basis in algorithms, but still no pre-existing knowledge on the red-black tree specifically, then you will be in a better posistion to adapt or optimise it for your particular use case. Not to mention have a better intuition in what to search for in the first place, or who to structure the rest of you code to play nice with an algorithm that is a good fit.
If, however, you have a strong basis in algorithms, but still no pre-existing knowledge on the red-black tree specifically, then you will be in a better posistion to adapt or optimise it for your particular use case. Not to mention have a better intuition in what to search for in the first place, or who to structure the rest of you code to play nice with an algorithm that is a good fit.
Agreed. Even though some interview coding questions are a bit absurd, having a good grasp of basic algorithms and data structures shows that you at least care a little bit about _how_ things work.
I left after "elemental awesomium," someone TL;DR?
TL;DR: You'll never work at Facebook because you don't have the attention span required to spend 5 minutes reading an article.
Well good, I was worried they'd forcibly hire me, so good to know I'm safe. The issue is less attention than having 5 minutes of time available to read obvious self-congratulatory posts filled with annoying startup-y words.
[deleted]
This was posted 2012-07-20. The link title ought to reflect that.
I should also point out that Facebook is hiring not just engineers but also designers, product managers, infrastructure people,...
I just joined a couple of weeks ago as a product manager and in the short time here, I've loved it.
I just joined a couple of weeks ago as a product manager and in the short time here, I've loved it.
How is the interview for a product manager?
I was hoping to get an answer as well.
Is there anything like HN for tech entrepreneurs only, maybe a subreddit somewhere? I see here regularly posts regarding jobs/interviews/etc. which are all great ressources but since they got so many upvotes -- this one is on #1 right now -- I wonder sometimes how many on HN are full-time (tech) entrepreneurs and how many are employed/freelance coders.
I'm in neither of those demographics, but I'd imagine part of being a good entrepeneur is understanding the hiring processes of companies that you will be competing with for talent, so this article should be popular on your hypothetical website too.
Never interviewed at Facebook but have been offered roles at similarly hard to get places. Though I am working at my own startup now, the absurdness of the interviewing process at majority of such places confounds me.
In short, I can't cope up with them well without going through quite a few glassdoor type questions of that respective company. And partially it is because most interviewers already have a set of solutions that they are looking for, and can't appreciate novel solutions and at times even better time/space complexity if they do not fit the standard mold. In my experience only some very hot startups had smart/ open enough interviewers to appreciate new solutions or see the relevance of new CS research results that may solve their question.
Before one starts attacking me on being a CS philistine, I want you to ponder on my background- current work involves designing & implementing pretty intricate & complex algorithms, and earlier research & publications in a range of ML related sub-fields, mainly NLP & recommender systems. I also read CS papers for pleasure, code in multiple languages and did reasonably well in programming competitions- no longer participate, latter is many years ago.
For a similar experience, though from a far more accomplished person, see Tanya Khovanova's blog post on hiring 'the smartest people in the world': http://blog.tanyakhovanova.com/?p=402
Also, FYI I don't resent the system a lot. It is better than it being an old-boys-club; I just dread going through the bootcamp of memorizing/ revisiting trivial stuff in case I ever have to look for a job again.
In short, I can't cope up with them well without going through quite a few glassdoor type questions of that respective company. And partially it is because most interviewers already have a set of solutions that they are looking for, and can't appreciate novel solutions and at times even better time/space complexity if they do not fit the standard mold. In my experience only some very hot startups had smart/ open enough interviewers to appreciate new solutions or see the relevance of new CS research results that may solve their question.
Before one starts attacking me on being a CS philistine, I want you to ponder on my background- current work involves designing & implementing pretty intricate & complex algorithms, and earlier research & publications in a range of ML related sub-fields, mainly NLP & recommender systems. I also read CS papers for pleasure, code in multiple languages and did reasonably well in programming competitions- no longer participate, latter is many years ago.
For a similar experience, though from a far more accomplished person, see Tanya Khovanova's blog post on hiring 'the smartest people in the world': http://blog.tanyakhovanova.com/?p=402
Also, FYI I don't resent the system a lot. It is better than it being an old-boys-club; I just dread going through the bootcamp of memorizing/ revisiting trivial stuff in case I ever have to look for a job again.
The thing that really bothers me about these postings is the advice that you should 'prep'. Conceivably, many applicants will already have a job that requires them to code 8 hours a day. But somehow, the skills required to pass their interview are so out of line with what a programmer does day to day, that extracurricular studying is required.
It would suggest that the interview itself selects for mostly irrelevant skills if that is a problem they're having with the process.
It would suggest that the interview itself selects for mostly irrelevant skills if that is a problem they're having with the process.
(Author of the post) Consider this: In any job you're going to do "normal" stuff the majority of the time. The other times, you have to pull out A-level work. It's not 24x7, but when the time comes you have to be able to do it, eg writing a parser for an obscure query language that will get executed $X billion times per day, so it better be small, correct, and fast.
We ask people to prep because we want to know if you can do that level of work.
We ask people to prep because we want to know if you can do that level of work.
Well, that sounds just weird. Either you expect the people being interviewed as part of their prep to learn and remember forever everything they ever may need at Facebook and that could possibly be asked in the interview, or your argument doesn't make sense. If I hadn't any contact with parsers/compilers for a while I will need to look stuff up. When you have no frame of reference in my process when getting the information necessary to solve the problem - how can that possibly be a good indicator of me being able to solve an unforeseen problem? If there is a known solution and I already have the exact algorithm, the hard part is over and it's only about writing code. Which is exactly what people seem to complain here: The skill to reproduce a known algorithm is at best the lowest possible bar.
[deleted]
It reads like a category error to me. My experience is that the coming times that require A-level work from memory are emergencies and the "$X billion times a day query parser" ones are not, allowing more iteration and collaboration.
You may be right, but all I know is my own experience. The query parser example is real; I had to do something like that recently in order to more deeply analyze some performance bugs.
The process you describe in the essay is portrayed as one of policy and iterated improvement at Facebook, oriented around "How We Do It," with your GP example meant as support for that process as relates to "prep mode" approaches to interviewing at FB. It sounds like you're backing away from that, though.
Was your query parser work done under the pressure and constraints of an interview environment? Would you have been able to write that parser in the same form at a white board during your actual interview?
Was your query parser work done under the pressure and constraints of an interview environment? Would you have been able to write that parser in the same form at a white board during your actual interview?
[deleted]
Thanks. That kind of answer is what I'm most curious about. What exactly is the A-level work that is not "normal stuff" that you want your candidates to be prepared for.
I agree that most of the work that needs to be done in this industry could be done by a well-trained monkey. And there are plenty of well-trained monkeys doing said work. But you really want more competent people doing it because you never know when you'll randomly encounter something that needs more ability than just cutting and pasting within a known template.
As an example of why, consider this famous Brian Kernighan quote, Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? I've certainly been in the situation where the website is crashing, nobody knows why, but we need it fixed immediately. And solving the problem under pressure like that is twice as hard as debugging it normally.
When things go pear shaped, you really want someone available to debug it who is both competent, and familiar with the code in question. This is easy if the person who wrote the code is competent. But if the person who wrote the code is not amazingly competent, you may be stuck with your choice of competent people who don't know the code, and incompetent people who do know the code. Neither of whom is in a good position to fix the problem.
This is hopefully not a situation that comes up very often. It is not something most of us get a lot of practice for. And we put a lot of effort into avoiding a pants on fire situation. But ideally you want all of your programmers to be able to think at this level. (Even if they mostly demonstrate it by avoiding problems in the first place.)
As an example of why, consider this famous Brian Kernighan quote, Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? I've certainly been in the situation where the website is crashing, nobody knows why, but we need it fixed immediately. And solving the problem under pressure like that is twice as hard as debugging it normally.
When things go pear shaped, you really want someone available to debug it who is both competent, and familiar with the code in question. This is easy if the person who wrote the code is competent. But if the person who wrote the code is not amazingly competent, you may be stuck with your choice of competent people who don't know the code, and incompetent people who do know the code. Neither of whom is in a good position to fix the problem.
This is hopefully not a situation that comes up very often. It is not something most of us get a lot of practice for. And we put a lot of effort into avoiding a pants on fire situation. But ideally you want all of your programmers to be able to think at this level. (Even if they mostly demonstrate it by avoiding problems in the first place.)
That baffles me as well. I made another comment in this thread [1], but what really dwells on my mind is: do companies that interview like Facebook really believe that my day-to-day as a programmer has so little to do with the work I would do if were to work at their company?
I'm particularly curious as someone who only did a bit of CS in school and became a full time programmer from work I did as a hobbyist.
And if the answer is "yes, your work has nothing to do with the kind of work we do at Facebook, Google, etc." it's not so much that I'm appalled but actually even more curious about the jobs at those companies than I am now.
[1] https://news.ycombinator.com/item?id=5623861
I'm particularly curious as someone who only did a bit of CS in school and became a full time programmer from work I did as a hobbyist.
And if the answer is "yes, your work has nothing to do with the kind of work we do at Facebook, Google, etc." it's not so much that I'm appalled but actually even more curious about the jobs at those companies than I am now.
[1] https://news.ycombinator.com/item?id=5623861
Another reason I am not fond of this- it is easily hackable. I know some pretty average people who prepared for months, went through all questions they could find online, ignored their day jobs and cleared the interviews, while some really talented people could not.
Funny that this got brought on the Facebook thread. Though I never applied at FB, I have 'mentored' two people who made it through the process. Mentoring as in, helped them make sense (and see the general pattern) of the solutions which they saw online but could not appreciate/ understand on their own. Though I guess they had lesser trouble regurgitating the solutions in the interviews.
Funny that this got brought on the Facebook thread. Though I never applied at FB, I have 'mentored' two people who made it through the process. Mentoring as in, helped them make sense (and see the general pattern) of the solutions which they saw online but could not appreciate/ understand on their own. Though I guess they had lesser trouble regurgitating the solutions in the interviews.
Its very easy to game the interview at big web companies. I mean even if they ask all these text book academia related questions- Algo/DS ones etc.
I remember once there was a question on Quora about an IIT BTech guy who had offers from all major web companies. Some one asked him how he did it. And his advice was that you had to simply 'practice'. Simply go out on the internet check for good interview forums work on it an hour every day. Even if you are actually a worthless programmer on the ground. You can pretty much ace any interview with simply practice.
This also reminds of my Math classes in pre-university college here in India. I would generally try to solve a problem in more than one way and show it to my lecturer. One day she scolded me badly, that my experiments might end up in me scoring less marks. Her point was the evaluators were used to seeing a certain pattern of answers over years. And if the student had a new innovative answer, they would simply mark it wrong because it didn't their 'one true' answer, even if the solution was more elegant and better than the common pattern. Therefore the only way of scoring high marks was to practice all the common patterns.
Rote learning works at all levels.
I remember some days back I watched a interview of RMS on youtube, and he was asked a question on how you could be a good programmer and what books you had to read. And he gave a straight reply- You had to simply work on some hard real world problems/projects and bring them to closure. That was his advice.
Too bad these days we check people on everything apart from their actual work.
I remember once there was a question on Quora about an IIT BTech guy who had offers from all major web companies. Some one asked him how he did it. And his advice was that you had to simply 'practice'. Simply go out on the internet check for good interview forums work on it an hour every day. Even if you are actually a worthless programmer on the ground. You can pretty much ace any interview with simply practice.
This also reminds of my Math classes in pre-university college here in India. I would generally try to solve a problem in more than one way and show it to my lecturer. One day she scolded me badly, that my experiments might end up in me scoring less marks. Her point was the evaluators were used to seeing a certain pattern of answers over years. And if the student had a new innovative answer, they would simply mark it wrong because it didn't their 'one true' answer, even if the solution was more elegant and better than the common pattern. Therefore the only way of scoring high marks was to practice all the common patterns.
Rote learning works at all levels.
I remember some days back I watched a interview of RMS on youtube, and he was asked a question on how you could be a good programmer and what books you had to read. And he gave a straight reply- You had to simply work on some hard real world problems/projects and bring them to closure. That was his advice.
Too bad these days we check people on everything apart from their actual work.
Agree on all points.
Interesting that you brought IIT up. Though I barely cleared IIT JEE and did not attend it for I could not get CS at any of the good schools, I had the feeling that it was becoming more and more hackable with the proliferation of coaching institutes. When I was in a top 5 PhD program which attracts the best of IIT K/B/M guys the quality drop became more evident over the years. There were and are still very bright IITians at my school, but I saw more noise coming in at later years.
And for those who are not aware- there are cram shops in India which 'train' you to clear Google/ Microsoft interviews. And this has been going for at least 6 years, if not more. Now from talking to my friends in India I get the impression that the superficial interview difficulty is higher in India than the Bay Area for similar companies. And that is despite the work quality being much higher in Silicon Valley.
It's all very funny and ironic.
Interesting that you brought IIT up. Though I barely cleared IIT JEE and did not attend it for I could not get CS at any of the good schools, I had the feeling that it was becoming more and more hackable with the proliferation of coaching institutes. When I was in a top 5 PhD program which attracts the best of IIT K/B/M guys the quality drop became more evident over the years. There were and are still very bright IITians at my school, but I saw more noise coming in at later years.
And for those who are not aware- there are cram shops in India which 'train' you to clear Google/ Microsoft interviews. And this has been going for at least 6 years, if not more. Now from talking to my friends in India I get the impression that the superficial interview difficulty is higher in India than the Bay Area for similar companies. And that is despite the work quality being much higher in Silicon Valley.
It's all very funny and ironic.
>>there are cram shops in India which 'train' you to clear Google/ Microsoft interviews.
This is so true, that I can't even find ways how to assert it more.
As a fresher, I attended a off campus interview here in Bangalore(Those who don't know- these are generally mass hiring drives, where hundreds/thousands get hired) where I happened to talk to a guy between written test sessions who even had taken very elaborate 'class notes' on clearing these interviews. He had gone through something like a 3 months coaching class just to attend these interviews. There are standard coaching materials, which are updated pretty frequently. Pretty much anything that they can ask you in these interviews will be covered. They have made you hard practice it so much it will be cake walk to you make it through.
>>And this has been going for at least 6 years
I can assure this has been going on for a very long time now.
>>It's all very funny and ironic.
Its all about the volumes. A recruiter told me, if a resumes falls down during a mass hiring drive they don't even bother to pick it up. We live in an era where recruiters search monster.com based on some keywords and pick up candidates based on that. So we are now down to SEO optimization for resumes. And then coaching classes to game the interviews.
As a side note, in all major IT services companies in India you have to take 'certification exams' for pay hikes and promotions. I've seen people drop everything they do and practice clearing these for months. The worst part is you have to 'memorize' the whole material. Later I would see those people go on to get promotions and hikes, while the actual who go the work done fail(due to lack of time to practice) in the certification exams.
This is so true, that I can't even find ways how to assert it more.
As a fresher, I attended a off campus interview here in Bangalore(Those who don't know- these are generally mass hiring drives, where hundreds/thousands get hired) where I happened to talk to a guy between written test sessions who even had taken very elaborate 'class notes' on clearing these interviews. He had gone through something like a 3 months coaching class just to attend these interviews. There are standard coaching materials, which are updated pretty frequently. Pretty much anything that they can ask you in these interviews will be covered. They have made you hard practice it so much it will be cake walk to you make it through.
>>And this has been going for at least 6 years
I can assure this has been going on for a very long time now.
>>It's all very funny and ironic.
Its all about the volumes. A recruiter told me, if a resumes falls down during a mass hiring drive they don't even bother to pick it up. We live in an era where recruiters search monster.com based on some keywords and pick up candidates based on that. So we are now down to SEO optimization for resumes. And then coaching classes to game the interviews.
As a side note, in all major IT services companies in India you have to take 'certification exams' for pay hikes and promotions. I've seen people drop everything they do and practice clearing these for months. The worst part is you have to 'memorize' the whole material. Later I would see those people go on to get promotions and hikes, while the actual who go the work done fail(due to lack of time to practice) in the certification exams.
>> where I happened to talk to a guy between written test sessions who even had taken very elaborate 'class notes' on clearing these interviews.
Pretty sure there would be coaching classes to get into coaching classes with higher hit rates of finally clearing the interviews. It's that broken.
Whenever people talk about the madness of India's youth, I can't help not quoting Soumen:
"It's hard to overstress the liability of a nation of a billion people out of which 700 million are functionally illiterate and the rest have no wish to follow instructions, even when they are asking for a favor."
http://www.cse.iitb.ac.in/soumen/APKGKAH/illiterate/Applicat...
>> As a side note, in all major IT services companies in India you have to take 'certification exams' for pay hikes and promotions.
Hope you are fortunate enough to be not working for such places anymore.
Pretty sure there would be coaching classes to get into coaching classes with higher hit rates of finally clearing the interviews. It's that broken.
Whenever people talk about the madness of India's youth, I can't help not quoting Soumen:
"It's hard to overstress the liability of a nation of a billion people out of which 700 million are functionally illiterate and the rest have no wish to follow instructions, even when they are asking for a favor."
http://www.cse.iitb.ac.in/soumen/APKGKAH/illiterate/Applicat...
>> As a side note, in all major IT services companies in India you have to take 'certification exams' for pay hikes and promotions.
Hope you are fortunate enough to be not working for such places anymore.
Broken? It sounds exactly how optimization systems work :-)
I think that raises another question. You assume that they don't want the process to be hackable, what if they just want someone to see the patterns in those solutions because they believe those patterns arise in the work they will be doing at Facebook?
Though I doubt that, it might be true that being good in algorithmic puzzle-solving (as opposed to real-world algorithmic research/ development) helps employees in their day-to-day work. And I do think they maybe missing some real gems because of it.
But in my opinion, they just need an easily definable and quantifiable process. And they are happy to look the other way when they see covert cheating/ hacking as long as it clears the process. And there is no denying that there is still a decent ability threshold which most covert cheating people too will pass, which I guess suffices the corp needs.
I am a far bigger fan of pair programming after a basic phone screen, but large companies just can't do that.
But in my opinion, they just need an easily definable and quantifiable process. And they are happy to look the other way when they see covert cheating/ hacking as long as it clears the process. And there is no denying that there is still a decent ability threshold which most covert cheating people too will pass, which I guess suffices the corp needs.
I am a far bigger fan of pair programming after a basic phone screen, but large companies just can't do that.
From the post: "Good coding problems are fractal in nature. They can be extended arbitrarily to gauge the depth of your knowledge. For example, you might be asked to solve a problem any way you want. Then you'll be asked to solve it again in constant space or sub-linear time."
You could prepare for months but if you don't understand the core CS concepts then it's difficult to hack these kinds of interview problems. Having a solution is one thing, but coming up with 3 different solutions to the same problem based on various constraints (preprocessing, space/time constraints) requires understanding.
If they "hacked" this, then thru likely understand the concepts well enough such that its sufficient for the job.
Also, interviewers should ask if they interviewee has seen the coding problem before and come prepared with a backup. Interviewers are also looking to see if the interviewee derives the answer too easily. Usually scraping the surface reveals whether the person really knows what they're talking about or not.
You could prepare for months but if you don't understand the core CS concepts then it's difficult to hack these kinds of interview problems. Having a solution is one thing, but coming up with 3 different solutions to the same problem based on various constraints (preprocessing, space/time constraints) requires understanding.
If they "hacked" this, then thru likely understand the concepts well enough such that its sufficient for the job.
Also, interviewers should ask if they interviewee has seen the coding problem before and come prepared with a backup. Interviewers are also looking to see if the interviewee derives the answer too easily. Usually scraping the surface reveals whether the person really knows what they're talking about or not.
I don't disagree with anything you say. As I mentioned earlier that all people who hack such interviews do have basic understanding/skills requisite for the corp, quite enough to play the gymnastics of the interviews.
A good interviewer does try to gauge whether the answer was known to the interviewee. But I have seen that happen far more at hot startups than big companies- primarily because of their more stringent process which leaves less wiggle room for guess work and is more tuned towards concretely judged parameters.
I just don't like the facade of 'hiring the smartest people' in the world, when their mechanism largely filters just well-trained average people.
And I most certainly don't want to sound condescending, so I apologize before-hand. But I probably used a different definition of average than what you or most people here may have in mind. I know quite a few ACM ICPC world finalists, am a region finalist myself, and have conducted/ published CS research with reasonable impact. So I was simply using my PhD program peers as good, and people with lesser (proven) skills as average. My fault, but I hope you can see what I was trying to say.
A good interviewer does try to gauge whether the answer was known to the interviewee. But I have seen that happen far more at hot startups than big companies- primarily because of their more stringent process which leaves less wiggle room for guess work and is more tuned towards concretely judged parameters.
I just don't like the facade of 'hiring the smartest people' in the world, when their mechanism largely filters just well-trained average people.
And I most certainly don't want to sound condescending, so I apologize before-hand. But I probably used a different definition of average than what you or most people here may have in mind. I know quite a few ACM ICPC world finalists, am a region finalist myself, and have conducted/ published CS research with reasonable impact. So I was simply using my PhD program peers as good, and people with lesser (proven) skills as average. My fault, but I hope you can see what I was trying to say.
I see your point and do feel the same way. The problem (industry-wide) is that the process only allows for a glimpse of a candidate. Even if you're interviewing all day, you're probably only talking to each interviewer for 1 hr (or less) and evaluating many different aspects of them (technical, personality, motivation, etc). And this is supposed to speak for your whole career.
I do think there are false negatives through this process but that's the trade off, I believe, for efficiency. Considering how time consuming interviews are (for the interviewer), there has to be some ways of reducing the wheat from the chaff.
After all, many use a university degree (from a prestigious university) as an initial filter. However, I'm sure there are many talented people who don't have degrees. But when looking at the probabilities, your chances of finding a great candidate are significantly higher if you filtered on that degree.
I do think there are false negatives through this process but that's the trade off, I believe, for efficiency. Considering how time consuming interviews are (for the interviewer), there has to be some ways of reducing the wheat from the chaff.
After all, many use a university degree (from a prestigious university) as an initial filter. However, I'm sure there are many talented people who don't have degrees. But when looking at the probabilities, your chances of finding a great candidate are significantly higher if you filtered on that degree.
Well trained average people are good enough to do great things. That is a feature, not a bug.
I made another comment on this thread [1]. I wish instead of having to prep for interviews like this, I could just present a portfolio of clean code I made myself (non-proprietary of course) or my github. Unfortunately most of the grads they're hiring have no serious code to show for themselves.
[1] https://news.ycombinator.com/item?id=5623922
[1] https://news.ycombinator.com/item?id=5623922
> really bothers me about these postings is the advice that you should 'prep'
Advice to prep bothers you? Wow! I thought it went without saying that any endeavor of import benefits from prep.
Advice to prep bothers you? Wow! I thought it went without saying that any endeavor of import benefits from prep.
If you don't care enough to skip a couple of episodes of Mad Men and warm up your brain before you come in, you aren't interested in working here.
This was my experience interviewing at Facebook. I spent one interview solving a problem in a way that was more efficient than the default, recursive solution. My interviewer was obviously disappointed, and wondered why I wasted so much time when a less efficient solution would have sufficed.
That was the exact opposite of my experience interviewing at Google, and when I got an offer from Google I took it.
That was the exact opposite of my experience interviewing at Google, and when I got an offer from Google I took it.
Knowing when to not microoptimize is a skill.
Honestly, you should have decided based on compensation, geography, etc. The jobs are similar. But you microptimized :-)
Honestly, you should have decided based on compensation, geography, etc. The jobs are similar. But you microptimized :-)
Those comments at the end... geeze.
"pls give me job at facebook call me 5551231234"
"send link to aplication to [email protected]"
"pls give me job at facebook call me 5551231234"
"send link to aplication to [email protected]"
All Facebook blog comments are of similar nature. It's pretty astounding.
I hope this doesn't sound facetious, but what I hear over and over again is that places like Facebook have difficult technical interviews that are algorithm focused to create more false negatives than false positives because they work on hard problems.
What are some concrete examples of hard problems tech companies face that require novel solutions and why are algorithms problems the best way to find the people qualified to solve them?
I know these seem like a naive questions, but these two things seem to be taken for granted in every interview discussion (or even if someone argues against them it's mostly a "this is how I find good people" argument). I think it's pretty clear this isn't the only way to find good people, I'd just love to hear more about the thinking behind this interview style and what it really means to these companies when they say "we deal with hard problems." The only concrete example I've ever been given is someone at another big Valley company speaking about difficulty of master-master writes between data centers at a large scale. Which certainly qualifies but I'd love to hear what other "hard problems" are out there.
What are some concrete examples of hard problems tech companies face that require novel solutions and why are algorithms problems the best way to find the people qualified to solve them?
I know these seem like a naive questions, but these two things seem to be taken for granted in every interview discussion (or even if someone argues against them it's mostly a "this is how I find good people" argument). I think it's pretty clear this isn't the only way to find good people, I'd just love to hear more about the thinking behind this interview style and what it really means to these companies when they say "we deal with hard problems." The only concrete example I've ever been given is someone at another big Valley company speaking about difficulty of master-master writes between data centers at a large scale. Which certainly qualifies but I'd love to hear what other "hard problems" are out there.
What are some concrete examples of hard problems tech companies face that require novel solutions and why are algorithms problems the best way to find the people qualified to solve them?
This is best answered by awesome example. See http://research.google.com/people/jeff/ for a list of some the problems that one Google programmer met, and solved. Many of said problems were novel at the time, though many have now learned the answers that Jeff came up with.
These kinds of problems and answers are simply not understandable to people who don't understand algorithms. And you can tell people without a deep understanding of algorithms how to solve those problems, and they will consistently get it wrong.
This is best answered by awesome example. See http://research.google.com/people/jeff/ for a list of some the problems that one Google programmer met, and solved. Many of said problems were novel at the time, though many have now learned the answers that Jeff came up with.
These kinds of problems and answers are simply not understandable to people who don't understand algorithms. And you can tell people without a deep understanding of algorithms how to solve those problems, and they will consistently get it wrong.
/What are some concrete examples of hard problems tech companies face that require novel solutions/
I'm a User Interface Engineer at Facebook in the Photos team. One common thing we do is to display photos in a grid. This is one subject that's really important, yet I haven't see any good documentation about it. I've first looked at all the websites that did some interesting image layouts algorithms, reproduced them and documented them.
Google Plus: http://blog.vjeux.com/2012/image/image-layout-algorithm-goog... Lightbox: http://blog.vjeux.com/2012/image/image-layout-algorithm-ligh... Lightbox Android: http://blog.vjeux.com/2012/image/image-layout-algorithm-ligh... 500px: http://blog.vjeux.com/2012/image/image-layout-algorithm-500p...
Unfortunately, none of them really suited our needs. We wanted to let users have the ability to make any (or all) images bigger. So I started playing around and writing a new image layout. The hardest part was to have an algorithm that was designed such that you could move images around in real time in ways that feel natural to the user, even though we have constraints that are impossible to solve.
Basic algorithm: http://blog.vjeux.com/2012/image/image-layout-algorithm-face... Reordering algorithm: http://blog.vjeux.com/2012/image/image-layout-algorithm-face...
I'm a User Interface Engineer at Facebook in the Photos team. One common thing we do is to display photos in a grid. This is one subject that's really important, yet I haven't see any good documentation about it. I've first looked at all the websites that did some interesting image layouts algorithms, reproduced them and documented them.
Google Plus: http://blog.vjeux.com/2012/image/image-layout-algorithm-goog... Lightbox: http://blog.vjeux.com/2012/image/image-layout-algorithm-ligh... Lightbox Android: http://blog.vjeux.com/2012/image/image-layout-algorithm-ligh... 500px: http://blog.vjeux.com/2012/image/image-layout-algorithm-500p...
Unfortunately, none of them really suited our needs. We wanted to let users have the ability to make any (or all) images bigger. So I started playing around and writing a new image layout. The hardest part was to have an algorithm that was designed such that you could move images around in real time in ways that feel natural to the user, even though we have constraints that are impossible to solve.
Basic algorithm: http://blog.vjeux.com/2012/image/image-layout-algorithm-face... Reordering algorithm: http://blog.vjeux.com/2012/image/image-layout-algorithm-face...
It is so cool that you guys can post about this stuff externally. It's one of my few regrets working at G. Thanks for the interesting reading.
That's some very cool stuff. Thanks!
>>These kinds of problems and answers are simply not understandable to people who don't understand algorithms.
Are you saying that jeff or whoever algo genius can come up with a solution to all those problems given say a couple of hours?
C'mon- Problem solving especially of difficult problems or big problems or long term projects is pretty much an iterative process. In which discovery and application of knowledge, and staying productive is more important than number of facts in the head.
Are you saying that jeff or whoever algo genius can come up with a solution to all those problems given say a couple of hours?
C'mon- Problem solving especially of difficult problems or big problems or long term projects is pretty much an iterative process. In which discovery and application of knowledge, and staying productive is more important than number of facts in the head.
Are you saying that jeff or whoever algo genius can come up with a solution to all those problems given say a couple of hours?
Of course not. Those problems and solutions were the result of years of work, by one of the best programmers on the planet. (Inside of Google, Jeff is a legend.) The question was what real problems faced by real companies require an algorithm person to solve, and that is an answer.
But any toy algorithm problem that you could be given in an interview, he could solve instantly. I guarantee it.
Heck, I'm nothing on his scale. Yet most algorithm questions that I see people complain about having been given in an interview I can figure out a decent solution to in under 2 minutes. When I hear people talking about prepping for that sort of question, it seems to me like they are missing the point.
Of course not. Those problems and solutions were the result of years of work, by one of the best programmers on the planet. (Inside of Google, Jeff is a legend.) The question was what real problems faced by real companies require an algorithm person to solve, and that is an answer.
But any toy algorithm problem that you could be given in an interview, he could solve instantly. I guarantee it.
Heck, I'm nothing on his scale. Yet most algorithm questions that I see people complain about having been given in an interview I can figure out a decent solution to in under 2 minutes. When I hear people talking about prepping for that sort of question, it seems to me like they are missing the point.
This is a great question. I can't speak to Facebook, but I ask hard algorithm questions and this is why I do it.
The point of these hard questions is not to assess if you know some obscure algorithm. The algorithms in these questions are obscure precisely because you're not supposed to know them. If the candidate clearly knows the algorithm I switch to a new question.
The point of these questions is to assess your ability to perform under pressure in an unfamiliar situation, which is a fundamental skill that all productive engineers require. I expect that any engineer I greenlight to encounter novel situations. These are not necessarily Hard Problems dun dun dun, but these situations will challenge your problem solving skills and you won't be able to look up the right answer on StackOverflow. I expect candidates to have the ability to deliver a solution that works and makes the right tradeoff between time, quality, and scope.
I have also had interviewers ask hard problems for the wrong reasons. Frowntown to that.
The point of these hard questions is not to assess if you know some obscure algorithm. The algorithms in these questions are obscure precisely because you're not supposed to know them. If the candidate clearly knows the algorithm I switch to a new question.
The point of these questions is to assess your ability to perform under pressure in an unfamiliar situation, which is a fundamental skill that all productive engineers require. I expect that any engineer I greenlight to encounter novel situations. These are not necessarily Hard Problems dun dun dun, but these situations will challenge your problem solving skills and you won't be able to look up the right answer on StackOverflow. I expect candidates to have the ability to deliver a solution that works and makes the right tradeoff between time, quality, and scope.
I have also had interviewers ask hard problems for the wrong reasons. Frowntown to that.
In my experience, I've seen 3 kinds of jobs that demand engineers who can solve "hard" problems:
1. Obviously hard, and needs no explanation e.g. self-driving cars. 2. Basic problems done at ridiculous scale. Quickly matching keywords to web pages is not a hard problem; quickly matching keywords to every web page on the internet is a hard problem. 3. The problem is that (forgivably or not, depending on circumstances) we have no idea what we're trying to do.
1. Obviously hard, and needs no explanation e.g. self-driving cars. 2. Basic problems done at ridiculous scale. Quickly matching keywords to web pages is not a hard problem; quickly matching keywords to every web page on the internet is a hard problem. 3. The problem is that (forgivably or not, depending on circumstances) we have no idea what we're trying to do.
You can also add, doing all of the above things in a situation where it is extremely profitable for others to game your system.
one I was given in an interview:
You're working on the front-end development for a chatting website. Each conversation gets it's own 100x200px div and they are placed on the screen such that two conversation windows are never intersecting.
We want to display a new conversation window, write an algorithm to determine where a conversation can be placed such that it does not overlap with any current conversations. Assume that the website is being displayed at 1024x1280px.
You're working on the front-end development for a chatting website. Each conversation gets it's own 100x200px div and they are placed on the screen such that two conversation windows are never intersecting.
We want to display a new conversation window, write an algorithm to determine where a conversation can be placed such that it does not overlap with any current conversations. Assume that the website is being displayed at 1024x1280px.
You can fit at most 60 chat windows on the screen. So surely you can just start at the top left and wrap around every 10 windows? When you get to 60 you can't display any more.
Or is the problem different? For example you already have some arbitrary number of windows already displayed at arbitrary locations that you cannot move?
Or is the problem different? For example you already have some arbitrary number of windows already displayed at arbitrary locations that you cannot move?
I would assume that you have an arbitrary number of windows already displayed that you cannot move.
In that case, it's probably most space efficient to place each new window next to an already visible window or at an edge of the screen.
So keep a list of possible candidate positions. Each of these positions represents either an edge of the screen or a position directly above/below/to the left/to the right of an existing window. You will need to calculate different offsets for each of these circumstances to generate candidate positions. You easily eliminate ones that fall outside of the screen.
Each time you attempt to add a window you iterate the list of candidate positions. If a candidate position can fit a window (just use brute force 2D AABB collision detection against all windows, or a quadtree/spatial hash to optimise) then place the window there. If it cannot fit remove the position from the candidate list.
Once you have added the window, calculate all the candidate positions (for each side) and add these to the list of possible positions for later windows.
Well it's late and that's the best I can manage.. I know somebody will point out a flaw here :)
So keep a list of possible candidate positions. Each of these positions represents either an edge of the screen or a position directly above/below/to the left/to the right of an existing window. You will need to calculate different offsets for each of these circumstances to generate candidate positions. You easily eliminate ones that fall outside of the screen.
Each time you attempt to add a window you iterate the list of candidate positions. If a candidate position can fit a window (just use brute force 2D AABB collision detection against all windows, or a quadtree/spatial hash to optimise) then place the window there. If it cannot fit remove the position from the candidate list.
Once you have added the window, calculate all the candidate positions (for each side) and add these to the list of possible positions for later windows.
Well it's late and that's the best I can manage.. I know somebody will point out a flaw here :)
You know, for people who have taken graphics classes, this seems like a much easier question because they know about AABB trees. That is the problem at the heart of the question. Also, your idea about candidate positions is wasteful. Just invert the tree so that it contains empty space instead of full space. Then, on insert, remove from the tree.
I guess you still need to find empty spaces that would overlap between branches at various levels. Under some circumstances you could end up backtracking around the tree quite a lot to find somewhere to park when you have a lot of nodes with some free space but not enough.
All kinds of problems are easier for people who know how to solve them. :-)
That is an example of a theoretical solution that may be overkill in practice, especially if you are stuck in JS. Unless you send window positions back to the server for analysis.
And can you code an AABB tree on a whiteboard? :-)
One could try placing the new window at (100x, 200y) for integer x,y, and check for intersection each time with all the existing windows. 3600 overlap tests in the worst case, but you get huge benefits in practice by hinting the location of the last new window.
Optimize a bit by sorting lists of windows by x and y, so you can binary search for the few candidates to overlap test, and you are down to about 1000 window checks. You miss some cases if windows are very maliciously aligned off grid, but you can mitigate that by using a slightly finer grid.
Or test the 8 neighbors (edges and corners) of each existing window (if any), as it is nearly impossible for available space to be not one of those positions.
(You can compute the next window position after the previous window creation or move, so there is no latency when rendering a new window.)
And can you code an AABB tree on a whiteboard? :-)
One could try placing the new window at (100x, 200y) for integer x,y, and check for intersection each time with all the existing windows. 3600 overlap tests in the worst case, but you get huge benefits in practice by hinting the location of the last new window.
Optimize a bit by sorting lists of windows by x and y, so you can binary search for the few candidates to overlap test, and you are down to about 1000 window checks. You miss some cases if windows are very maliciously aligned off grid, but you can mitigate that by using a slightly finer grid.
Or test the 8 neighbors (edges and corners) of each existing window (if any), as it is nearly impossible for available space to be not one of those positions.
(You can compute the next window position after the previous window creation or move, so there is no latency when rendering a new window.)
Naive solution: There are 924x1080 px as possible candidates for the upper-left corner of the new rectangle. Test each of these candidates to see if a rectangle placed there is a valid position. The complexity would be O(W * H * n) where W,H = dimensions in pixels of the screen, n = number of already placed windows. For practical purposes i think this would be a good solution, assuming the need for a new window is not very frequent. I suspect the complexity can be improved though, maybe with some sweep line algorithm.
Am I reading the problem incorrectly or is that just ridiculously easy?
As stated this seems really easy. I think it is supposed to be more like Meebo where the users can resize/move every window (i.e. they dont have to be aligned to any boundary) and they recieve a new message. The Meebo software wants to place a new 100x200 window not on top of any existing window. Write the algorithm to determine where to place it. Then generalize the algorithm to WxH. Hard enough? (If not, find an algorithm that does this in linear time)
Is there a linear time solution? The normal solution is O(N^3) in the number of windows (and does not depend on W,H at all).
Facebook Hacker Cup had a similar problem:
https://www.facebook.com/hackercup/problems.php?pid=53250625...
I almost solved it; after screwing around for a while trying to record only one value for each square, I realized you need to store two values for each square. If we’re looking for the upper-left corner we can put a window, each dead pixel/pixel “poisons” all the pixels less than the width of the window to the left of it and the height of the window above it. Then you just do a linear scan over the remaining pixels. I think my problem was that I used too much RAM because I was trying to store the whole 2D grid; you only need to keep one dimension in memory.
You can see people’s submissions here: https://www.facebook.com/hackercup/scoreboard?round=18989011...
I almost solved it; after screwing around for a while trying to record only one value for each square, I realized you need to store two values for each square. If we’re looking for the upper-left corner we can put a window, each dead pixel/pixel “poisons” all the pixels less than the width of the window to the left of it and the height of the window above it. Then you just do a linear scan over the remaining pixels. I think my problem was that I used too much RAM because I was trying to store the whole 2D grid; you only need to keep one dimension in memory.
You can see people’s submissions here: https://www.facebook.com/hackercup/scoreboard?round=18989011...
This problem is interesting. It doesn't make any sense to use an N^3 solution like the Meebo problem if N can be so large. I haven't looked at any solutions, but it seems like an N*lg N + WH solution would pass.
I guess they also hire a lot of young people who might not have a lot of practical software engineering experience. They probably have studied a lot of algorithms at college though so that is probably the best way to test how good they are at applying things they have learnt.
I also guess that when you run the largest online community out there you might run into problems that you can't find the answer to on stack overflow. Even if these are not the majority of problems you face day to day there's an advantage to having staff on-site who have a hope of solving them.
I also guess that when you run the largest online community out there you might run into problems that you can't find the answer to on stack overflow. Even if these are not the majority of problems you face day to day there's an advantage to having staff on-site who have a hope of solving them.
For my Facebook interview for an internship, I was given a simple string manipulation problem which I solved quickly. Then I was given the N-Queens problem (a more generalized version of this one http://en.wikipedia.org/wiki/Eight_queens_puzzle). Needless to say I didn't solve that with my remaining time, since the interviews are only 45 minutes. I didn't feel it was a fair assessment of my skills.
Do they really expect people to solve 8 queens in under 45 minutes? Even if you already know how to approach the problem, writing out the code to do it would take most of that time it seems like.
Maybe they were trying to ascertain something else about their candidates. Like how they approach problem-solving in general?
Maybe they were trying to ascertain something else about their candidates. Like how they approach problem-solving in general?
Where there other constraints on your N-queens? (no bruteforce? no backtracking? must run in X time?)
Really it was just write code to verify whether it can be done or not (return boolean) based on the N input (integer). Without having to write code it would return true for N >= 4, but I didn't know that. I was just trying to get an initial solution down with recursion, not thinking about backtracking yet or worst case time (which was probably 2^N).
At the larger tech companies, many of their problems typically are an issue of scale. They are dealing with large datasets, massive numbers of users, terabytes of data, etc.
When dealing with scale, its important to have efficient solutions. They may need to be time efficient or space efficient due to constraints. Even though space is cheap and hardware is fast, inefficient algos may never work or be very high cost.
Maybe you won't be the one implementing this infrastructure but you may be implementing code on top of this infrastructure and it matters that you understand (at least the basics) the consequences of designing things a certain way.
When dealing with scale, its important to have efficient solutions. They may need to be time efficient or space efficient due to constraints. Even though space is cheap and hardware is fast, inefficient algos may never work or be very high cost.
Maybe you won't be the one implementing this infrastructure but you may be implementing code on top of this infrastructure and it matters that you understand (at least the basics) the consequences of designing things a certain way.
I really like this kind of post and I wish more companies would write about their expectations before you actually get to the interview.
Still, it seems like rather run-of-the-mill process. It will certainly filter out the bad, but you may miss some very good workers who work in different ways. Facebook still seems to be totally focused on code problems, and doesn't even mention if what you've already built is important.
In my opinion, stuff that someone has made should probably be considered the most important thing by miles. It doesn't have to be open-source code, but that certainly helps.
Second most important is communication skills, especially how well they can explain things they have worked on.
From this post, Facebook seems more interested in making sure developer can re-re-re-implement merge-bubble sort-reduce, I'm sure while occasionally printing "Buzz". I understand why these tests can be necessary for a lot of people[1], but I imagine the caliber of people that get past screening at Facebook aren't of that type.
~~~
The most delightful interview I ever had (I was being interviewed) was one where the development team didn't even ask me any general programming questions. They took what I had written as fulfilling that pass, and went straight into several conversations with different developers about the ways we go about making libraries. They asked me to talk about decision making process and how I might explain or advocate for various concepts. I'd like to think if they had any suspicions they might have switched gears to a FizzBuzz level, but I can't know for sure.
These talks got very in depth, and whiteboard-writing was had, but at no time did they ask a programming question that wasn't rooted in the concrete. It was always directed: "How did you...?" "How might we...?" "Didn't you run into problems with...?"
Never did they ask me to implement a common algorithm, which feels silly. I can't remember all of them (or even most of them), and if I needed to in the course of my work I'd consult Professor Wikipedia long before I touch my own corruptible memory. Never did they ask me to implement an obscure algorithm, which popular companies seem to enjoy but I imagine filters out a lot of good candidates who happen to have spent time knowing the wrong things. I do not understand why obscura in itself might impress.
Instead, they had me make worthwhile claims about (my or other's) code and then prove them.
Then they showed me what each of them was working on, ensuring there was two-way discussion on each. They showed me problems they were having, what they were doing, and asked my opinion. They showed me bugs, and we sat down and set breakpoints, talked it over and stepped through until the issue was resolved.
This process lasted two days, and the entire time I was delighted. They did an incredible job of making me feel accepted as a fellow professional developer. I ended up not taking the job for personal reasons, but the entire process and people involved were all wonderful.
(The company was Sencha).
[1] Jeff Atwood's "Why Can't Programmers.. Program?" has a good discussion on that http://www.codinghorror.com/blog/2007/02/why-cant-programmer...
Still, it seems like rather run-of-the-mill process. It will certainly filter out the bad, but you may miss some very good workers who work in different ways. Facebook still seems to be totally focused on code problems, and doesn't even mention if what you've already built is important.
In my opinion, stuff that someone has made should probably be considered the most important thing by miles. It doesn't have to be open-source code, but that certainly helps.
Second most important is communication skills, especially how well they can explain things they have worked on.
From this post, Facebook seems more interested in making sure developer can re-re-re-implement merge-bubble sort-reduce, I'm sure while occasionally printing "Buzz". I understand why these tests can be necessary for a lot of people[1], but I imagine the caliber of people that get past screening at Facebook aren't of that type.
~~~
The most delightful interview I ever had (I was being interviewed) was one where the development team didn't even ask me any general programming questions. They took what I had written as fulfilling that pass, and went straight into several conversations with different developers about the ways we go about making libraries. They asked me to talk about decision making process and how I might explain or advocate for various concepts. I'd like to think if they had any suspicions they might have switched gears to a FizzBuzz level, but I can't know for sure.
These talks got very in depth, and whiteboard-writing was had, but at no time did they ask a programming question that wasn't rooted in the concrete. It was always directed: "How did you...?" "How might we...?" "Didn't you run into problems with...?"
Never did they ask me to implement a common algorithm, which feels silly. I can't remember all of them (or even most of them), and if I needed to in the course of my work I'd consult Professor Wikipedia long before I touch my own corruptible memory. Never did they ask me to implement an obscure algorithm, which popular companies seem to enjoy but I imagine filters out a lot of good candidates who happen to have spent time knowing the wrong things. I do not understand why obscura in itself might impress.
Instead, they had me make worthwhile claims about (my or other's) code and then prove them.
Then they showed me what each of them was working on, ensuring there was two-way discussion on each. They showed me problems they were having, what they were doing, and asked my opinion. They showed me bugs, and we sat down and set breakpoints, talked it over and stepped through until the issue was resolved.
This process lasted two days, and the entire time I was delighted. They did an incredible job of making me feel accepted as a fellow professional developer. I ended up not taking the job for personal reasons, but the entire process and people involved were all wonderful.
(The company was Sencha).
[1] Jeff Atwood's "Why Can't Programmers.. Program?" has a good discussion on that http://www.codinghorror.com/blog/2007/02/why-cant-programmer...
Hi. I work at facebook and do many interviews.
Facebook still seems to be totally focused on code problems
I would say that statement is categorically false. In fact, the article lists 4 criteria, only one of which would be "code problems". The interview certainly has a focus on coding, but it most assuredly is not a total focus. And people can, have, and will pass the coding bar, and still fail to get an offer.
stuff that someone has made // communication skills, especially how well they can explain things they have worked on.
Both of these are critical parts of every facebook interview.
From this post, Facebook seems more interested in making sure developer can re-re-re-implement merge-bubble sort-reduce
I don't think that is a well supported inference from the post in question.
Facebook still seems to be totally focused on code problems
I would say that statement is categorically false. In fact, the article lists 4 criteria, only one of which would be "code problems". The interview certainly has a focus on coding, but it most assuredly is not a total focus. And people can, have, and will pass the coding bar, and still fail to get an offer.
stuff that someone has made // communication skills, especially how well they can explain things they have worked on.
Both of these are critical parts of every facebook interview.
From this post, Facebook seems more interested in making sure developer can re-re-re-implement merge-bubble sort-reduce
I don't think that is a well supported inference from the post in question.
Hi! Just pitching in here as an outsider who has interviewed twice with Facebook and talked to quite a few others (mostly fresh graduates) who have. I did not receive an offer on both occasions, but I'll try to remain unbiased. I did receive an offer from Google and Quora, if it helps.
Facebook's interview process seems to have a very high variance in terms of candidates' experiences about the process. In the telephone rounds, collabedit often has sync issues, which can be quite stressful for first timers. Occasionally, interviewers either do not speak clearly, keep moving away from the speakerphone or have a very difficult to understand accent (not sure how to solve this one). These two things compounded together have caused several people I know to have a terrible experience in the first round, and it appears that these issues are not taken into consideration when making a final decision, as was the case for me. I had two phone interviews because the first one had these issues. I was called to the campus for the final interviews, which I would certainly describe as "code problems", or more accurately as algorithm based problems. I actually found these interviews to be easier than the phone rounds, which was a common opinion among the other candidates I met. I was quite surprised to not get an offer and my guess is that the botched phone round had an effect, but I may be wrong.
This is intended as honest feedback rather than a sour grapes reaction to not being extended an offer. I have interviewed with several other companies and usually the experience is either consistently good or consistently bad, which at least gives the candidates a fair playing field. My guess would be that this feedback is getting ignored because it primarily comes from rejected candidates.
Finally, it would be great if software companies started sharing feedback about candidates' performance if they don't receive an offer instead of a cliched e-mail. Quora seems to be the only one doing this at the moment: https://www.quora.com/Quora-Recruiting/Can-I-get-the-feedbac...
Facebook's interview process seems to have a very high variance in terms of candidates' experiences about the process. In the telephone rounds, collabedit often has sync issues, which can be quite stressful for first timers. Occasionally, interviewers either do not speak clearly, keep moving away from the speakerphone or have a very difficult to understand accent (not sure how to solve this one). These two things compounded together have caused several people I know to have a terrible experience in the first round, and it appears that these issues are not taken into consideration when making a final decision, as was the case for me. I had two phone interviews because the first one had these issues. I was called to the campus for the final interviews, which I would certainly describe as "code problems", or more accurately as algorithm based problems. I actually found these interviews to be easier than the phone rounds, which was a common opinion among the other candidates I met. I was quite surprised to not get an offer and my guess is that the botched phone round had an effect, but I may be wrong.
This is intended as honest feedback rather than a sour grapes reaction to not being extended an offer. I have interviewed with several other companies and usually the experience is either consistently good or consistently bad, which at least gives the candidates a fair playing field. My guess would be that this feedback is getting ignored because it primarily comes from rejected candidates.
Finally, it would be great if software companies started sharing feedback about candidates' performance if they don't receive an offer instead of a cliched e-mail. Quora seems to be the only one doing this at the moment: https://www.quora.com/Quora-Recruiting/Can-I-get-the-feedbac...
> I don't think that is a well supported inference from the post in question.
From the post in question:
> [screening portion] The bulk of the time is spent on coding exercises. The interviewer will send you a link to a collaborative editor and ask you to solve some programming problems.
> We will ask you to do a lot of coding during the interview process, because programming ability tends to correlate strongly with how well people perform as employees. We even have a large set of take-home questions. It can't hurt to check them out and maybe solve a couple before you even submit your resume.
> Take your time preparing. Do code katas and practice interviewing with friends. Try solving the interview questions on our site.
> Hard training makes for an easy battle. Brush up on techniques that you may not use every day, but are very useful when you need them: recursion, graph theory, tree traversal, combinatorial problems, etc.
> You might be asked to implement some well-known library functions.
Being asked to implement some well-known library functions is why I said re-re-re-implement merge-bubble sort-reduce. The rest is why I said FB seems more interested in this than anything else on the list.
Code katas? Take-home questions? Maybe it isn't this way in practice, but the post certainly makes it sound like a bizarro SAT. Needing to "prep" and "practice" coding questions in the way encouraged seems rather odd to me.
From the post in question:
> [screening portion] The bulk of the time is spent on coding exercises. The interviewer will send you a link to a collaborative editor and ask you to solve some programming problems.
> We will ask you to do a lot of coding during the interview process, because programming ability tends to correlate strongly with how well people perform as employees. We even have a large set of take-home questions. It can't hurt to check them out and maybe solve a couple before you even submit your resume.
> Take your time preparing. Do code katas and practice interviewing with friends. Try solving the interview questions on our site.
> Hard training makes for an easy battle. Brush up on techniques that you may not use every day, but are very useful when you need them: recursion, graph theory, tree traversal, combinatorial problems, etc.
> You might be asked to implement some well-known library functions.
Being asked to implement some well-known library functions is why I said re-re-re-implement merge-bubble sort-reduce. The rest is why I said FB seems more interested in this than anything else on the list.
Code katas? Take-home questions? Maybe it isn't this way in practice, but the post certainly makes it sound like a bizarro SAT. Needing to "prep" and "practice" coding questions in the way encouraged seems rather odd to me.
Hi, author here -- the article focuses on "code prep" because that's something you can brush up in a short-ish period of time. You can't become a nicer or more thoughtful person quickly, so on those parts of our criteria we take people as they are.
Implementing some well-known library functions is basically a quick way to see whether you know how they work.
If you don't feel it's necessary to ever practice for an interview, well, ok. This advice is not for you.
Implementing some well-known library functions is basically a quick way to see whether you know how they work.
If you don't feel it's necessary to ever practice for an interview, well, ok. This advice is not for you.
> If you don't feel it's necessary to ever practice for an interview, well, ok. This advice is not for you.
I don't think that was his point at all, with all due respect. I got the impression he was just criticizing the rather stereotypical technical interview, which Facebook seems to subscribe to very strongly based on the article.
I don't think that was his point at all, with all due respect. I got the impression he was just criticizing the rather stereotypical technical interview, which Facebook seems to subscribe to very strongly based on the article.
Have you stopped to consider that given the pressure situation of an interview at a well respected company, and without the common resources a programmer generally works with (an IDE and reference documentation), that a person might have trouble with this despite understanding how it works?
It seems like you should be asking 'Write me something to do X, using Y from the standard library' and evaluating that code, if you're looking to evaluate how well someone knows a library function.
It seems like you should be asking 'Write me something to do X, using Y from the standard library' and evaluating that code, if you're looking to evaluate how well someone knows a library function.
"Knowing the argument signature" and "knowing how to implement the guts" are two very different things. I personally don't care if you can remember fine details of the API. We ask many kinds of questions; in the article these are only examples.
If people who already work in software feel the need to study for an interview, it's a pretty decent indication that the interview itself is... not ideal.
Please share what is the ideal interview.
Not necessarily "ideal" IMO, but a friend told me about an interview where they told him beforehand "bring your own laptop, set up", then when he arrived they told him "please build this" (I think it was something similar to Everything). After a couple of hours when he was done, they asked him to add some functionality (network support? can't recall).
At least this type of interview seems to solve the problem of developers strangely needing to study for an interview, and I would guess it also better represents coding ability.
Alternate versions can include "debug this" and "design this" (which is pretty popular AFAIK).
At least this type of interview seems to solve the problem of developers strangely needing to study for an interview, and I would guess it also better represents coding ability.
Alternate versions can include "debug this" and "design this" (which is pretty popular AFAIK).
> If you don't feel it's necessary to ever practice for an interview, well, ok. This advice is not for you.
It is wrong to conclude that the person whose comment you replied to, feels that way. Excerpt: "Needing to "prep" and "practice" coding questions in the way encouraged seems rather odd to me." [emphasis added]
It is wrong to conclude that the person whose comment you replied to, feels that way. Excerpt: "Needing to "prep" and "practice" coding questions in the way encouraged seems rather odd to me." [emphasis added]
>You can't become a nicer or more thoughtful person quickly
Why not?
The main downside of these kind of interviews is that the candidate has to prepare.
This may be well suited for fresh grads, but not for mid-career senior engineers.
You should seek good candidates as is. But, you already assume that one needs to prepare...
This may be well suited for fresh grads, but not for mid-career senior engineers.
You should seek good candidates as is. But, you already assume that one needs to prepare...
Hi, author here. With respect, I am a mid-career senior engineer too. I trained for a few weeks before interviewing at Facebook because, well, changing jobs is important. There is zero harm spending some time warming up mentally.
I recommend that people prepare because I've seen many many obviously smart people not make it through. It's like showing up for a singing audition without warming up your voice. You might have a beautiful voice, but you have to show it in the best condition possible.
I recommend that people prepare because I've seen many many obviously smart people not make it through. It's like showing up for a singing audition without warming up your voice. You might have a beautiful voice, but you have to show it in the best condition possible.
[deleted]
They can't test you on the intricacies of your current project, because they don't know them.
An interview needs a greatest common denominator. That is what an undergraduate CS test is.
An interview needs a greatest common denominator. That is what an undergraduate CS test is.
This echoes the best interview I ever had, which finished with the interviewer starting me with a problem ("This functionality is running slow and hanging a lot") and had me walk through how I'd diagnose the problem, from the front end to the database: he was interested in what metrics I'd gather, what question I'd ask about how things work, who I'd want to rope in for help with particular parts of the problem, and so on. It was all drawn from a real-world problem they'd solved a few weeks ago.
I've used that ever since when I've been a technical interviewer. It's fascinating hearing how people go about solving problems, and it tells me a lot about their actual skills.
(One of the best responses for a sysadmin role qas a quiz around sudenly degraded performance and the first question was, "What's changed? I'll check the change management to see what's gone live recently.")
I've used that ever since when I've been a technical interviewer. It's fascinating hearing how people go about solving problems, and it tells me a lot about their actual skills.
(One of the best responses for a sysadmin role qas a quiz around sudenly degraded performance and the first question was, "What's changed? I'll check the change management to see what's gone live recently.")
> In my opinion, stuff that someone has made should probably be considered the most important thing by miles. It doesn't have to be open-source code, but that certainly helps.
Problem is, a lot of good engineers (especially at big companies) may have spent a lot of time working on something that wasn't very important or good. They may have been a sparkling diamond in a sea of mediocrity.
One of my first jobs I spent the best part of a year working on something pretty dumb that was mired in bureaucracy and most people considered a bad idea from the start.
Yet that is what I worked on for around a year because that was where I was assigned, and it was considered important by edict of a person who earned approx 1000x my salary.
They eventually scrapped the project altogether.
Problem is, a lot of good engineers (especially at big companies) may have spent a lot of time working on something that wasn't very important or good. They may have been a sparkling diamond in a sea of mediocrity.
One of my first jobs I spent the best part of a year working on something pretty dumb that was mired in bureaucracy and most people considered a bad idea from the start.
Yet that is what I worked on for around a year because that was where I was assigned, and it was considered important by edict of a person who earned approx 1000x my salary.
They eventually scrapped the project altogether.
Why not make it an either or type of thing. "Would you rather solve an algorithm based question, or discuss some work you've done in the past that demonstrates that aptitude?"
Because I don't know how to judge past work in your niche. My niche is different.
Or,... the stuff I built in the first 10 or so years of my career is classified. I'd have to kill you if you saw it. Some of it was pretty cool stuff, though.
This sounds awesome. The next time I interview for a position somewhere, I really hope it's closer to this, than to obscure problem solving trivia.
The next time I interview someone to work for me, I really hope I can make the experience as collaborative and rewarding as it sounds this was for you.
The kinda person who I can work through this interview with is exactly the kinda person I wanna work for / employ.
The next time I interview someone to work for me, I really hope I can make the experience as collaborative and rewarding as it sounds this was for you.
The kinda person who I can work through this interview with is exactly the kinda person I wanna work for / employ.
Other company with a similar process (in my experience): Yammer
This sounds similar to something I read about the process at Shopify.
http://swizec.com/blog/the-most-pleasant-job-interview-i-hav...
http://swizec.com/blog/the-most-pleasant-job-interview-i-hav...
Interesting and informative post, but it seems to be focused on software engineers. What is the process and screening like for hardware engineers?
[deleted]
Here's a question: at companies with these kind of approaches, how many of the founders and early employers would have done well in these interviews themselves?
Obviously, services grow and the Facebook of 2013 is very different from the Facebook of 2004, but it's kind of funny to see companies that succeeded because the original team was able to ship (period) evolve to focus on hiring CS majors who can reinvent the wheel on a whiteboard.
Obviously, services grow and the Facebook of 2013 is very different from the Facebook of 2004, but it's kind of funny to see companies that succeeded because the original team was able to ship (period) evolve to focus on hiring CS majors who can reinvent the wheel on a whiteboard.
If you inspect the actual early employees, a majority of them were ivy league grads who most certainly could solve these easy interview problems (It also helped that they could ship code).
That doesn't mean they would have done well in the interviews. Quite a different thing entirely, really. I mean, there's some correlation, but it's not that strong.
Communication from Facebook recruiting team is ZERO after applying. Not even an automated reply.
About a week back, I applied to Facebook after solving a puzzle on their Interviewstreet page successfully within given time.
Sadly I didn't get any kind of acknowledgement from their recruiting team, neither saying I am rejected nor that they have received my application.
About a week back, I applied to Facebook after solving a puzzle on their Interviewstreet page successfully within given time.
Sadly I didn't get any kind of acknowledgement from their recruiting team, neither saying I am rejected nor that they have received my application.
>>Take your time preparing. Do code katas and practice interviewing with friends. Try solving the interview questions on our site.
This makes me wonder, who or what kind of a candidate the person even trying to hire. Programming or any career for that matter is by and large a kind of job that requires you to perform everyday, you have to be consistent. Its not an Boxing match or America's got talent contest which happens once an year for which you do all the preparation for 12 months and then perform on the last hour. Software projects or any project for that matter simply don't work that way. You don't read books for months, decide to do the project and then hammer out all the code in an hour.
>>Impress us with your mastery of whatever language you're best at.
Again, whom are you trying to hire?
>>Hard training makes for an easy battle. Brush up on techniques that you may not use every day, but are very useful when you need them: recursion, graph theory, tree traversal, combinatorial problems, etc.
Sorry but this is getting boring. This algorithm thing is so badly gamed, it doesn't even make a good point of testing a candidate anymore. I've known people who work an hour everyday practicing these interview problems and can ace through such interview in a breeze, but wouldn't even last hours in a demanding work environment.
The best way to check if a candidate is good for you is to do a through check on the quality and kind of projects/problems they have worked on in the past. If they have done well, hire them. Else regardless of whatever they might know from the text books, if they can't get the job done or haven't in the past. They are worthless to you anyway.
This makes me wonder, who or what kind of a candidate the person even trying to hire. Programming or any career for that matter is by and large a kind of job that requires you to perform everyday, you have to be consistent. Its not an Boxing match or America's got talent contest which happens once an year for which you do all the preparation for 12 months and then perform on the last hour. Software projects or any project for that matter simply don't work that way. You don't read books for months, decide to do the project and then hammer out all the code in an hour.
>>Impress us with your mastery of whatever language you're best at.
Again, whom are you trying to hire?
>>Hard training makes for an easy battle. Brush up on techniques that you may not use every day, but are very useful when you need them: recursion, graph theory, tree traversal, combinatorial problems, etc.
Sorry but this is getting boring. This algorithm thing is so badly gamed, it doesn't even make a good point of testing a candidate anymore. I've known people who work an hour everyday practicing these interview problems and can ace through such interview in a breeze, but wouldn't even last hours in a demanding work environment.
The best way to check if a candidate is good for you is to do a through check on the quality and kind of projects/problems they have worked on in the past. If they have done well, hire them. Else regardless of whatever they might know from the text books, if they can't get the job done or haven't in the past. They are worthless to you anyway.
The problem with the previous work done is that could be difficult to show or check. If you worked on a regular company, the work done is not available. I agree that a discussion about previously done software can be very interesting, but that could be gamed too...
I'm afraid that interviewing is never going to be easy for both...
I'm afraid that interviewing is never going to be easy for both...
I need to use Facebook to login to take their 'programming' test. I'm PISSED.
> "Practice writing code in a simple text editor without syntax highlighting or completion macros."
Maybe applicants shouldn't be able to "undo" during the interview? Or maybe applicants should be able to manually convert the code to assembler? Or, heck, have them use one of those behemoth computers with the blinking lights that we have to plug wires into sockets to program?
I mean...why should we rely on any technology that has been developed to make software engineers more effective and that the majority use daily? That would be like if we let sales people use tools they rely on, like charisma, during interviews!
The only sensible argument I've heard for why companies interview with programming puzzle questions is that it "takes too long" to do an interview better (like the way simonsarris pointed out Sencha does). At the point a company is unwilling to look at applicants as humans, and instead treats them as numbers/percentages, I wonder if they're a company worth working for any way.
Maybe applicants shouldn't be able to "undo" during the interview? Or maybe applicants should be able to manually convert the code to assembler? Or, heck, have them use one of those behemoth computers with the blinking lights that we have to plug wires into sockets to program?
I mean...why should we rely on any technology that has been developed to make software engineers more effective and that the majority use daily? That would be like if we let sales people use tools they rely on, like charisma, during interviews!
The only sensible argument I've heard for why companies interview with programming puzzle questions is that it "takes too long" to do an interview better (like the way simonsarris pointed out Sencha does). At the point a company is unwilling to look at applicants as humans, and instead treats them as numbers/percentages, I wonder if they're a company worth working for any way.
Here is one answer for you.
Many programmers will take longer to configure their environment than you have available for the interview. Therefore if you tried to let them interview in the programming environment of their choice, there would be no actual interview. (And you'd have to undo whatever they did before the next interview.)
Many programmers will take longer to configure their environment than you have available for the interview. Therefore if you tried to let them interview in the programming environment of their choice, there would be no actual interview. (And you'd have to undo whatever they did before the next interview.)
Configuring the environment shouldn't take more than 5 minutes. You copy the settings files, update them a bit if needed and that's it.
Download and install software. Download and install necessary plugins. Play with window manager settings. Deal with the fact that the version that you are used to using has changed in the last 18 months and needs to be retweaked to behave like you want it to.
I've seen people spend days getting themselves set up exactly the way that they want. And looking at http://xkcd.com/1205/ it isn't obvious that this is a waste of time either.
I've seen people spend days getting themselves set up exactly the way that they want. And looking at http://xkcd.com/1205/ it isn't obvious that this is a waste of time either.
Let the candidate bring a laptop?
There are lots of good reasons why you might not want random people plugging in their laptops on your computer, and likewise reasons that you wouldn't want them to walk away with your interview materials loaded on their personal computer.
Most interview questions are verbal, and a laptop is capable of compiling code. Your problems with it seems factitious.
Yes, this easily solves many problems. Plus I get to see exactly how they are used to working, neatly avoiding many "tell me about your environment" questions.
How many people do you actually need to run a website? The whole thing can be maintained by a small team probably.
You're greatly underestimating the complexity of Facebook. I bet they have greater than 200,000 machines. Creating the infrastructure to just manage and deploy to those machines would already go beyond your 'small team'.
Not sure how you imagine a 'small team' managing a system that has an exabyte of data. From network infrastructure all the way down to cold storage, a 'small team' would be needed for each.
Not sure how you imagine a 'small team' managing a system that has an exabyte of data. From network infrastructure all the way down to cold storage, a 'small team' would be needed for each.
My interview technique is this; I look at their resume for the typical buzzwords. Next, I ask them to explain about said buzzword, what they worked on, what they thought of the technology.
Then, we dig deeper. Anything they say, I continue to ask them followup questions. Eventually, we dig deep enough to know whether this person truly knows said technology or just put in on their resume for buzzword compliance.
It might go something like, "Oh, I see you've had some experience with REST. What is REST?" ... "How does REST relate to HTTP? Is HTTP required?" ... "What HTTP verbs are considered idempotent? What does that even mean, how is this useful?" ... "How would you implement a {insert} application using REST?"
There's no "tricking" the candidate this way. If they know their stuff, they get to talk in depth about it allowing them to shine. You will recognize this person, as we all love to talk about things we actually know something about.
And the other type will also be spotted. They get nervous when you start probing deeper on what they said they should know. They start giving really bad, contradictory and even laughable answers as you go.
Then, we dig deeper. Anything they say, I continue to ask them followup questions. Eventually, we dig deep enough to know whether this person truly knows said technology or just put in on their resume for buzzword compliance.
It might go something like, "Oh, I see you've had some experience with REST. What is REST?" ... "How does REST relate to HTTP? Is HTTP required?" ... "What HTTP verbs are considered idempotent? What does that even mean, how is this useful?" ... "How would you implement a {insert} application using REST?"
There's no "tricking" the candidate this way. If they know their stuff, they get to talk in depth about it allowing them to shine. You will recognize this person, as we all love to talk about things we actually know something about.
And the other type will also be spotted. They get nervous when you start probing deeper on what they said they should know. They start giving really bad, contradictory and even laughable answers as you go.
I'm sort of disappointed that this is #1 on the board.
I don't have a problem with the piece per se, I just have the general feeling that an article on how to impress mid level managers to get a job at some giant established company is considered "hacker" news is.. I mean, am I the only one that thinks that's the antithesis of hacker ethos? There's no "hack" to this, it's like reading a pamphlet on how to get a job after college or something. It's not /wrong/, per se, but there's no real special insight here, and it basically reads like a PR piece.
I don't have a problem with the piece per se, I just have the general feeling that an article on how to impress mid level managers to get a job at some giant established company is considered "hacker" news is.. I mean, am I the only one that thinks that's the antithesis of hacker ethos? There's no "hack" to this, it's like reading a pamphlet on how to get a job after college or something. It's not /wrong/, per se, but there's no real special insight here, and it basically reads like a PR piece.
> Give feedback. We regularly survey candidates about the interview process and take feedback seriously.
Yet so few companies give feedback.
Yet so few companies give feedback.
From a legal perspective, that's a dangerous move. There are any number of ways an interviewer's feedback could be misinterpreted (or correctly interpreted, I suppose) as being an illegal reason for issuing a no-hire. Even if you're careful, there's a non-zero chance of a really bad outcome. It just isn't worth it.
I know about this legal thing, but still.
By the way, I'm wondering why do some people insist of working at a company which doesn't want them? Besides money from a lawsuit, of course. Even if the interview wasn't "fair", it's someone else's company, so they should be able to hire whoever they want.
By the way, I'm wondering why do some people insist of working at a company which doesn't want them? Besides money from a lawsuit, of course. Even if the interview wasn't "fair", it's someone else's company, so they should be able to hire whoever they want.
Working at fb sounds like cool experience. Though im wary of companies who still make one suffer through such interviews. Thats what keps me as a contractor. None of that interviews funny business.
Fb recruiter, if you read this, shoot me an email.
Fb recruiter, if you read this, shoot me an email.
Does anyone at facebook know how the full time hiring of interns works? I'm starting an internship in the bay area office in a few weeks and it looks like the odds of coming out with an offer are pretty slim. Right now there are ~500 people scheduled for the summer intern block and I believe that facebook currently only has about 1000 fulltime engineers. My understanding of internships at 'lesser' tech companies seems to be that if you impress your superiors you'll probably come out with an offer. The idea that i'm getting from facebook is that I have to compete against basically everyone else. I'm very excited by also a bit nervous.
The "fit" category is fairly vague, but a better description of it (and what I think about when interviewing candidates) is "how would I feel if I had to stay late fixing a live site issue with this person?" Ideally that doesn't happen, but I find it helpful framing question.
For coding questions, I generally have a pretty low bar - and it's gotten lower. Generally I look for understanding of basic data structures, and the ability to manipulate them. I realize that's slightly biased towards recent grads, but I think linked-lists, binary trees, and pointers are fair game even for experienced candidates. I'm sometimes amazed at how many people have problems with what I think are simple questions.
SQL and schema design questions are also good, and lend themselves very well to iterative questions. It's easy to start with simple problem statement, have someone get a reasonable solution, and then throw additional requirements in.