I must say, beforehand, that I’m not a director. The advice here comes from some of my conversations with this person in the summer of 2019, when I was a teeny tiny 19-year-old intern.

Image for post


“You cannot study.”

It seems counter-intuitive to tell a prospective applicant to _not _study for a technical interview. Most tips emphasize getting the “Cracking the Coding Interview” book or doing copious amounts of problems on LeetCode. Personally, I believe this is good advice for people who aren’t super knowledgeable or comfortable with the basics of Data Structures & Algorithms, or even having any preparations whatsoever, but Ms. Director believed otherwise:

Studying is actually going to do you a disservice. Now if you want to sit and think about the interview as a whole a little bit, if someone asked you “What are you working on?” meaning side and personal projects, it’s a reasonable thing to be prepared for. But don’t study coding itself.

A little background on what she said: Most internship interviews are split into two parts, the coding challenge, and a small bit of time where you talk about you, the developer, as a whole. Things such as your side projects can be brought up. Your interviewer might ask you to clarify technical parts of your project, and they expect to hear about your ownership and understanding of it.

It’s reasonable to pre-formulate your thoughts, just looking at your code and making sure you actually interview with the right mindset

As Ms. Director said, this is where you should obviously go in prepared. Know what things you might want to talk about, what projects, what technologies, libraries, which skills you have as a developer or team player. Don’t go into your interview like a deer in headlights.

Now onto the hiring methodology:

“Always pick to turn away people you should’ve hired.”

Here, Ms. Director gives some idea of what the recruiting guidelines are for Facebook:

One of the things on the interview process that folks won’t tell you is, whenever you have a system that has a gray area, you have to choose on which side of it you fall. If you want to take it statistically, call it False Positives or False Negatives. When we interview, we have to choose “too tough” or “too soft.” If we are too tough, we turn away good people we should’ve hired. If we are too soft, we hire people we should not have.

Ask a question that’s really difficult, and you might be unnecessarily turning away a candidate that is capable of doing the daily tasks of an engineer. But is that necessarily a bad thing? She continues:

When you think about it, once you’re in a system that has to pick one of the two, either “too tough” or “too soft,” you always pick to turn away people you should’ve hired. It’s a tough thing of life, but that’s how you’ll be careful. Because letting people in who are not good for the job is really bad for the business.

Facebook’s largest spending comes from employee salaries — about 1.27 Billion spent on software developers & engineers last quarter. The median compensation for an employee is in the mid-200 thousands. But it’s not just about the financial cost; lacking team members negatively affect the entire team.

… and it’s also not good for that person. I don’t know about you, but I’m not excited about a job where I go struggle everyday and end up miserable. So, we have to have a default stance of “unsure = NO.”

**The main claim: **Ms. Director believes that if you practice too much, you appear over-prepared, and risk making the interviewer _unsure. _Unsure about what you know, and what you don’t know.

If the interviewer asks you a tough question, and you immediately start writing the answer or doing it without fault, they will be suspicious that you’ve done this question or something very similar in the past, to the point that you’ve memorized it.

So, you really can’t study. It comes off so bad. We have interviews where the interviewer comes back and says, “they were reciting. Clearly. No hire.”

This could be why so many people are turned down after a seemingly perfect interview. You might provide a solution correctly, but the way in which you arrive at the solution ultimately betrays you.

This is not to say all rejections are explained by “unsure = NO.” It’s just a possible way to screw up.

#tips #internships #software-development #facebook #interview

Interviewing Advice from a Facebook Director
1.15 GEEK