Ask HN: How to not fail on coding interview questions?

Best thing you can do is to enhance your skills in data structures and algorithms so you have a strong base in them. The interviews normally start here for most of these companies because their software deals with a large amount of data structures and/or algorithms and is essential to understand to be a productive contributor there.

If your previous work did not actually require you to know them, they probably where not building algorithms from scratch or optimizing parsing/processing of data very much. As without the essential basics of data structures and algorithms it is very hard to build scalable applications that rely on them.

As you grow in your career you will have to learn things outside of your base knowledge as you move up the ranks on the technical skills ladder. This will be standard requirements for senior level positions which you are probably seeing now. At the junior and mid level you are normally not responsible for building the core pieces of data processing software engines or massively scalable applications that run custom in house algorithms.

If you go through some of the below resources they should help fill that skills gap and make you an overall stronger engineer so you can feel confident applying for senior level positions.

I would recommend taking the following course: https://www.coursera.org/specializations/data-structures-alg... https://www.edx.org/course/algorithms-and-data-structures https://in.udacity.com/course/data-structures-and-algorithms...

and reading the following book: https://www.amazon.com/Introduction-Algorithms-Press-Thomas-...

I'm one of the most low-key, relaxed people you might meet, which makes my test anxiety worse: since I've learned strategies to mask my anxiety around whiteboard coding, I just look incompetent when my mind goes blank and I can't think clearly.

Contrast this to my daily work, which is often highly technical and high pressure in a wide variety of areas.

The tech interview is broken. The problem is that there aren't many good ideas to replace it. Every large company is focused on eliminating personal bias, easing the process of training new interviewers, and improving repeatability. Pass/fail-type challenges (or perhaps a simple grading system) are the easiest way to achieve those things.

Additionally, companies like Google and Facebook can absorb large numbers of junior candidates directly from schools. Most of these exams are geared toward those fresh from an academic setting.

Small companies adopt these techniques because they also want "the best" without actually considering their real needs. As a result, a cargo cult has arisen around making the technical interview increasingly long and baroque.

Here is some practical advice:

1. Talk to your doctor about your situation and tell them you've heard beta blockers[0] help stop the flight-or-fight response.

2. As others have said, practice over the course of months. Do the same problems again and again. If you can't solve these toy problems without pressure, you definitely won't solve them with pressure.

3. Ask the company ahead of time for a take-home as an alternative. Explain the situation.

Ultimately this situation won't change until engineers in decision-making positions force it to change. Interviewers also need to be trained on how to recognize test anxiety and what strategies they can employ to ease that.

[0] https://en.wikipedia.org/wiki/Beta_blocker

You have entered the world of "competitive programming". Companies have started to incorporate competitive programming problems into their interview processes. They're hard, and often don't overlap a lot with what you may do at work, but there's not much you can do about it other than to prepare.

A good book is "Competitive programmer's handbook", available for free in https://cses.fi/book.html. This book is programmer to programmer advice that will take you very very far into these kinds of problems, and gets to the point really fast. The code examples are clean and well formatted. For interviews, it gives you about 70% of the competence you would get from reading much longer books like Skiena's or Sedgewick's.

My approach to these interviews is:

- Read the requirements very well. Try to read between the lines as much as you can.

- Ask if there are follow up questions or if the exercise has multiple parts. This helps you plan your time.

- If you do not have an ideal approach, try a bruteforce approach first.

- Try to narrow down candidate solutions: what happens if I use an array? a list? a tree (binary search, trie, heap, etc)? a stack? a queue? a graph? a combination of them?

You can practice on sites like Leetcode, Hackerearth and so on so forth. If you want to try something harder, you've got this (not for the faint of heart): https://techdevguide.withgoogle.com/

But first, try to implement common data structures from scratch and get a better intuition about them. Remember to try recursive and iterative versions of operations. You can output Graphviz data and use that to debug.

Finally, even if you fail an interview, many companies will let you reapply after some period of time. I failed an interview a few years ago and I still get contacted by that same company today. It's not a life sentence.

If you live near enough to a tech hub, you have to assume you're going to be code screened and whiteboarded. Companies around here (Seattle) use it as a cost cutting measure so they don't have to spend time and money manually interviewing every single candidate. It's significantly cheaper to enforce a competition-style coding challenge and pick off the top 5-10% performers (example figure) of the challenge for the actual interview.

The pain point is multi faceted:

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