Ask HN: How to not fail on coding interview questions?
I joined my company as an intern ~5 years ago & when I interviewed for the position I didn't have to solve any white-board style interview questions etc., since it was an un-paid internship. After a few months I had demonstrated my ability to write code they made me an offer.
When I now casually look around and apply for mid-to-senior level positions I cannot seem to get past phone (coding interview) part, that involves solving some basic algorithm on collabedit. I get nervous and given I need to solve (perhaps a simple) problem in an optimal/sub-optimal way in 30 minutes, my brain sort of shuts off and I cannot arrive at a clean solution, let alone solve the problem end-to-end.
I'm respected within the company, if you were to ask any colleague I have worked with whether I can write clean testable code that solves real business problems, everyone would attest that I absolutely can.
How do you create that environment of - "Coding under pressure and someone looking at your code while you're trying to think of how to solve a problem and your brain is thinking about everything other than a problem itself"???
One idea is to just keep applying and failing until I become immune to it. But each failure kind of brings me down, and makes me think that I'm a bad engineer.
Last thing I want to mention is that I don't blame the process itself. I think white-board style questions eliminate a lot of bad candidates. I know that the process has to be rigorous because those jobs pay well. But there's also extreme examples like the inventor of homebrew that got rejected by google because he couldn't reverse a binary tree.
128 comments
[ 3.1 ms ] story [ 185 ms ] thread1. Pick up leetcode (or whatever rocks ur boat).
2. Do a lot easy questions and understand the pattern.
3. Do medium level questions and understand the pattern.
4 If you are aiming for Big 4 do Hard.
Coding interviews is all about finding the pattern and applying it. Only way to be good at it is practice. Don't give interviews without some practice.
- For that authentic whiteboard performance feeling ask a friend to play the role of an interviewer.
- Maybe set up a local meet up to help people practice this interview skill
Indeed. Many people (including myself) find it hard to reconcile our lived experiences with the hysterical claims in the press about a desperate skills shortage.
To the OP: if it helps, understand that these kinds of interviews and how you do on them are in no way reflective of your skills as an engineer or your worth as a human being. You’re just being hazed, by someone you probably wouldn’t want to work with anyway. Keep at it, and eventually you will get to speak to someone who is basically normal that you can have a real conversation with.
They have collectively adopted a strategy of constant moaning because they always want more and better candidates for lower prices.
How long would it take you to merge two sorted arrays on a computer without internet access and no one looking?
I think the general problem is that I don't deal with such low-level problems on a daily basis.
I can write multi-threaded Kafka consumer app that processes thousands events per second and applies some basic ETL on them, add end-to-end integration test for it in <8 hours.
But it may take me ~1/8th of that time to write a low-level (quick) sort algorithm.
For example, there is almost no engineering question on the planet that people straightforwardly solve from first principles in 30 minutes, unless it’s totally shallow based on memorization or childish rote practice — and has virtually zero relationship to how they would ever solve any problem at work.
But there are all kinds of insanely hard problems that people can give you beautiful solutions for in 10-20 hours, and involve an entirely different way of working than anything possibly representable in 30 minutes.
Engineering and math questions just require burn-in and rumination, tinkering, stop & get a cup of tea, take a walk, tinker more. They just do.
Seeing “how someone thinks” in an artificial 30-60 minute session only tests a completely separate and mostly unnecessary skill set for passing tests and memorizing things.
Totally agree. However, what's a good alternative? A company can't hire everyone for a trial week, and a candidate can't work a trial week for every company. It's really hard to design a hiring process that is efficient for both parties plus resistant to abuse.
You are right that interviewers won’t get much more than an hour to judge a candidate. So why waste it on information that fundamentally can’t be helpful (like whiteboard trivia)?
Instead, first jump right into a domain where the candidate should already be comfortable and technical — their past work projects — and go from there, probing for more technical depth.
The idea that it somehow makes more sense to use limited time by wholesale discounting & ignoring the person’s previous work history in favor of having them write a sorting algorithm in CoderPad is totally indefensible.
- the interview questions are invariably things that have already been solved and abstracted away.
- as an experienced programmer it's not your job to solve problems like that. The work you do is more complex and requires sleeping on it, doing research, trying stuff out, talking to people. THAT'S the stuff you're good at, and what you are hired for.
- as a result of doing that increasingly complex work you get out of touch with the simple problems, even worse you develop an instinctive internal block against doing it, you develop a 'spider-sense' for what NOT to waste your time on.
- this gets into my way when doing coding interviews.
- it also makes it harder for me to spend time practicing. I have a family, other stuff to do outside of work, do I need to spend many evenings to practice on things I will only need during coding interviews and will never need afterwards?
The process for hiring experienced engineers is completely broken.
PS: I also failed much easier interviews at CrowdStrike and SourceGraph so maybe I just suck at being interviewed in a way that's not clear to me. It really takes a toll on your confidence though.
1 - https://www.pramp.com/
2 - https://github.com/andreis/interview
3 - https://github.com/jwasham/coding-interview-university
Try not to take things personally, it could have just been a bot. https://news.ycombinator.com/item?id=17334552
I have to ask: how do you tell a good process from a bad one?
this doesn't mean the tests and problems need to be easy or an easy pass, they can be just as hard or even harder to solve, depending on the problems you guys face, i often hear people defending the drills because "people just want a for loop problem and fizzbuzz and easy pass", which is not the case for many seniors engineers that would like a decent challenge related to what the company works on.
Am I wrong to say that he as one person is in no position to change the process?
What I mean is that his choices are either to just go through the hoops and reject to the drills because they are not representative for his ability, or accept this testing but not stamp negative results on his quality as a person or developer.
In the end he is not defending the process too strongly; is seems to me that he simply wants a formula to navigate it.
One of the most effective ways I've found to deal with this is be open. Say, "Yeah, I suffer a bit from anxiety and interviews in particular are difficult. Do you have a take home interview? I can easily commit to git in near real time if you want a blockchain-quality log of my process, and I'm happy to review it with an engineer." I have gotten a surprising number of takes on this (and in general I annihilate these).
As a bolster to your confidence, try not to take these too seriously as an indicator of your personal skill. Having worked a bit on my current and past employer's interview process, tbh an awful lot of orgs have questions that are more like riddles than actual coding exercises; they often have a simple solution you have to "know" otherwise the problem is excruciating and every solution is obviously bad. Examples of this include "chocolate bar" division problems, skyline problems, or rainfall problems. All of them are bad examples.
We also enjoy a sellers market for many tech skills right now. In such a market, interviews can also be information for you to save your time not proceeding. This feels very strange for people normalized to the creepy feudal culture of tech where you align yourself with a company body and soul and only state laws allows you to escape their clutches, but it's pretty powerful. If an interview seems deliberately excruciating, just say, "I've seen all I need to see. Thanks for your time, but I don't think you're a good fit for what I'm looking for in an employer."
Finally, it's also worth remembering that just modest reading in PL, CS and database literature written in the last 10 years often gives you ammunition to completely break down these questions. The folks that structure and ask these only seldom actually their theoretical basis. I've managed to break out of ugly and tedious interview questions by flipping the conversation to something I do know well and am confident speaking to, like modern O(n) sorts (discrimination, american flag), wavelet trees, recursion schemes, CRDTs and strategies for gossip protocols. Appeal to their greed and interest and show them that you DO know things, you just may not know THIS thing RIGHT NOW.
At one point I interviewed at a couple big ones and got into FB, where I also did a fair amount of interviewing. My tips:
1. Accept it's a numbers game; apply to N, and you'll get an offer from one. I got rejected by Google and Spotify, got an offer from FB. Some people do better and get more offers, but I know I'm a nervous type during interviews and under-perform. It's okay, it's a First World Problem, just apply to more companies. I think most people I know who work at G/FB/Spotify got rejected be a few others.
2. Practice a lot. There are 100s of questions available online. If you're smart, you will pick up the patterns / tricks you can use to solve the coding questions. Eg. when the obvious solution is O(n^2), usually there is a more efficient one involving using a hashmap to do a lookup.
If you think the problems you find online are too hard or stupid (eg. "who cares about implementing an LRU cache"), then read up on core CS topics to appreciate the subject matter.
If you think it's not worth to invest the time to beef up for it, then (i) it is, you can learn a lot at the big ones (ii) you can see how hiring candidates who think it's worth it is better for the company.
3. Think of it as a good thing. You brush up on your core skills (LRU cache), and it probably forces/incentivizes you to look at some recent developments in your sub-field so you feel prepared and can comment on it if it comes up. Although I don't enjoy the interview itself, I find the preparation to be a very fun time, reminds me of the good old days at University; a good break from the usual crunch of the job, which usually leads to rusting of core skills and specializes you in the tools the team/company happens to use.
4. At the big companies, on the initial loops where you solve the shortish interviewing questions, usually they just want you to solve the problem, not talk too much. I found some candidates think they have to talk a lot and relate the problem to their work, but that's not the case. Don't say "At work I'd just use a library for this." That's obvious, that's not the point of the interview. In the initial screens the interviewer just wants you to supply a solution, explain it, and move on. So just do that. Be efficient.
5. Getting rejected feels like shit but doesn't say much about you. It just means you had a bad day, or you were nervous. Or maybe the interviewer actually did a good job of assessing your skills, and you're not a good fit for the team/org that was hiring. I've seen lots of people get rejected from FB where I thought any smaller company would _kill_ to get them onboard, but FB didn't accept them for some weird reason, which at a high level is sth like "Would they be successful here at this role X, in team Y or Z, _given how this role works here_? Maybe, but the hiring manager isn't convinced enough". It's a bit frustrating, but it works for the company: the people who get through the filter are very smart&good, work together very well and efficiently, altogether create products Bs of people use (good for everybody), creates Bs of revenues and Bs of profits. So it works, it's not going to change. Play the game.
1. Others already recommended to practice solving problems on LeetCode;
2. While solving these problems don't spend too much time if you got stuck, look for answer or discussion after hour or two;
3. If you feel weak on some topic (e.g. dynamic programming), try to read up related material, lecture notes, familiarize yourself with classical problems on this topic;
4. Even if you solved problem, look for other answers. You often be surprised how much shorter and concise solution can be;
5. Read some books on algorithms like Skiena or Papadimitriou. I don't recommend you to read Knuth or CLRS unless you have strong math background. Skiena or Papadimitriou are much easier to read for beginner. Also, separately, I do recommend the book - Programming Pearls by Bentley;
6. Once you practised for two months or more, start taking mock interviews on Gainlo;
7. Enjoy algorithms and solving programming puzzles. Enjoying algorithms is a must because if you really want to master it to the Google interview level, it may take years;
The Golden Rule: When in doubt, use a hashmap. Almost all code challenges are about finding an algorithm or datastructure to fit the problem/solution. Many of them are solvable efficiently via a hashmap.
Preparation
- Practice on a whiteboard
- Do mock interviews with the most skilled people you can find and get feedback! This is critical to glean any information about how you're actually doing! I could volunteer to do that for you remotely if you like. Send me your contact info. I'm a distributed systems guy but could walk you through some problems and tell you how you're doing with whatever you're using for tech very likely still. Drop a note on how to connect if you're comfortable.
- Take an algorithms course before you interview. (The princeton sedgewick one is great and easy to grokk. see coursera: https://www.coursera.org/learn/algorithms-part1)
During:
- Write tests for your code during the interview to demonstrate production quality code.
Especially if interviewing for eg Google. They don't give super tricky problems in every interviews (eg during phone screen) - focus on writing good code that is tested and will compile and run after the interview, not writing mediocre code fast.
- It's okay to incrementally improve your solution. Talk through your thinking. Start at the naive solution and then work toward optimal. Eg give two lists, find any number from list a sums to any number from list b. To start, you could write a couple quick tests on the board to make sure you understand the problem. Then you could reason about solutions - say you could use nested for loops. That's O(n squared) which isn't suitable as a solution. So you ask if the data is sorted. If they say no, you can sort lists, iterate through one and binary search on the larger list to get to an asymptotically linearithmic solution. That's suitable so you write that fairly swiftly. To improve you discover you only need to sort one list so you change the solution to only sort the larger one and iterate through the smaller. If there is extra time you might start to reason about how you can move toward a linear solution. Remember I said the golden rule is use a hashmap? Why don't you make a hashmap out of one of the lists and iterate through the other one to find values in the map? Don't just sit there and take it away to the corner and try to solve it.
God Mode: - WAYYYY before you take the interview: Stop using an IDE at work if you're working in a statically typed language. Use emacs, or vscode or whatever you fancy. Moving to emacs made my brain learn the qualities of the language at an intimate level faster than anything else. You check the docs if you forget the api until you stop forgetting the API. It slows you down a bit at first so it's an investment but whatever - tack 25% on your estimates for a few weeks. You can revert to the IDE for larger refactoring work.
Don’t waste time on leetcode / HackerRank / etc. It’s not useful. Practice programming by writing code you enjoy, solving problems you are interested in. You’ll be naturally productive at what you enjoy, and just build on that.
Anybody giving advice that comes from the point of view that these interview techniques have any legitimacy is probably just someone who happens to randomly be good at or enjoys interview trivia, and so their opinion is clouded by a selection bias effect. This is especially true on Hacker News.
They do well on interviews, not because their study methods work better and not because they are better at engineering or more effective in a job. They are not. They just benefit randomly from a system set up to reward traits they happen to have already and find easy. Their ideas worked for them but are very unlikely to work for you.
Seriously, just do a lot of interviews, fail a lot, and be fine with it. It’s easier said than done, but it’s necessary for you to weed out the places with foolish interview practices and find the ones which are more holistic, human productivity focused, flexible, etc.
I happen to be good at quickly working through algorithms, mostly in machine learning and search data structures, but in general software too.
If anyone tries to hire me because of that quick “see how you think” whiteboard nonsense, I just walk away. They are doing it wrong; life’s too short.
Email me at the link on my profile if you'd like a list of our open positions.
The alternative is finding companies that do not ask these types of interview questions. The only big company I know that doesn't ask those types of questions is Stripe but I'm sure there are plenty of others though they may not be 100% what you are looking for.
HN has rehashed this debate plenty, but I don't think you should necessarily see this as an example of a dramatic failure of the Google SWE interview process.
Homebrew became a success due to great vision and execution, not because it solved a challenging technical problem. Howell seems like a great guy who would probably make a great senior developer, founder or PM at any company that aims to solve customer needs.
Google's focus, however, is on hiring SWEs that can solve uniquely complex and difficult technical problems. The merits of such a narrow focus is obviously up for debate, but if that is to be your goal, this hiring decision aligns with it.
I think that's kinda just marketing TBH. How else do you explain things like their habit of overhauling the graphics while removing functionality on many of their popular offerings? The last update of Google News looked a lot nicer but removed all user customization of the news feed - you can't even filter out sources any more.
I mean, maybe there are a lot of super-clever SWEs at google who are bored and frustrated with everyday consumer-centric product development and so do a terrible job at it until they're rotated onto something more interesting. I can't think of any other reason to inflict such a product on the public.
I can't speak to any specific instances, but generally when this happens it's because the front-end needed replacing, and not because they had to give up on supporting the functionality on the backend.
For example, the front-end may have been mobile or offline hostile, while the new one works great with both but only reimplemented 80% of the massive feature set that the old UI accumulated.
It sucks if you primarily used the site on desktop and heavily leveraged the missing 20%, but I can see the value in such a trade-off.
Huh? Isn't all difficulty in software complexity management? Isn't writing a package manager a sufficient demonstration of that? What's a "difficult technical problem"?
Isn't solving customer needs through managing technical complexity what Google should be hiring for, full stop?
I'm actually confused at the philosophy here.
Another way to think about it is that Google wants SWEs who can also act like researchers (e.g. PhD students).
He joined Apple after that and was interviewed on the Changelog not long after he left.
Honestly he sounds like a really difficult dude to work with.
My unsolicited advice is to:
A. Come to terms with the fact that there has been a shift in expectations from employers. Understand that to get the really plum jobs it will require a lot of dedication to get to where you need to be interview performance wise.
B. If you are really rusty, start off with Firecode.io. It provides a more structured approach to studying these interview questions. Once you feel comfortable with the questions there then you can go for Leetcode.
C. Go to interviewing.io and pramp and practice with actual engineers. This will allow you to work on your communication skills. A big part of interviews is just basic communication. You could be rock solid with your algorithms but if you still can't communicate what you are thinking to interviewers in an effective manner you still won't pass the screen.
D. It's not a particularly popular corner of the internet but reddit.com/r/cscareerquestions has a lot of good advice on how you can improve your interview skills. It's also a good place to get a sense of how interviews are structured, how people typically prepare, expectations etc. It's skewed towards getting jobs at the FAANG type of companies but the good advice you will get in the sub is pretty solid and will help regardless of the direction you want to go.
Overall, try not to be too hard on yourself. Technical interviews are an inherently noisy screening tool, and a lot of great engineers fall through the cracks. Preparing for these interviews just like you would prepare for any other important assessment will help you in being more competitive.
> good advice
That place is literally college confidential for CS students. It really doesn't help anyone when the people who are giving job advice haven't even left school yet.
If they don’t give you the business logic, then you’ll need to practice, practice, practice, but you honestly should be able of reasoning you through a piece of businesslogic and turning it into pseudo code.
Aside from that, it’s a terrible test for hiring people exactly because you, can, memorize it through practice. But American hiring processes are funny like that.
Go to networking events and meet-ups. Offer to give mock interviews to people more junior than you. Have coffee with founders to give them feedback on their ideas. Anything that puts you in unstructured conversation with strangers will make you more comfortable and confident in an interview. You get better at reading people and start to see things from both sides.
Being a software engineer often mainly only requires communicating with a mostly unchanging group of people. Interviewing well requires being able to communicate efficiently with someone you just met. During an interview if you can direct less time and mental energy at just communicating you'll have more for demonstrating that you'll be able to do the job.
https://github.com/poteto/hiring-without-whiteboards
I signed for the role of Senior Product Engineer just today in a pretty fast growing startup company.