This is good general, high-level advice and following it might slightly increase your chances, but I'm more and more convinced every day (and every jumped-through hoop) that there is no formula--and that random chance plays the biggest role in how far you get through any given interview funnel. The solution, if that's true, is just to make it a probability problem. Get as many interviews as you can, and as long as your chance of getting the job is greater than zero, you'll eventually get one. In tech, especially at these big companies, it's an employer's market, and they have the luxury of being able to be as picky as they want: There's always a line out the door of qualified candidates.
What I've learned from 100s of interviews with candidates at top tech companies
31–40 of 225 posts
Re: What I've learned from 100s of interviews with candidates at top tech companies
#32I'll try to stay active on this thread if anyone has any more specific questions. (Context: I'm the author of Cracking the Coding Interview)
If you do not get an offer even though you did well on technical questions(verified your answers online). Should you reapply? Why? Personally I think it's the sign of cultural fit issue so they unlikely will like you just because you reapply.
When people don't get an offer after a technical interview, it's typically about technical skills. Even if they think they did well because they verified their answers online. Often, although their answers were eventually correct, it took them too long to get there which the interviewer perceived as weak problem solving skills.
Re: What I've learned from 100s of interviews with candidates at top tech companies
#33The advice about not giving up on the question is a key point here.
In a previous startup I would ask a single question that would take 30+ minutes to work through with no expectations that the candidate would ever get the answer. All I cared about was if you could break down the issues and move from one set to the next in trying to narrow down the issue. I cared deeply about how you thought, not what you knew.
As people will ask the question had to do with networking and knowning the answer required you to have seen the issue before and have had delved deep enough into the Ethernet HW specs to get the answer.
Narrowing down the question just required you to think and be able to problem sovle. At the end most people never figured it out but those that spent the time attacking the problem and asking question are the ones that got job offers.
Re: What I've learned from 100s of interviews with candidates at top tech companies
#34Has any link ever been determined between interview performance and on-the-job performance? I've made the clichéd mistake mentioned in the article of wearing a suit to an interview where it wasn't appropriate, and felt the air being sucked out of the room. It strikes me as silly, but what do I know. Do these hiring practices result in a good cohort of employees?
Unfortunately, nobody has any data on the job performance of people who failed their interview.
True but it should be possible to compare interview performance to job. I presume that interview performances for successful hires aren't uniform, and that on-the-job performances aren't uniform either. If these interview practices make sense then presumably there should be a clear correlation between the two.
Re: What I've learned from 100s of interviews with candidates at top tech companies
#35I wonder how much diversity initiatives impact evaluations, if at all?
I know Google is establishing pipelines with HBCUs like Howard and FB is looking into something similar I’ve heard. I also noticed a lot of Google engineers teaching MOOCs happen to be women, which is a great way to be inclusive to people looking to learn.
Just how far does that go in the actual interview evaluation (ie: Do feedback reports have any identifying information, are behavioral or design questions examined for cultural bias etc)
Re: What I've learned from 100s of interviews with candidates at top tech companies
#36Earlier quoted context omitted.
1. No, you don't need to know everything. You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. (If a company is requiring this knowledge, then they're doing whiteboard interviews poorly [or they have a very specific skillset needed]. That's not a problem with whiteboard interviews. That's a problem with that company or interviewer. It takes maybe a week for a…
>> You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. Fine. I know this. Will this give me a job? No >> Yes, I understand that interview prep might interfere with other obligations. You don't have to study. But it'll help you. I'm not sure what you expect here. Do you want companies to hire based on how smoothly you're able to bullshit about what you can cl…
I think we just have to accept that the skills needed to pass an interview are a largely different set than the skills needed to excel at the job. One set of skills is not more important than the other, because you need both of them to get and keep the job. We need to practice both.
Re: What I've learned from 100s of interviews with candidates at top tech companies
#37Sure- you don't need a CS degree but you need to know everything taught in a CS degree regardless of it's applicability to real life software engineering. You should also buy a bunch of books and section off at least a month to study. Especially if you don't have that CS degree. Hope you don't have other obligations like a family or a demanding job. You should also spend a lot of time doing coding competitions even i…
1. No, you don't need to know everything. You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. (If a company is requiring this knowledge, then they're doing whiteboard interviews poorly [or they have a very specific skillset needed]. That's not a problem with whiteboard interviews. That's a problem with that company or interviewer. It takes maybe a week for a…
I'm pretty sure the entire parent comment was sarcastic
Re: What I've learned from 100s of interviews with candidates at top tech companies
#38Earlier quoted context omitted.
1. No, you don't need to know everything. You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. (If a company is requiring this knowledge, then they're doing whiteboard interviews poorly [or they have a very specific skillset needed]. That's not a problem with whiteboard interviews. That's a problem with that company or interviewer. It takes maybe a week for a…
>> You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. Fine. I know this. Will this give me a job? No >> Yes, I understand that interview prep might interfere with other obligations. You don't have to study. But it'll help you. I'm not sure what you expect here. Do you want companies to hire based on how smoothly you're able to bullshit about what you can cl…
>> >> You should know what a binary search tree. You probably don't need to know the specifics of how to balance one.
>> Fine. I know this. Will this give me a job? No
No, it's not about knowledge. The knowledge is needed. But the real focus of the interview is to tackle a new question.
>> I want to be hired for the skills I'm bringing in and not for my ability to solve toy problems on a whiteboard.
The ability to see a hard problem, develop your own solution, and translate that into code is a pretty important skill. "Skills" aren't all about knowledge.
>> If the interviewer cannot filter out bullshitters, the interviewer is incapable of the "job of interviewing". Maybe hire better interviewers. Why is the burden on the candidate?
It's a lot more complex than that. It's not just about filtering out bullshitters. It's also about identifying people who might be great but are unable to talk about it. There's also lots of people who are great but haven't been in situations where they've been able to tackle interesting challenges (either because of their inexperience, industry, etc). Or maybe they've done interesting things but in a related field that's hard to understand.
But, yes, absolutely train interviewers. (Interviewing isn't really a role that you hire for.) But even a very well trained interviewer might not be very effective in a behavioral interview.
>> I agree with this, only so long as the interviewers don't fret about some stupid edge case. Why is there an expectation of perfect code in 15 mins on a whiteboard? Who does that in production?
There generally isn't. What an interviewer should be looking at is not some sort of percent correct element. It's about signal. So if a candidate is totally unable to understand an obvious, that might worry me. The signal the candidate is sending is a poor understanding of details. (Or, maybe not. It depends on the situation.) What I train interviewers on is that correctness in and of itself is not relevant. Why a candidate was correct or incorrect might be.
>> The interviewer knows about these edge cases because they've seen the problem before. But I can guarantee that the same interviewer would not be able to 'perfectly' solve some problems that I pose them without having seen them before.
The interviewer is comparing the candidate to other candidates on the same question. So if a candidate is getting rejected because they failed to be perfect, this means that other candidates are actually getting to perfect solutions. Or you just have a crappy interviewer who rejects everyone.
>> Which brings me back to the question. What is the point of the coding interview (or perfection in coding interview) if the only people who can solve them are the ones who have seen the problem before?
If that's the case? Nothing. But that's not the case.
Re: What I've learned from 100s of interviews with candidates at top tech companies
#39Sure- you don't need a CS degree but you need to know everything taught in a CS degree regardless of it's applicability to real life software engineering. You should also buy a bunch of books and section off at least a month to study. Especially if you don't have that CS degree. Hope you don't have other obligations like a family or a demanding job. You should also spend a lot of time doing coding competitions even i…
1. No, you don't need to know everything. You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. (If a company is requiring this knowledge, then they're doing whiteboard interviews poorly [or they have a very specific skillset needed]. That's not a problem with whiteboard interviews. That's a problem with that company or interviewer. It takes maybe a week for a…
>1. No, you don't need to know everything... It takes maybe a week for a smart developer without a CS degree to learn what they need to know for interviews.
I just went through a job search and I didn't find this true. I think the bar on algorithms has raised significantly with all of the prep material (your book included) out there. I also found a few companies sent over "things to study" lists that were quite comprehensive and included topics that you might not even see in undergrad.
>I'm not sure what you expect here. Do you want companies to hire based on how smoothly you're able to bullshit about what you can claim to have done in the past?
I think this is a false dichotomy. I had two friends that just interviewed at Stripe and loved their process: https://stripe.com/jobs/engineering-onsite.pdf
Re: What I've learned from 100s of interviews with candidates at top tech companies
#40Earlier quoted context omitted.
1. No, you don't need to know everything. You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. (If a company is requiring this knowledge, then they're doing whiteboard interviews poorly [or they have a very specific skillset needed]. That's not a problem with whiteboard interviews. That's a problem with that company or interviewer. It takes maybe a week for a…
I'm pretty sure the entire parent comment was sarcastic
I'm pretty sure I interpreted the comment correctly...