Ask HN: What do you do if you can't pass technical interviews?

I have a bit of a different take on this.

(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.

You'd be surprised how bad it can be working as a developer at non-tech companies. AD-agencies where the projects might be 90% tech even end up being shitty workplaces. You're a second class citizen amongst copy-writers, SCRUM-EXPERT project managers and UX-Gurus who make keynotes of 2 or 3 frames for the long parallax intro animation of 7 pages.

I second this. At tech companies, you'll be treated with a degree of respect. With many non-tech companies, you can be referred to as "the guys who spend the money that the sales team makes".

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.

Agreed, but the reverse can also be true. HR companies for example are infinitely better at working with employees (and treating them as humans/individuals) than tech companies.

Some of the best jobs I've had have come from extremely non-technical interviews.

I am not sure what you mean with "HR companies" but HR in general isn't there for you, it's there for the company. An ex-colleague of mine had to experience that the hard way. She's alright now, but she felt horrible for a couple of months.

They really took advantage.

(1) Be genuinely thankful that you got the level of detailed feedback that you did. Many employers love to basically go dark on candidates after they decide they don't meet the bar (or don't make the unanimous team vote, whatever). To get either a simple "Thank you, but No" with no detailed feedback -- or, quite often, no follow-up of any kind at all; just crickets -- isn't the exception; it's almost become the general rule.

(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.

When you don't pass technical interviews, you make a resolve to practice more and pass them.

[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.

Should I just burn my CS degree and get a job a burger king?

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

Here's some advice.

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.

FYI my understanding is that a sockpuppet has a connotation of an alternate account used to create a false sense of consensus. Generally people call anonymous accounts "throwaway".

> Avoid companies with stupid hiring policies.

Agree with this. Sounds ridiculous. What other profession has to prove their skills in such a way in a job interview?

At least where I work we use a similar process for all roles. Customer support do mock phone calls and emails to customers, logistics people plan delivery routes, and marketers at least talk about how they'd develop and measure a campaign.

Anything else is hiring people on their ability to talk about how they might do the job, rather than how they actually would.

Stop prepping and putting all your hopes on each interview. Start getting out there and doing real interviews for practice. Apply for software engineering positions everywhere. Even places you have zero interest in working. See what different kinds of companies have to offer and how they hire.

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.

As someone who has done hiring, when someone says that it's a tough decision, it is. They probably would have hired you if the circumstances were different, like if they had a lot more money or if the other candidates were much worse. Most likely you nearly nailed it. Keep trying!

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.

Read this:

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 think lots of companies only interview up to Level 2.

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.

Study and practice. I failed a bunch until I decided to prep.

Try these tips.

http://kelukelu.me/interview/prep.html

I have a whiteboard. I have been studying. I have been practising. But over and over I make a few tiny errors in front of an audience and sink my chances. I think I must just be broken.

Then practice more rigorously. Do it in front of friends and film yourself.

This is especially hard to do if you're in a more senior position and tend to take more interest in solving better problems than small algorithms problems.

Keep trying. Every interviewer has their own standards, and I for one don't recommend against people for minor mistakes when they're on the right track.

If you're just stressed an anxious, try practicing mindfulness or try practicing taking a bunch of pills beforehand.

You are not broken, or at least no more broken than everybody else. You do have a characteristic trait that makes you underperform in certain types of interviews. It sounds like you’ve got a good way to manage that for day-to-day work.

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.

By the way, I tend to be quite good at these "whiteboard" style problems and I always make mistakes. Every single time. I get the impression that most interviewers would find it weird if you didn't, because they didn't get to see you think critically about something you've never seen before.

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.

My advice would be to just do more interviews, and stop taking each one so seriously. Understand that it's a flawed process that in no way reflects your actual skill as a developer, and just play along with it, like the game that it is. If an interview doesn't work out, understand that it's really their loss, because their flawed process ended up filtering out a great candidate that had much to bring to their team.

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.

Looking at your portfolio -- are you applying for video game jobs or generic Big Co software engineer? Or pretty much anywhere you can find / that reaches out to you? Try for something outside of your experience, or even something you might think is "beneath you", selling yourself as a new college grad eager to grow your experience and be part of a team. Also consider applying for SDET jobs after learning some basics about in-vogue testing philosophies. Other than that, I second the advice that it's just a numbers game, keep trying as long as you're able, and if you can up your job search into a full-time activity (i.e. 8 hours a day spent on job search) that's even better. Once you get your foot in the door, even as an engineer-in-test, you can start transitioning within the company more easily as well as continue looking elsewhere without the stress of "I need a job now to pay bills."

I feel as though your story has more to it than simply flubbing code tests. Are there other factors beyond coding skills that an employer would see as a negative? Are you applying only for positions in a particularly competitive region, skill niche or business vertical? etc

>> Should I just burn my CS degree ?

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.

Have you looked at state agencies or consulting companies. The state doesn't pay as much up front but has good benefits and continuous pay raises. Consulting companies are good because they pay you less, train you then throw you at a client at full rates and expect you to "wow" the client. which as far as I can tell means work long "free" hours until you "catch up." But you getting paid and usually get to work at a lot of different companies.

Just a warning about the state: even in the best of circumstances, you will not be working with the latest and greatest tech. You are often legally prohibited from just playing around with something new to see if it will work. The team segregation alone will make you run for the hills if you're used to startup life.

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 :)

Here's what I've done throughout my 35+ year career. 1. I keep my resumes on line (I like to get lots of emails) 2. I love to go to interviews (even if I'm not looking for a job) It's good practice. 3. I approach the problem solving using pseudo code. That way I can offer abstract reasons for perceived errors. 4. The ultimate is to get the interviewer to solve the problem for you.

Buy a bottle of Bourbon, Chips and a nice movie.

If you have a CS degree, but not that much development experience, try aiming for positions which are open for new grads or people with similar experience.

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.

As someone who is graduating this semester, those kinds of questions are very commonly asked to recent grads and for junior positions. In fact it would make less sense to ask a senior programmer whiteboard questions.

That is true, but you aren't going to be grilled on it as strictly if you were an experienced developer.

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.)

Interviews are for unknown quantities and cannon fodder but also for social skills. You need a network to avoid being gamified but, more than that, you need a no-nonsense attitude to manipulate social exchanges to your advantage.

Do you enjoy coding? If so, don't worry. Just keep practicing.

Shoot me an email if you want me to help you interview. :)

Position yourself in a lower position than you think your worth is. If you think you are an intermediate level developer, position yourself as a junior developer who's eager to learn.

If you set lower expectations people are more likely to be impressed.

If you set higher expectations, people are more likely to be underwhelmed.