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.
“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.
So if there was one takeaway, it’s that memorizing solutions to specific CS problems will not help you in anything (other than answering a specific CS problem.) Conceptual understanding is what your interviewer is after. They want to see that you can struggle with a problem but then come out on top. They want to see you genuinely asking questions, being curious about solutions, making mistakes, and correcting yourself — just how a day-in-a-life of an engineer is. If you don’t show a clear boundary of what you know and what you don’t know, the interviewer will leave the room with that “unsure = NO” mindset. When you don’t practice, you show your true skills during an interview process — whether that’s a positive or negative thing. In the end it is your responsibility to determine whether you already have the necessary conceptual understandings needed to succeed in an interview.
I can’t recommend you do this, I just thought it would be an interesting look into the brain of someone high up in hiring chain. But, if you have a lot of interviewing opportunities to spare, you might want to give it a try and let me know!
I’ll leave you with parting words:
We want to know exactly what your boundaries of knowledge are. Be honest. What matters is you being very clear about your weaknesses, as well as your strengths.
If you want to brush up on some of your Data Structures and Algorithms ~~😎 Conceptual Understanding😎~~, I highly recommend you watch through some of the lectures by Professor Josh Hug of UC Berkeley’s CS 61B. Not only is it a perfect resource for interview questions, it’s truly a masterclass in lecturing. Josh Hug was the main content creator of the famous Princeton Coursera course on Algorithms.
Good luck! Follow me at https://twitter.com/DanielEdrisian