3 ms·

Coding interviews are the easiest interviews. There’s very little difference between the problems, and they usually don’t need a trick. Just discuss your soluti

Coding interviews are the easiest interviews. There’s very little difference between the problems, and they usually don’t need a trick. Just discuss your solution before you start writing the code, and assuming you don’t get a jerk or completely blank, you’ll be fine. It’s the most objective of all the rounds. It’s literally just practice. The fact that it’s so paint by numbers, is probably one of the reasons why interview coaching focuses on it. Manufacture some demand, and you have a low effort company. Technical design is a bit harder to prepare for, because it’s more about trying pattern match systems you know against the problem presented. Unfortunately, there’s not a lot of high level case studies or design discussions. The ones that are hardest to prepare for, and no doubt has sunk many a candidate are the softer interviews, particularly management interviews and cultural fit interviews. Those are a complete crapshoot. There’s probably stock answers to prepare, but the questions are pretty random. If you can figure out how to coach the those in 202X (as opposed to recycling 1965’s advice), then you’ve got something.

homie 5y ago
Absolutely agree. I’ve found that behavioral interviews are harder than technical interviews at this point. If you don’t have the set of experiences they’re looking for then it’s game over. This can be ameliorated slightly if the interviewer is willing to accept a hypothetical, but this has rarely been the case for me recently.
- jonathankoren 5y ago
  Or if your management philosophy doesn’t mesh with theirs. “Tell me about the last time you had make your team work late for a deadline.” “I don’t. It’s been my experience as both an IC and a a manager that crunches just burn people out, and you end up getting less quality work out of them. It’s much better to communicate early and either adjust deadlines or deliverables.” “What if you can’t?” “Unless there is an external forcing function on the company, everything should be negotiable. Does this happen a lot here?” “One or twice a year.” “Huh. It’s only happened to me once in ten years, and that was due to a multimillion dollar contract deadline. If it happens regularly here, then the company should fire the directors of engineering for gross incompetence. They can’t project manage.” Needless to say, I didn’t get the job, but at that point, why would I have wanted it?
djanogo 5y ago
>Manufacture some demand, and you have a low effort company What do you mean by that?
- jonathankoren 5y ago
  I’ve interviewed at four of the five FAANGs, and got offers from three of them, including one of them twice. I’ve interviewed at I don’t know how many startups and midsized companies as well. All the technical interviews are the same. You might get some better interviewers at the bigger companies, but that’s more due to practice on their part. They just have interviewed more people overall, and have asked this question enough times they know the common mistakes. There’s this belief that FAANG interviews are somehow harder, and you need to study for months to prepare, and it’s not really true. It’s the same MO as the test prep business, but with less obvious metrics for success. (You don’t get standardized test scores to compare, you just get an offer… eventually. Did the interview prep business help? Who knows?) The interview prep businesses push the specious idea that FAANGs are tougher, and people believe it. (eg Less than 1% of FAANG applicants get an offer! Well, yeah. Do you know how many people apply? A lot. Do you know how many are nowhere near qualified for the job they’re applying for? Probably more than half.) They keep repeating these claims, they end up scaring people into paying for something that’s not needed. That’s the manufacturing demand part. The low effort part is that technical interview questions and programming puzzles are a penny for two dozen. You give the question and the solution in maybe three different languages (say, JavaScript, Python, and Java) and you’re done. Charge $500 for ten questions, give them a HackerRank link, and you’re done. You’ll spend more on advertising and paid testimonials than anything else. The interview prep companies don’t focus on the noncoding interviews, because they’re harder to find questions for, and harder to grade. When it comes to personal interviews, you have work with each student one on one to help them talk about their experiences most effectively. That’s high touch. If you’re trying to maximize volume, you don’t do that.
  - djanogo 5y ago
    Makes sense, thanks for clarification. But there could be people who are some where in between you and not-qualified, whom this site might be helpful, it's connecting people for specific purpose. The site says you can request somebody from FAANG for mock interview, without knowing quality of these interviews, I assume that would require this company pay for their time.
