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.

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

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

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

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

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

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.

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

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

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.

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