Ask HN: What do you do if you can't pass technical interviews?
"This was a tough decision. We enjoyed talking with you and saw strengths through various parts of the interview, in particular on the [design discussion] and [list traversal] problems. However we made the final decision because we didn't see the overall level of coding we're looking for, especially during the [interactive terminal-based application] problem. The rate of progress on this problem wasn't as fast as we'd hoped and we weren't able to build a nice, generic solution within the time available. There was also a fair amount of confusion on the out of bounds issue, which we feel was the type of bug that would have been caught faster by a more experienced engineer."
This is a pattern: when I'm given a trivial code problem or a design problem, I tend to do well, but live coding and whiteboards are trouble because I frequently make tiny mistakes (always unrelated to my understanding of the underlying algorithm). I know this about myself as a coder, which is why I obsessively test my own code to catch my own errors.
But, especially under stress, these mistakes are continuing to cost me job opportunities. I've purchased cracking the coding interview, programming interviews exposed, and I've done scores of practise questions online at sites like HackerRank, but I keep hearing the same thing back: "You're clearly smart, but you didn't do well on the whiteboard, so fuck off." I've heard some variation of that nearly a dozen times in the past six months.
I'm at my wits end. I'm consumed with self doubt (which doesn't help in the interviews). I'm depressed, I don't know what is wrong with me, and I don't know what more I can do.
Should I just burn my CS degree and get a job a burger king? At the very least the interview would be shorter.
40 comments
[ 3.8 ms ] story [ 99.1 ms ] threadTry these tips.
http://kelukelu.me/interview/prep.html
The good news is that interview performance is not a reflection of how you’ll perform at your job. Think about it – how representative are the interview situations you’ve described? Jobs aren’t like that.
Don’t start flipping burgers just yet. There’s good advice on this thread – two basic ideas.
First, you can get better at the “Google/Facebook/Twitter” whiteboard interview by practice and hard work. No matter how much you think you suck, you can get better.
Second, there are thousands of companies with software jobs all of over the US that don’t use the whiteboard approach to interviewing. You have to look for them. They might not be software companies per se, but have developer groups that provide useful line-of-business software that make their internal users happy.
Don’t give up. You can do it.
A seriously underrated skill (which you can practice) is keeping calm when you make a mistake and reasoning out loud, under pressure. When you hear yourself saying, "Oh wait, that won't work because..." is when you know you're on the right track.
[I run http://InterviewKickstart.com for a living]
Following are some very common mistakes people make when preparing for technical interviews.
1. They code, but they don't invite feedback on their code. Nor do they compare their code with other people's code. So they solve problems, but they never know if their solution was sufficient. They don't get better, despite solving problems.
Avoid this mistake: When you prep on leetcode.com or some such, read other people's solutions line by line, understand and compare. Yes, that takes time.
2. They don't do mock interviews with practicing engineers
Avoid this mistake: Find a friend or mentor who works at a brand name company and do a strictly graded mock interview or two (or more). That will reveal a lot of things your coding practice won't. You could also practice with fellow learners (interview each other), which will help lower the stress in actual interviews (though won't be as useful as doing it with a practicing engineer).
3. They practice very few problems
Avoid this mistake: If you're coming from a top-20 4-year CS program, or you have an IQ of 130+, you won't need a lot of practice. But for everyone else, don't stop until you've practiced at least about 150 problems. Anything less won't help and worse, might give you false confidence.
And when you're in the interview, try asking the interviewer if you can solve the same problem on your computer or on a piece of paper. You'll be surprised how many people will let you do it.
HTH.
(2) That said, do take what they're saying seriously, but feel free also to take it with a grain of salt. Generally, interviewers greatly underestimate the effects of stress (the fact that interviews are typically quite dreadful experiences for many candidates) and the sheer cognitive overload of parsing the problem statement, explaining your thought process to a person you don't know very well (and who may be judging you quite harshly) while you are solving the problem, and crucially, guessing the level of optimization your interviewer is secretly looking for (e.g. maintainability versus quick-and-dirty) have on candidate performance.
(1) Apply to companies that aren't software companies. I was once interviewed by a chemist at DuPont.
(2) If you're not in love with your location, move away from the big tech hubs.
I suspect hiring standards are much lower outside SF/Seattle/Boston/Denver/Austin/etc. There are so few people graduating from CS programs (and so few of them competent developers), that they can't be so picky in most of the country, far away from the top schools.
During and at the end of my college career (CS as well), I interviewed at 10-15 companies or so for developer positions. Not a single interviewer did a live coding test. Only one wanted to go over the work samples I voluntarily provided with my resume. I got offers from all but a few of those companies. I think the reason is because I'm in suburban Pennsylvania, not San Francisco.
I did apply for a job at Google once while in grad school. Did two of those algorithm phone screens. I did alright, but I hated being tested under pressure like that. If I were to look for a job, I'd rule out the software companies and tech startups that interview like that. They're not the only option.
They'll also make you clone products from companies like Slack and question you why the performance isn't as good, when they've already allocated a budget of $10,000.
Some of the best jobs I've had have come from extremely non-technical interviews.
They really took advantage.
I have the same problem. It's a numbers game. You just have to interview at 8-12 places until either a.) you find people who understand you or b.) you find a company with lax hiring processes.
Here's a review of my 2013 job search (all rejections): https://matt.sh/searching-2013
If you set lower expectations people are more likely to be impressed.
If you set higher expectations, people are more likely to be underwhelmed.
A few things will happen. 1) You'll get good at interviews. 2) You'll stop caring so much about failing interviews which will combat your anxiety. 3) You'll find there is a wider range of jobs available to software engineers than the kinds you've seen so far.
Avoid companies with stupid hiring policies.
It seems that these guys want you to code like they do, and they'll eventually find someone "close enough" - eventually. After wasting many man hours of interview time. You don't want to work with these guys.
You want to find a company that appreciates you for the developer you are, which appears to be someone who knows his own limitations and has ways of mitigating those limitations.
You have no idea how much that is worth. Simple mistakes like forgetting api parameters, the occasional typo and off-by one errors gets all of us. Especially in a high stress environment like an interview.
I feel that a common "you're not technical enough" to be a lazy excuse, or to replace a poorer one such as "your face didn't fit", you are too bright and will show us up, or "we liked another candidate better".
I feel your pain with the interview process. I'm a contractor and I hear lots of bullsh*t all the time from agencies and recruiters. Stick with it, and do a side project that proves to yourself that you're worth it.
sockpuppet account for obvious reasons.
Agree with this. Sounds ridiculous. What other profession has to prove their skills in such a way in a job interview?
Anything else is hiring people on their ability to talk about how they might do the job, rather than how they actually would.
Doing actual interviews is by far the best way to practice interviewing. And I find that taking interviews less seriously actually helps me keep my composure during interviews and allows me to perform much better than back when I first started interviewing, when I was treating each one like some kind of a once-in-a-lifetime opportunity and stressing myself out unnecessarily.
Software is a seller's market right now, and there's no shortage of companies that are looking for great developers. As long as you keep interviewing, you'll keep getting better at interviewing, and eventually you'll become good enough, or get lucky enough, to land an offer that you like.
P.S. I really like the way TripleByte does their technical interviews, offering each candidate a choice between a live-coding track and a project track. Unfortunately, having a choice in the interview style isn't a very common hiring practice, even among TripleByte's own clients, who tend to then turn around to grill TripleByte-referred candidates on algorithms in live-coding sessions anyways.
Does anyone know of some kind of a job board that allows filtering by the availability of a take-home project as an alternative to the traditional interview?
Eventually, I want to stream myself working on side projects, so I can say to companies: If you want to see what I've worked on, take a look at my GitHub/LinkedIn/Website/Resume. If you want to see how I work, take a look at my streams. If you like what you see, feel free to contact me to talk about opportunities and make me an offer. If I like your offer, I'd be willing fly over and meet with your team to see if we can get along, but the moment you start trying to grill me on my ability to solve obscure algorithms and data structure problems under pressure, I'm outta there.
It sounds like you're trying out for more senior development positions. You're not being dismissed out of hand, but they are relying on the white-boarding.
We in the industry know that CS programs don't consistently crank out people with superb coding skills. Those people are almost always "self-made" programmers (who got their CS degrees too).
> In fact it would make less sense to ask a senior programmer whiteboard questions.
Indeed, but he or she isn't one, right?
Look at some of the comments: There was also a fair amount of confusion on the out of bounds issue, which we feel was the type of bug that would have been caught faster by a more experienced engineer.
Basically the message is we are looking for a more experienced engineer for this position and not you suck at white-boarding, go away!
But they know about the level of experience from the resume. So why bother interviewing at all? Probably they are somewhat willing to overlook lack of documented experience, in case a "superstar" programmer shows up. You know, one of those who has been programming since age six, and whose CS degree is just a paper with a stamp so their resume isn't tossed aside.
(Or it could just be a string of bad luck, or the way the job market is in the area. Maybe everyone is grilling new grads to find superstar programmers.)
https://medium.com/@thatboiwill/levels-of-technical-intervie...
Get to the point where you are decent at level 4 interviews and you are a shoe in for 80% - 85% of tech companies anywhere.
If you can master level 4 and harder than you have a strong fighting chance for even the toughest companies to interview at.
Another thing to note you only really get level 3 and 4 interviews with top tier tech companies generally in the Silicon Valley area and maybe started by or around people from [insert college with top tier CS program].
Having deep knowledge of your specific domain (web development, mobile development, etc.) and basic data structures and algorithms (up to Level 2) will get you offers in any tertiary Tech scene i.e. Austin, Texas or Atlanta, Ga.
Source: I have gotten offers in both of these areas with just that level of knowledge.
But if you want to make sure you can get a job in the valley you got some work cut out for you. It aint the best for no reason.
Edit: I'll leave you with one more thing.
One of the authors of Programming Interviews Exposed them self was rejected by Google his first time...
https://www.quora.com/I-am-a-software-engineer-with-20+-year...
let that sink in.
I won't mention a certain big one, but they just test to make sure your brain grasps the concept of pointers. They do pay upscale salary and are in one of the major startup hubs.
I'd say Level 2 is the optimum to be comfortable in for a degree level if you do a lot of tough stuff. Level 3 if you're in something more niche like optimizations. A huge, listed company like Google or Microsoft might do Level 4, only because they have the money to solve problems that give a 0.01% improvement and want to maintain that competitive edge.
There's a reason for this - the best programmers have an abundance of job offers. So it's good not to annoy the candidate too much or to stretch out the interview process very long.
A few examples of my current environment (which I love, I'm a private-sector employee currently contracted to a state government agency, but some here would absolutely hate it):
- The entire stack is .Net. I like .Net so this is fine for me but some people would hate this.
- New code is regularly written in VB. We are free to use C# when we want, but we can't use F# (nobody at the state knows it), and there are several state developers who don't know C# and refuse to learn it to the point of outright hostility.
- New code is also written in Fortran because reasons. The floor I'm on alone probably has about $550k/yr in payroll dedicated solely to maintaining existing mainframe applications.
- No write access to the test db schema. Have a change that requires a database schema change? Send it over to the DBAs and it'll show up in a day or three. This is not just because I'm a contractor, the DBAs are the only ones with this access.
- 8 hours (including lunch) and out, on the dot. This is great for work-life balance, but when everyone else works 7-3 (or earlier) the office is a ghost town for several hours every day.
- The level of bureaucracy is staggering. I mean it regularly gets to the point where it seems like a caricature. Make something ridiculous up and it's probably happened here.
Some people thrive in this environment - it hasn't bothered me the last few years, but I know a lot of HN's target audience would not be caught dead working for a state agency.
And everything you said regarding consulting companies is spot on in my experience :)
Maybe you should reconsider how you apply.
Your goal should be convincing your employer that you're either a great coder or have the potential to be a superstar coder.
I have interviewed for a lot of jobs, and didn't require a technical interview for any of them. You don't have to win the interview!
I first got over it with a very strong recommendation and a top degree. They gave me a technical test and I convinced them that they should just offer me 3 months probation at half salary, because that would be a better test.
Later on by showcasing projects and convincing the employer that I was the expert. An interview would be like "Have you used Fragments?" and I'd just hit them back with every pro and con and horror stories of using Fragments. Then they give an offer without further tests.
You should think of yourself as a hacker, trying to get past the door. Instead of bringing every kind of key with you, be creative and see if you can go through the windows.
Do whatever it takes to avoid those whiteboard interviews! Convince them you're the right person before you get to that stage!
However, do remember that in order to convince others that you're a great coder, you have to convince yourself. Code can be a very emotional thing, like writing. If you don't believe in yourself, you may end up worse at it.
Neah !! Jobs are not about the degree only, still having a degree always adds up. Try half a dozen other companies. This response is typical of small size startup who instead of inviting you for a drink invite you to an interview with their two person team. I was rejected by three companies (2+ engineers) before the present company (15+ engineers) made me an offer. It wasn't even a coding interview at all, the Sr. Engineer wanted to have a conversation for a couple of minutes.