iamricks 5y ago
I find that for more problems you do need a trick. Once you memorize some of the main algorithms asked, usually the questions are a twist on common algorithms + some trick that is not obvious. Sure you it can become easy if you "Practice" but everything gets easier the more you do it. People who pass these either have have IQ or have grit, thats why companies use this to judge canidates, either you spent 500 hours on learning it or DS/A just sticks to your head like glue.
- jaimebuelta 5y ago
  the main problem is that you can get caught in an interviewing pet project, so it seems obvious for them, but not for you. Properly done, a code interview could not require clever tricks, but the problem is that it's just too easy to slip into that realm...
  - iamricks 5y ago
    That's true, you can get unlucky with interviewers.
    - jonathankoren 5y ago
      The quality of the interviewer is one thing that the interviewee can’t control. The main interviewer failures are: 1) Letting the interviewer struggle. By the end of the interview, the candidate should know what the solution looks like, even if they couldn’t solve the problem themselves. If you let someone struggle too long, you’re failing them. Give feedback early. Point out caveats. Don’t have them code up a dumb a solution, and then in the last 10 minutes tell them to redo it with a completely different approach because it’s suboptimal. (Im not talking about special cars they can retrofit, or if the original wrong solution was trivial. Use your judgement.) The interviewer understands the nuances of the problem. The candidate probably doesn’t. After all, they just heard problem. 2) DO NOT CONFUSE THEM! This happens by giving the wrong feedback. You might think you’re helping someone, but you could be knocking them off their game. If they’re going for the optimal solution, and they know the approach, just let them. It’s not wrong, I’m fact it’s the most correct answer. It’s very easy to confuse someone in these timed and stressful situations. Don’t don’t do it! 3) If it’s a design question, or something else with multiple reasonable answers, then there are multiple correct answers. Make them state their assumptions. Ask how the solution would change if something was different. Don’t expect someone to come in off the street and understand the nuances of your use case and data issues. You didn’t understand them until you were confronted with the obstacles either.
AlwaysRock 5y ago
> Coding interviews are the easiest interviews. For you. I am a bit over a year into my eng career and coding interviews are far harder than any other type of interview for me. I have a handful of stock behavioral question answers that I can adjust for most non technical interviews. I do minimal prep before hand looking up who I am interviewing with to have a few questions for them and try to find a way to relate to them during the interview. That is much easier than someone asking me anything from fizz buzz to red black trees.
- jonathankoren 5y ago
  No one asks anyone to implement a red-black tree. There are too many special cases. Just know it exists and what problem it’s trying to solve. Fizz buzz is a hello world problem. That’s why it exists.
  - AlwaysRock 5y ago
    I'm giving examples of the range of questions that exist. I've been given Fizz Buzz in a real coding interview. I'm sure someone has been asked to implement a red-black tree before. Replace red-black tree implementation with some other silly overly complex question that isnt related to the actual job.
    - jonathankoren 5y ago
      They might ask you to implement sqrt(), but the question being asked isn’t “Can this person implement square root using Newton’s Method?”, it’s “How does this person tackle a problem without an obvious solution?”

homie 5y ago

Absolutely agree. I’ve found that behavioral interviews are harder than technical interviews at this point. If you don’t have the set of experiences they’re looking for then it’s game over. This can be ameliorated slightly if the interviewer is willing to accept a hypothetical, but this has rarely been the case for me recently.

jonathankoren 5y ago
Or if your management philosophy doesn’t mesh with theirs. “Tell me about the last time you had make your team work late for a deadline.” “I don’t. It’s been my experience as both an IC and a a manager that crunches just burn people out, and you end up getting less quality work out of them. It’s much better to communicate early and either adjust deadlines or deliverables.” “What if you can’t?” “Unless there is an external forcing function on the company, everything should be negotiable. Does this happen a lot here?” “One or twice a year.” “Huh. It’s only happened to me once in ten years, and that was due to a multimillion dollar contract deadline. If it happens regularly here, then the company should fire the directors of engineering for gross incompetence. They can’t project manage.” Needless to say, I didn’t get the job, but at that point, why would I have wanted it?

djanogo 5y ago

>Manufacture some demand, and you have a low effort company What do you mean by that?

