Ask HN: What have the s/w interviews evolved to :(
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.
18 comments
[ 2.5 ms ] story [ 46.1 ms ] threadAlso, 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).
Don't worry so much. Keep preparing by focusing on small bite size chunks you can master. Then attempt some interviews.
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.
https://github.com/jwasham/coding-interview-university
It's pretty in depth and extremely popular (44k stars). Hope it helps.
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.
Thanks for the advice, gives me something to think about as I was preparing to study for a few months to get into a big 4.
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.
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.
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!
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.