Ask HN: What have the s/w interviews evolved to :(
18 comments
Ask yourself this, if you're losing sleep over the interview process because of anxiety/stress maybe these companies aren't a great fit right now.
A friend of mine studied really hard for three months while working a full time job to get into one of the big four.
He got the job purely because he studied coding interview questions. So he moved to the other side of the world with his gf to work there.
A year later he went into PIP, got out of PIP and then had so much anxiety he couldn't concentrate on his work. Now he has to move back home with little to show for it.
I know this is hard to hear but you most likely will fail until you change your mentality. You're spending your time being very hard on yourself rather than constructively asking why you want this and what is the next step I can take.
A friend of mine studied really hard for three months while working a full time job to get into one of the big four.
He got the job purely because he studied coding interview questions. So he moved to the other side of the world with his gf to work there.
A year later he went into PIP, got out of PIP and then had so much anxiety he couldn't concentrate on his work. Now he has to move back home with little to show for it.
I know this is hard to hear but you most likely will fail until you change your mentality. You're spending your time being very hard on yourself rather than constructively asking why you want this and what is the next step I can take.
You are interviewing at companies that so many people in the field from around the world apply to. So it's really damn challenging to even get an interview lined up. It's up to you, often you can have more fun, and play a bigger role in product design, architecture, and planning at smaller companies. But if you care about the status, pay, and comforts of working at one of the big ones, then go for it. It really depends on what you value.
Also, based on my experience with interviewing and being interviewed, the questions are difficult on purpose. If everyone got the solution, you couldn't differentiate between applicants, but if they are very tough, you can get a sense of a persons problem solving skills, how determined they are, what types of questions they ask to proceed through the problem. etc. It shows a lot about a persons thought process and how likely they are to be successful when a tough problem is thrown at them. Often, getting to the solution isn't the point of the question. Seeing how someone solves something, they haven't encountered before is much more informative (especially for companies and startups working on things that are game changers).
Also, based on my experience with interviewing and being interviewed, the questions are difficult on purpose. If everyone got the solution, you couldn't differentiate between applicants, but if they are very tough, you can get a sense of a persons problem solving skills, how determined they are, what types of questions they ask to proceed through the problem. etc. It shows a lot about a persons thought process and how likely they are to be successful when a tough problem is thrown at them. Often, getting to the solution isn't the point of the question. Seeing how someone solves something, they haven't encountered before is much more informative (especially for companies and startups working on things that are game changers).
I agree with some parts of your answer but I have always wondered do u really evaluate the capabilities solely on an ability to solve these mind bending problems, there are lot of folks who might not know how to get an exact solution for a crazy hard dp problem but are very good devs and vice versa is also true a good cs interview might not necessarily translate to a great dev in a real world scenario.
I didn't mean to imply that I solely evaluate capabilities based on a mind numbing problem. I think it's important to balance questions: CS coding questions that they should know (based on education or previous projects), and questions that they probably haven't encountered before. This way you get a good assessment of the level and quality of their existing knowledge, and then get to assess how well they can think and solve new challenges.
This made the rounds here a little while ago and should help you prepare for CS heavy type interviews:
https://github.com/jwasham/coding-interview-university
It's pretty in depth and extremely popular (44k stars). Hope it helps.
https://github.com/jwasham/coding-interview-university
It's pretty in depth and extremely popular (44k stars). Hope it helps.
I actually just went through a thorough interview search over the past month, where I have interviewed with Google, Facebook, Apple, Stripe, Lyft, and much more. I failed on several of the more earlier interviews due to lack of knowledge/exposure on certain algorithms that could be applied to certain data structures, so I studied them up after failure - that has been my approach in general, fail on interviews, then learn how/why I failed & refine those aspects after.
After the early failures, including a phone screen with Facebook, and an onsite with Google & Apple (with Google, I think I got rejected purely because I bombed the DP question I got really badly, I felt I did strong on all my other sessions), I got accepted by two different teams within Apple after back-to-back 6-7 hour onsites with Apple (with Apple, you interview with the team - I did a total of 3 onsites with Apple, and failed two phone interviews & an onsite for 3 teams).
IMO it is better to optimize for career growth and work on the algorithms/data structures for interview purposes as minimal as possible. They're important, but being good at your regular job is moreso IMO. That has been my guiding philosophy, and it has finally paid off for me - I have 4 1/2 years of experience in predominantly frontend work (and some fullstack as well).
Just food for thought - of course, it's all up to you how you approach interviewing. Personally, I don't fear failure, and use it as an opportunity to improve.
After the early failures, including a phone screen with Facebook, and an onsite with Google & Apple (with Google, I think I got rejected purely because I bombed the DP question I got really badly, I felt I did strong on all my other sessions), I got accepted by two different teams within Apple after back-to-back 6-7 hour onsites with Apple (with Apple, you interview with the team - I did a total of 3 onsites with Apple, and failed two phone interviews & an onsite for 3 teams).
IMO it is better to optimize for career growth and work on the algorithms/data structures for interview purposes as minimal as possible. They're important, but being good at your regular job is moreso IMO. That has been my guiding philosophy, and it has finally paid off for me - I have 4 1/2 years of experience in predominantly frontend work (and some fullstack as well).
Just food for thought - of course, it's all up to you how you approach interviewing. Personally, I don't fear failure, and use it as an opportunity to improve.
Hi I found your post interesting. I'm a frontend dev myself for about 3 years and also with some full stack. I've been on the lookout for frontend engineers at the big4 & I wanted to know how the process is like? Is this CS heavy. If you don't mind can I email you? Thanks in advance.
This doesn't answer your question, but have you tried interviewing at companies that don't get a thousand awesome resumes a day and thus have very tough interview process? When I interviewed last year I had none of these problems. Perhaps your stress, anxiety, and job performance is not worth a job at a "respected" company.
It will be overwhelming to be significantly prepared, even for a passionate CS expert. But a passionate CS expert can still get an offer at these places, even without preparing significantly. This is because (many) interviews are designed to test a breadth of fundamental knowledge, up to pushing the candidate to their limits, and even the limit of the state of the art. As an analogy, just because a Corvette doesn't perform like a Ferrari doesn't mean it's a bad car. It could still be chosen. Perhaps chosen based on some other soft qualities. Or because the Ferrari is too expensive.
Don't worry so much. Keep preparing by focusing on small bite size chunks you can master. Then attempt some interviews.
Don't worry so much. Keep preparing by focusing on small bite size chunks you can master. Then attempt some interviews.
Ehm, what makes you think that "Facebook, Google, Airbnb et. al." should hire people with "a few years of exp"? Also, programming is not only about those huge megacorps. Just join a startup and get some exp.
Focus on the fundamentals and problem solving with data structures. Try to map the solution into a data structure and algorithmic technique. Read and study the solutions. Start as simply as possible. The first task is to understand the problem being asked. Sometimes we figure that out after being shown the solution.
I wouldn't worry about dynamic programming or network flow per se. Everyone finds those hard and looks up the algorithms.
These are at the harder end. Recursion is maybe somewhere in the middle.
That said the competition level could be very high at these companies and ask yourself if you really want to work in such an environment. Also ask if you want to work on what they work on.
Interview questions are the same as word problems we see in math. Class. You have to map the problem into the CS, then apply what you know. Forget finding something optimal at first. Once you have the toolbox of algorithms/data structures you will find success.
I wouldn't worry about dynamic programming or network flow per se. Everyone finds those hard and looks up the algorithms.
These are at the harder end. Recursion is maybe somewhere in the middle.
That said the competition level could be very high at these companies and ask yourself if you really want to work in such an environment. Also ask if you want to work on what they work on.
Interview questions are the same as word problems we see in math. Class. You have to map the problem into the CS, then apply what you know. Forget finding something optimal at first. Once you have the toolbox of algorithms/data structures you will find success.
"Super human"? I went to college 10 years ago to study computer science. Questions were sometimes way harder than that. Part of it is intelligence but it's mostly a memory exercise. Memorize 500 soluions then you'll crack any SWE interview. The problem is, as soon as you start working you forget about all this BS and nobody cares.
Which is why the interview process is broken. We already go through that painful exercise in college. Companies should stop being lazy and look for a better solution to double check that you really went to college. They could focus on a lot of other things in 45 minutes, projects, behavior, culture fit, etc.
Which is why the interview process is broken. We already go through that painful exercise in college. Companies should stop being lazy and look for a better solution to double check that you really went to college. They could focus on a lot of other things in 45 minutes, projects, behavior, culture fit, etc.
The interview process at many software companies is weighted towards fresh grads who display a "genius factor", i.e. are quick to answer typical engineering problems with the best possible academic solution. Simple as that.
The trick isn't to interview well. It helps! But the trick is to have a great referral into the companies.
CareerCup is good, but it has so much content with no structure, so you feel overwhelmed obviously.
Try leetcode if you haven't already, start with topic wise easy questions, then medium and then difficult, participate in the message boards discussions about problems, you need time and discipline, that's all.
Try leetcode if you haven't already, start with topic wise easy questions, then medium and then difficult, participate in the message boards discussions about problems, you need time and discipline, that's all.
Consider using something like interviewing.io to practice interviews with real people that can give you feedback in real-time on how you're doing. Some other people in this thread have offered some other choices, like HackerRank and Code Kata and so on. All good choices for practicing algorithms. Becoming good at interviewing for technical positions is a TOTALLY different skill set than being a good programmer, so just keep practicing and eventually you'll get better.
Once you're more confident, consider using something like Triplebyte or interviewing.io to do your tech challenges and hopefully skip past some of the earlier tech challenges.
For what it's worth, as a hiring manager I would also say that, generally speaking, I'm not interested in whether you got the "correct" answer in 45 minutes, and I'm certainly not interested in perfection in 45 minutes. Don't worry about being perfect. Just worry about being competent. I'm far more interested in the bigger picture. Things like:
1) Can you write code in the first place? The basics should be easy for you.
2) Are you familiar with the language you're writing? You shouldn't have to look up how to sort an array or how to declare a function, for example, and your code should be clean and readable.
3) Can you properly assess the problem and begin working on a solution? Take a moment to think about it. Ask follow-up questions if necessary. I always try to repeat the challenge back in my own words, just to make sure I understand what's expected.
4) Is your solution heading in the right direction? If not, you either don't know what you're doing or I didn't explain the challenge well enough.
5) Can you identify and fix edge cases? Usually the problem I give you will have some reasonably obvious edge-cases, like the popular FizzBuzz test has.
Trust me. As an interviewer, I know you're nervous. I don't expect perfection. I expect thoughtfulness, progress, and adaptability. I expect you to think through a problem, make progress toward a solution, and be able to make changes as necessary to fix edge cases and unexpected problems. That's all. (ha.)
IMO, if your interviewer is fixated on whether it's "perfect" or whether you got the exact right answer, they're not good interviewers and perhaps you shouldn't want to work with them in the first place. In fact, an ideal programming challenge should have multiple solutions (e.g., there are many ways to sort a list). The challenge should be more about figuring out how you think than whether you can add 2+2.
Also, keep in mind that the interview works both ways: you should be interviewing them just as much as they are interviewing you. Every question you're being asked is a question you can ask them. If they don't think you're doing a good job, they won't hire you, and if you don't think they're doing a good job, you don't have to work there. Keep in mind that the bare minimum for a programming job is... programming. If that's all they focus on during an interview, they're missing out on everything else you can bring to the table. Imagine if the only question they asked truck drivers was "Can you drive?" or the only question they ask a journalist is "Can you write?"
Good luck!
Once you're more confident, consider using something like Triplebyte or interviewing.io to do your tech challenges and hopefully skip past some of the earlier tech challenges.
For what it's worth, as a hiring manager I would also say that, generally speaking, I'm not interested in whether you got the "correct" answer in 45 minutes, and I'm certainly not interested in perfection in 45 minutes. Don't worry about being perfect. Just worry about being competent. I'm far more interested in the bigger picture. Things like:
1) Can you write code in the first place? The basics should be easy for you.
2) Are you familiar with the language you're writing? You shouldn't have to look up how to sort an array or how to declare a function, for example, and your code should be clean and readable.
3) Can you properly assess the problem and begin working on a solution? Take a moment to think about it. Ask follow-up questions if necessary. I always try to repeat the challenge back in my own words, just to make sure I understand what's expected.
4) Is your solution heading in the right direction? If not, you either don't know what you're doing or I didn't explain the challenge well enough.
5) Can you identify and fix edge cases? Usually the problem I give you will have some reasonably obvious edge-cases, like the popular FizzBuzz test has.
Trust me. As an interviewer, I know you're nervous. I don't expect perfection. I expect thoughtfulness, progress, and adaptability. I expect you to think through a problem, make progress toward a solution, and be able to make changes as necessary to fix edge cases and unexpected problems. That's all. (ha.)
IMO, if your interviewer is fixated on whether it's "perfect" or whether you got the exact right answer, they're not good interviewers and perhaps you shouldn't want to work with them in the first place. In fact, an ideal programming challenge should have multiple solutions (e.g., there are many ways to sort a list). The challenge should be more about figuring out how you think than whether you can add 2+2.
Also, keep in mind that the interview works both ways: you should be interviewing them just as much as they are interviewing you. Every question you're being asked is a question you can ask them. If they don't think you're doing a good job, they won't hire you, and if you don't think they're doing a good job, you don't have to work there. Keep in mind that the bare minimum for a programming job is... programming. If that's all they focus on during an interview, they're missing out on everything else you can bring to the table. Imagine if the only question they asked truck drivers was "Can you drive?" or the only question they ask a journalist is "Can you write?"
Good luck!
Some of the problem solving/algorithm questions that are being asked, I find it very hard to figure out the perfect solution leave alone coming up with a solution in the 45min window one is provided. The crazy dp/graph problems that get asked are something I find hard to grapple with.
I am in no way trying to be critical of the interview processes but actually respect them!!! and makes me feel the folks working there are super human.
This is making me very miserable and I am losing my sleep over this and this is effecting my daily job as well; Anyways just wanted to vent out the steam and look for ways other ppl here coped with similar situations and how to be successful.
P.S: IMO, going thru Career Cup and other interview prep material is helpful but awfully falls short of the kind of questions being asked! In fact sometimes I want to walk away from the interviews unless I am in the range of decent ranking topcoder and that makes me question the whole cs career has come to be i.e. does one have to be an elite competition level coder and only then have a fair chance to work in the top companies and whether this really translates to great software contribution.