jonathankoren 5y ago
I’ve interviewed at four of the five FAANGs, and got offers from three of them, including one of them twice. I’ve interviewed at I don’t know how many startups and midsized companies as well. All the technical interviews are the same. You might get some better interviewers at the bigger companies, but that’s more due to practice on their part. They just have interviewed more people overall, and have asked this question enough times they know the common mistakes. There’s this belief that FAANG interviews are somehow harder, and you need to study for months to prepare, and it’s not really true. It’s the same MO as the test prep business, but with less obvious metrics for success. (You don’t get standardized test scores to compare, you just get an offer… eventually. Did the interview prep business help? Who knows?) The interview prep businesses push the specious idea that FAANGs are tougher, and people believe it. (eg Less than 1% of FAANG applicants get an offer! Well, yeah. Do you know how many people apply? A lot. Do you know how many are nowhere near qualified for the job they’re applying for? Probably more than half.) They keep repeating these claims, they end up scaring people into paying for something that’s not needed. That’s the manufacturing demand part. The low effort part is that technical interview questions and programming puzzles are a penny for two dozen. You give the question and the solution in maybe three different languages (say, JavaScript, Python, and Java) and you’re done. Charge $500 for ten questions, give them a HackerRank link, and you’re done. You’ll spend more on advertising and paid testimonials than anything else. The interview prep companies don’t focus on the noncoding interviews, because they’re harder to find questions for, and harder to grade. When it comes to personal interviews, you have work with each student one on one to help them talk about their experiences most effectively. That’s high touch. If you’re trying to maximize volume, you don’t do that.
- djanogo 5y ago
  Makes sense, thanks for clarification. But there could be people who are some where in between you and not-qualified, whom this site might be helpful, it's connecting people for specific purpose. The site says you can request somebody from FAANG for mock interview, without knowing quality of these interviews, I assume that would require this company pay for their time.

iamricks 5y ago

I find that for more problems you do need a trick. Once you memorize some of the main algorithms asked, usually the questions are a twist on common algorithms + some trick that is not obvious. Sure you it can become easy if you "Practice" but everything gets easier the more you do it. People who pass these either have have IQ or have grit, thats why companies use this to judge canidates, either you spent 500 hours on learning it or DS/A just sticks to your head like glue.

jaimebuelta 5y ago
the main problem is that you can get caught in an interviewing pet project, so it seems obvious for them, but not for you. Properly done, a code interview could not require clever tricks, but the problem is that it's just too easy to slip into that realm...
- iamricks 5y ago
  That's true, you can get unlucky with interviewers.
  - jonathankoren 5y ago
    The quality of the interviewer is one thing that the interviewee can’t control. The main interviewer failures are: 1) Letting the interviewer struggle. By the end of the interview, the candidate should know what the solution looks like, even if they couldn’t solve the problem themselves. If you let someone struggle too long, you’re failing them. Give feedback early. Point out caveats. Don’t have them code up a dumb a solution, and then in the last 10 minutes tell them to redo it with a completely different approach because it’s suboptimal. (Im not talking about special cars they can retrofit, or if the original wrong solution was trivial. Use your judgement.) The interviewer understands the nuances of the problem. The candidate probably doesn’t. After all, they just heard problem. 2) DO NOT CONFUSE THEM! This happens by giving the wrong feedback. You might think you’re helping someone, but you could be knocking them off their game. If they’re going for the optimal solution, and they know the approach, just let them. It’s not wrong, I’m fact it’s the most correct answer. It’s very easy to confuse someone in these timed and stressful situations. Don’t don’t do it! 3) If it’s a design question, or something else with multiple reasonable answers, then there are multiple correct answers. Make them state their assumptions. Ask how the solution would change if something was different. Don’t expect someone to come in off the street and understand the nuances of your use case and data issues. You didn’t understand them until you were confronted with the obstacles either.

AlwaysRock 5y ago

> Coding interviews are the easiest interviews. For you. I am a bit over a year into my eng career and coding interviews are far harder than any other type of interview for me. I have a handful of stock behavioral question answers that I can adjust for most non technical interviews. I do minimal prep before hand looking up who I am interviewing with to have a few questions for them and try to find a way to relate to them during the interview. That is much easier than someone asking me anything from fizz buzz to red black trees.

jonathankoren 5y ago
No one asks anyone to implement a red-black tree. There are too many special cases. Just know it exists and what problem it’s trying to solve. Fizz buzz is a hello world problem. That’s why it exists.
- AlwaysRock 5y ago
  I'm giving examples of the range of questions that exist. I've been given Fizz Buzz in a real coding interview. I'm sure someone has been asked to implement a red-black tree before. Replace red-black tree implementation with some other silly overly complex question that isnt related to the actual job.
  - jonathankoren 5y ago
    They might ask you to implement sqrt(), but the question being asked isn’t “Can this person implement square root using Newton’s Method?”, it’s “How does this person tackle a problem without an obvious solution?”