Hacker News Reader

Comment by lbrandy | Hacker News Reader

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.

View on HN

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...

> 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.

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.

> 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.

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.

"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).

> 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]

>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...

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.

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.

Reply on news.ycombinator.com