Ask HN: How to not fail on coding interview questions? - <AUTHOR> I'm a mid-senior level software engineer with 5+ years of industry experience and making $100,000+. I don't consider myself a bad software engineer, and yet I can't seem to solve some basic problems on a white-board in 30-60min (i.e. traverse a heap, merge sorted arrays etc).
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. <comment><USER4> I honestly feel you'll get horrible advice from HN. Many here feel too strongly about the process itself to give objective advice, as almost everyone here has probably been screwed over for no good reason at least once.

What's your goal? I assume, get a new, higher paying job. What's the barrier? Interview style coding problems, apparently.

So, things that will help you achieve your goal (IMHO):

\- Buying and reading cracking the coding interview

\- practice solving problems on sites like hacker rank and leet code

\- when you practice, try simulating interview conditions. Use pen and paper or a whiteboard if your interviews will involve that

The more familiar and mundane the problems become, the less likely you are to feel nervous with an audience. Just practice the problems until it is like tying your shoes.

If asked to tie your shoe with someone watching, would you be so nervous as to be unable? If so you may have some serious anxiety issue you might want to work on before starting a job search.

Things that definitely won't help you achieve your goal:

\- ruminating on life's injustices

\- ruminating on your own shortcomings

\- comparing your self with others

\- ruminating on the decidedly capricious and error prone hiring practices of Silicon Valley companies.

Life is not fair and there is a time and place to think about those things. But doing so is counter productive to your goal, so I wouldn't recommend it at the moment.

<comment><USER5> Any chance we can up-vote this coherent response above the mud-slinging rebellion against whiteboard interviews? This advice can actually help OP and folks in similar situations.

</comment></comment><comment><USER6> BALL-PITS and CLOWN NOSES

I worked with a guy, Bob, in our college computer room. Bob had returned to get his BS after many years in industry. He had great stories. He also had great advice. He taught me that you can learn a lot about how a company will treat their employees by paying attention to the way they treat you during the interview. He suggested several sign that indicated it was best to just "walk away".

If you go into a restaurant for a professional lunch meeting and they have a ball-pit / swing set /etc. it might not be the most professional place to hold the meeting. Just walk away.

If you go to a 5 star restaurant and they want you to wear a clown nose (Everybody Does It!) Just walk away.

The big scam is "We hire the best and the brightest". "We mandate a whiteboard test (Everybody Does It)". It is my opinion (based on experience) that companies that insist on a whiteboard test, despite years of programming on your resume and open source code, are either Ball-Pit companies (who don't know what it means to be a professional) or Clown-Nose companies (who know what it means to be a professional but still treat you like a commodity). Just walk away.

I understand why Google does it. I've even interviewed there. They get thousands of resumes (which they never read, at least nobody did at my interviews). They have to weed out the "learn coding in 6 weeks" crowd. But you're a professional. You should expect to be treated like one. You don't ask your surgeon to cut up hams in an interview. You don't ask your builder to nail two boards together. Professional accountants are not interviewd by bank tellers and ask to count change.

Google, like Microsoft before it (remember the "why are manholes round? quizes?"), have combined the marketing claim "We hire the best and brightest" with the ball-pit mentality of whiteboarding. Google HR (sorry, People Resource?) SHOULD be embarrassed but apparently they, and upper management, LIKE ball-pits.

A real professional interview involves a discussion about what the company does, what it current problems are (aka why are they hiring), and a discussion of if you, as a professional, have the skills to solve the problem. What do they need? How can you contribute?

We, as professionals, should consider whiteboarding as an insult.

Just walk away.

<comment><USER7> > The big scam is "We hire the best and the brightest".

And adding noise to the hiring process increases the effect of "we are the best".

If you flipped a coin, it would be more honest and less expensive than putting people through a "difficult" whiteboard test. But you wouldn't get the "we only hire geniuses" effect.

As these "difficult" tests are usually based on a corner of the CS field that the interviewer enjoys, it is essentially random, while appearing to be totally meritocratic.

You end up with a process that filters out 90% of qualified candidates, but nobody that was hired by that process wants to change it.

<comment><USER8> "Automatically reject 10% of applicants. We don't hire unlucky people."

</comment></comment></comment><comment><USER9> > But each failure kind of brings me down, and makes me think that I'm a bad > engineer

First off, you are not a bad engineer for failing a technical interview. Over the past 3 years, I've applied for hundreds of roles across dozens of companies. I've been through dozens of interviews and I've got offers from (or worked at) Uber, Twitter, Microsoft, Tesla, etc. The side of the story I don't focus on is that I've had over 200+ rejections. Some after first rounds, some just after they look at my resume. Rejection is part of the game but you just need to push through it. Here's my advice.

\- As other comments have said, it's definitely a numbers game. Some days you just don't mesh with your interviewer, others you know the answer to their coding question before they've even finished asking it. Just apply over and over if you want the best odds. You can't get too emotionally attached to any single interview opportunity. I've had to apply for ~50 roles for each offer I get. That's just the way it works.

\- Practice a ton. It sounds like you are more worried about coding under pressure and thinking through the answer while you are in the middle of trying to explain your thought process to the person interviewing you. I recommend pramp.com You interview someone for 30 minutes over the webcam and then they interview you for 30 minutes. It's super convenient and gets you very comfortable thinking through problems on spot with someone else watching you. I normally do ~10 pramp.com interviews while I'm preparing for an upcoming interview. In person interviews with friends is good too but less convenient than just signing up online for a time slot.

Just remember that bad interviews don't make you a bad engineer. At the end of the day, no one will remember dozens of rejections, but they will remember the job you eventually land. Keep interviewing till you get an offer that you're excited about. Good luck!

<comment><USER10> I commend what you did and where you're coming from but going through 200+ rejections is just soul wrenching, and it's probably not what the OP wants to hear. Something is very wrong in this industry if its hiring practices are so that someone competent needs to go through that many interviews (and rejections) before finding work.

<comment><USER11> Honestly once you get into the groove the rejections really don't matter anymore. I've been rejected from companies that I forgot I even interviewed with - just gotta push forward and play the numbers game.

That said, getting rejected from a company that you had your sights on... that does suck, at first. But usually you can apply again in a year.

</comment></comment></comment><comment><USER12> >there's also extreme examples like the inventor of homebrew that got rejected by google because he couldn't reverse a binary tree.

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.

<comment><USER13> _Google 's focus, however, is on hiring SWEs that can solve uniquely complex and difficult technical problems._

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.

<comment><USER12> >How else do you explain things like their habit of overhauling the graphics while removing functionality on many of their popular offerings?

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.

</comment></comment></comment><comment><USER14> I really enjoyed practicing on Pramp [1]. I ran through their whole batch of problems (roughly 40) so I can't schedule more interviews, but it helped me a lot to work on the soft skills required for FAMG type interviews. Unfortunately I still didn't pass the Google interview (had on-sites in Zurich) even though I was very well prepared. I also maintain (sort of lol) a list of interview preparation resources [2], although I find [3] to be even better.

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/](https://www.pramp.com/)

2 - [https://github.com/andreis/interview](https://github.com/andreis/interview)

3 - [https://github.com/jwasham/coding-interview- university](https://github.com/jwasham/coding-interview-university)

<comment><USER14> At least 2 downvotes on this comment. I'm done with this site.

<comment><USER15> Hey I appreciated your comment, have an upvote.

Try not to take things personally, it could have just been a bot. [https://news.ycombinator.com/item?id=17334552](https://news.ycombinator.com/item?id=17334552)

</comment></comment></comment><comment><USER16> Before this discussion starts between how the interview process sucks. Here is my 2 cents:

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

<comment><USER17> Anyone has any top list in terms of most interesting/creative/fun? Because, I find most of these tasks quite boring - even if the solution is not clear from the start, it just feels too contrived and you know that it's aimed at some particular algorithm and the data structure.

<comment><USER18> I am really enjoying working through the book "Elements of Programming Interviews"

</comment></comment></comment><comment><USER19> It's all supply and demand. The expectations from employers as to what a 'qualified' engineer is likely to demonstrate within a 30 min to 1 hour timespan has increased. To get access to the plum jobs you have to be able to pass the gauntlet of interviews and this is something that's not particularly easy if you don't know the 'game'. First thing to realize is that you don't have to be a genius to pass these interviews, however it does require consistent practice and you will have to be dedicated enough to rearrange your life such that you are able to get in some practice on a regular schedule. Of course how feasible this is depends on your life situation. It is easier for younger engineers to dedicate their evenings and weekends to grinding Leetcode than older candidates.

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.

<comment><USER20> > reddit.com/r/cscareerquestions

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

</comment></comment><comment><USER21> Apply to companies that don't do whiteboarding/phoneboarding. I don't know, maybe this is a US thing, or the Big Four thing, but down here in London I am yet to encounter a company that does whiteboarding.

[https://github.com/poteto/hiring-without- whiteboards](https://github.com/poteto/hiring-without-whiteboards)

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

<comment><USER22> London is a "tech hub".

</comment></comment></comment><comment><USER23> 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](https://en.wikipedia.org/wiki/Beta_blocker)

</comment><comment><USER24> Hi. I also feel this way when I'm interviewing, so please know that you're not alone. Interview Anxiety afflicts a lot of us and it makes us perform much worse in interviews. The way that interviews are structured tend to hurt people as well, often deliberately trying to create a sense of inferiority in applicants to help close deals and negotiate rates. It's an act, usually an intentional one!

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.

</comment><comment><USER25> Here are my advices on how to train yourself for algorithm/data structures interviews:

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;

</comment><comment><USER26> Coding interviews is a performance-based art, so treat it as such. The best way to prepare for an on-stage performance? 1 Memorize your lines until you can't forget, 2 practice with fellow actors, and then 3 practice with real interviews. 1+2 is practice. For step 3, concentrate on improv & how to compensate for when you're not at your best (aka you didn't get great sleep so you forgot a line - what do you do?)

Same for coding interviews. Practice, then interview. 5-10 years down the line, every time you're looking to switch jobs, it gets easier, and you get the insights from the past experiences.

NB

The phone screen isn't easier than on-site; it can often be harder, and often is the same level of difficulty, with more pressure.

NB 2

If you're mid-level they'll ask a few systems design questions. Make sure for the systems you've built, you know at a high level how each individual component was built and what abstraction it stands for.

Good luck! And ping me at my tw email (check profile) if you want to follow up

</comment><comment><USER27> Several people have mentioned practicing on LeetCode problems. I've been doing LeetCode problems recently as exercises to refresh skills in languages I use infrequently but don't want to forget too much of.

Here's a tip that they either don't tell you, or that I managed to overlook. You are allowed to mutate inputs.

I had assumed that inputs were read-only, and spent about three months trying to solve "Given an array of N integers, find the smallest positive integer that is not in the array, in O(N) time and O(1) space". (It wasn't three months of constantly working on it...it was more for three months it was one of my "something to think about while falling asleep in bed or while sitting at a red light" problems).

I then came across a site that talked about the problem and mentioned doing it in O(1) space involved overwriting the input. It was only a couple minutes to solve after that.

Possibly interesting variant of that problem: Can you still solve it in O(N) time and O(1) space if when your code returns the answer the input must be unchanged? You can still mutate the input while your code is running, but you have to undo any changes you make before returning.

I'm pretty sure that the answer to this is "no" in the general case, but if you are allowed to limit the size of the input so that N is not a significant fraction of MAXINT on your machine you can do it.

<comment><USER28> > Can you still solve it in O(N) time and O(1) space if when your code returns > the answer the input must be unchanged?

I don't think that is possible in general. In _some_ cases, such as your "small integers only" case, the program can get extra working memory by essentially compressing the input, doing some work in the freed-up memory, and uncompressing; but if the input memory is already used optimally, there should proveably be no way to store the input plus additional data in those bits.

(Obviously, you can e.g. store one bit of the input in the program counter by splitting the entire program on an initial "if (first_bit) ..."; but that's just moving information around without gaining additional storage.)

FWIW, mutating the input array is a neat trick, but I wouldn't be inclined to accept such a solution, either.

<comment><USER27> (Note: this comment contains spoilers for the original problem and for my proposed variation)

(Note: I'm going to use Python3-based pseudo code, except I'm going to assume 1-based array numbers, so the input is in a[1], a[2], a[3], ..., a[N].)

Suppose the input input list has N integers. Then the smallest positive integer not in the list must be one of 1, 2, 3, ..., N+1. (Prove by noting that all positive integers less than the smallest missing positive integer must be in the list, and then apply the pigeonhole principle).

In the classic problem, where you can use the input list as scratch memory and do not have to restore it, there are two approaches I've seen.

1\. The sorting/permuting approach. With this approach you go through the list, and for a[k] you do

      while 1 <= a[k] <= N and a[a[k]] != a[k]:
        a[k], a[a[k]] = a[a[k]], a[k]

The result is that if a 1 is in the list, a[1] ends up with 1. If 2 is in the list, a[2] ends up with 2, and so on. Then you can scan the list looking for the first k such that a[k] != k, and k is the smallest missing positive. If a[k] == k for all k, then k+1 is the fist missing positive.

If one takes this approach, I don't see much hope in restoring the input back to its original state after identifying the missing integer.

2\. The flagging approach. Conceptually you have an array, b, of N Boolean values, initialized to all False, and do this:

      for k in range(1,N+1):
        if 1 <= a[k] <= N:
          b[k] = True

Then you scan b looking for the first a[k] that is False. k is the missing integer. If all of is True, N+1 is the missing integer.

Note that if all of the input integers were known to be positive, we could use the sign bits of a[] as out b[].

      for k in range(1,N+1):
        if 1 <= abs(a[k]) <= N:
          a[a[k]] = -abs(a[a[k]])

(The abs is there on the assignment to deal with duplicate values in the input).

Then we can scan a[] looking for the first positive a[k], and k is the missing integer, or N+1 if all a[k] < 0.

In this special case, where we know all of the input is positive, we can restore the input back to its original value after finding the missing by simply setting a[k] = abs(a[k]) for each k.

The flagging using sign bit approach also works if not all the input is positive. Just add this at the start:

      for k in range(1,N+1):
        if a[k] <= 0:
          a[k] = N+2

(If N+2 ≥ the maximum positive integer your language allows, then you are going to have to do some special cases that I'm not going to go into).

But now we cannot reverse this after we find the number. If we had a way to get rid of the non-positive entries that we could later reverse, we'd be good. One approach would be to find the most negative value, m, in the list, and then add abs(m) + 1 to everything. Then we could do the prior positive-only sign flagging approach, remembering that when we want the value at position k it is a[k] - m - 1, not a[k]. At the end, we then just subtract m + 1 from a[].

This works as long as M + m + 1, where M is the most positive value in the list, is not greater than the maximum positive integer.

Here's some working Python3 code for this (so arrays are back to 0-based, and so there are "\- 1"s here and there):

      def firstMissingPositive(a):
          s = min(a)
          if s > 1:
              return 1
          s = abs(s) + 1
          for i in range(len(a)):
              a[i] += s
          for i in range(len(a)):
              v = abs(a[i]) - <USER3>
              if 1 <= v <= len(a):
                  a[v-1] = -abs(a[v-1])
          missing = len(a) + 1
          for i in range(len(a)):
              if a[i] > 0:
                  missing = i+1
                  break
          for i in range(len(a)):
              a[i] = abs(a[i]) - <USER3>
          return missing

For Python3, which automatically does big integers, so M + n + 1 will not overflow, this should always solve my proposed restoring variant of the problem.

For systems where that can overflow, we need another approach. I've had some ideas, but they all would also run into overflow problems, so I'm currently stumped.

I think this subproblem is interesting enough on its own to state as a separate problem:

Write a function that given a list S of integers, returns an invertible integer function f and its inverse f', such that for all k in S, f(k) exists, is > 0, and INT_MIN <= -f(k) <= f(k) <= INT_MAX where INT_MIN and INT_MAX are the smallest and largest integers, respectively, your language handles. This should run in O(N) or better time and O(1) space.

Then to solve the restoring variant of missing integer, find f for your input, apply f to the input, and then do the positive-only flagging version of missing integer (using f' to get to the original values of a[]). Use f' to restore the input at the end.

This can be further generalized, because flagging by sign is not the only way to flag. For instance, if we happened to know that all of the input was even, we could use a[k] |= 1 to flag it, and we could clear the flag at the end with a[k] &= ~1. If not all of the input is even, we could start with a pass of a[k] *= 2 and undo it at the end with a[k] //= 2.

That gives us this problem to contemplate. Write a function that given a list S of integers, returns using O(N) time and O(1) space an invertible integer function f and its inverse f', invertible integer function m and its inverse m', and integer function t, such that.

1\. For all k in S, f(k) exists

2\. For all f(k), m(f(k)) exists

3\. t(f(k)) = 0, t(m(f(k)) = 1

f, f', m, m', and t should all be O(1) time and O(1) space.

<comment><USER28> I was indeed thinking of (1), albeit just using radix sort - your permutation trick is nicer.

But (2) doesn't work in general, because information theory may not allow storing more information in the input array than is already there; I'm convinced myself, but I haven't come up with a better argument than "obvious" in the time I had available. ;-)

</comment></comment></comment></comment><comment><USER29> Just be fine with failing a bunch until you find a company not using such obviously bad interview techniques.

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.

</comment><comment><USER30> Posting as annon for obvious reasons.

I was in exactly the same situation you describe about 4 months ago. 5+ year work experience, making 100k+ and joined my company after an internship. Additionally, as an electrical engineer by training, I had little formal training in algorithms and data structures.

Here are some things that worked for me:

1\. Interviewcake.com - worth every cent I paid for the annual subscription. It is an excellent resource - even better than the book "cracking the coding interview" in my experience.

2\. Donald Knuth's Art of Computer Programming - as a person without a formal training in algorithms and data structures, the classic text by Cormen et al was pretty poor. Knuth's AOCP had much better treatment for multiple topics and really helped me understand what's going on. (See the treatment on hash tables in both works for an example on the difference in quality)

3\. Whiteboarding tips - (here is where my recent interviewers might be able to identify me) - You have to remember how whiteboards are more versatile than text editors. Use the whiteboard to draw things, make notes for yourself, analyze the question. I followed a process of writing and underlining these headings:

i. Problem : Reverse alphabets in a word stored as a linked list ii. Test cases: h-e-l-l-o iii. Algorithm: <write down pseudo code> iv. Final code

This might seem like a lot more work at first, but an organized approach like this really helped me complete complex challenges within 45 mins. Give this a try. It really helps

4\. Resume polishing - Some former colleagues were very helpful in reviewing my resume and providing feedback. I saw a dramatic increase in the number of calls I received after revamping my resume.

5\. Practice white boarding - Book a conference room for a weekend and practice solving 10 to 15 hard problems with a timer in the conference room. It makes an incredibly huge difference.

I am happy to say that with these, I went from being completely unprepared for interviews to multiple fantastic job offers in the past 4 months.

</comment><comment><USER31> I've gone through about 6 coding interviews in my life and I failed one. I've given hundreds of interviews, many at some of the biggest companies.

Here's the thing. There aren't that many different kinds of problems that you'll be asked to solve. The recipe for 80%+ of the interview problems I ever see is this:

1\. You have a data structure (tree/array/matrix/graph/string) that may have some special properties (sorted? directed? etc?)

2\. You solve one of a few classes of problems: * Find an optimal <blah> (shortest path, highest value node, longest subsequence, etc) * Mutate the output in some interesting way based on the values

3\. You do that using some other data structure (Queue, Stack, Hash, Heap) or technique (dynamic programming, recursion, etc) for efficiency.

There's probably also a brute force solution you should be able to implement and that shouldn't take too long to do.

My point is, these interviews should be easy for a good candidate because the fundamental problem space for a typical question isn't huge and there's tons of places to practice online. For most interview problems, you should be able to say "Oh! I recognize the general shape, I can apply a few primitive patterns together and get a solution that's basically correct, and maybe I'll have to tweak it a bit to optimize it later".

Instead, I tend to get candidates with 15 years of experience who think they're so hot but somehow can't implement a trivial depth-first search. I don't want to spend the whole interview on trivial coding problems. I want you to finish that part in 15 minutes so we can spend the rest of the time on interesting topics and technologies.

</comment><comment><USER32> Right, so most of the problems in coding interviews that I've done are closer to CS111 trivia or ACM contest prep than an interview of your real-world abilities. Therefore, the best way to practice for that problem set is to practice doing problems like that problem set. There are plenty of resources online to help prepare for that.

That said, a surprising number of problems in life tend to reduce or closely resemble a fundamental data structure or computer science problem. (A lot of problems tend to approximate to graphs.) Additionally, even though most languages have support for fundamental data structures or algorithms in their standard libraries, knowing the performance implication of a double-for loop or understanding when to use a binary search tree compared to a B-Tree or RB Tree can make huge performance differences that real users care about.

This is where the value of the coding trivia interview sort-of comes in. It is the clearest indicator of ones skills in CS primitives you can have, and it does a good job in setting a quality bar within an engineering organization (at least everyone knows how to do these).

I personally think that more comprehensive and system-level interview questions are more valuable in assessing the technical abilities of a candidate in toto. In asking something like "How would you design an app like Instagram," you get a clearer sense of how the candidate thinks, how they approach problems, how much of their CS fundamentals they've retained, and, to some degree, what they're like to work with. It also allows more flexibility than the trivia-style interview. If you want to assess coding ability, you can ask them to write their idea of a feed algorithm. Conversely, if you want to assess their abilities as a lead, you can ask them about maintaining the system and finding the right team to build an app like this.

</comment><comment><USER33> Even before stackoverflow was available, my ability to solve a problem on the spot was probably not that great so my success in passing technical interviews seems like a lot of luck in hindsight - in my actual work I had to solve similar issues in successful technical interviews, and this is over four different industries/positions. This is versus unsuccessful ones where I haven't looked at the thing in question in years or _ever_ so I am pretty much going in cold on the question. I've seen some people talking about going through every question on leetcode or hackerrank and being able to recall a solution instantly to prep for a Google style interview so you have to ask yourself if you think it's worth that kind of effort. Don't take your lack of success now as a very good measure of your ability, it sounds like your company might not hire you if you applied to it even though you are really good at your job.

</comment><comment><USER34> \- Practice a lot.

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

<comment><USER35> +1 for practice. Gone are the days when you could go into a tech interview and count on your skills and smarts carrying you to the finish line. They're just too high pressure and picky nowadays, and you're competing with too many good candidates. You need rote practice: mock interviews with good mock interviewers, and book study. I'd shoot for at least 10:1 prep:interview ratio, so for a 4 hour interview, prep at least 40 hours.

<comment><USER36> _They're just too high pressure and picky nowadays, and you're competing with too many good candidates_

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.

<comment><USER37> The shortage is a myth and corporate propaganda.

They have collectively adopted a strategy of constant moaning because they always want more and better candidates for lower prices.

</comment></comment></comment></comment><comment><USER38> 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](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/](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.

</comment><comment><USER39> In the same boat as you here.

As everyone here says, you have to practice.

Then, when you're finally fairly good at coding challenge questions, you'll discover that you also have to be good at system design questions which is a different beast altogether. And then you'll learn that instead/addition to the above, company X actually wants you to complete a take-home exercise, and company Y won't consider you because they do Python while you have Java.

It becomes very hard to know what to focus on when you don't have your eyes set on a particular company.

<comment><USER40> I had two take homes this week.

The first suggested not to spend longer than two hours and had very precise requirements. I passed this.

Second had four questions - first two were clear and the last two were vague hinting that I should spend 5+ hours implementing a authorization system in rails. They got high level answers for those two. We'll wait and see.

</comment></comment><comment><USER41> If you don't have problems with sharpness of your mind, you might want focus on stress handling. I'd start with the attitude. Why stress out when you have a 6 figure salary?

</comment><comment><USER42> The problem is, while possible that "white-board style questions eliminate a lot of bad candidates", it's a terrible and empirically unsubstantiated methodology of assessment given the purported goals most companies claim to have in hiring people.

In the event that it works at all, it does so by accident, not by design. Which is often evident in how hit-or-miss hiring someone is in most companies even after they've managed to make it through all these silly contrived crucibles.

To a certain extent it's a cargo culting problem. Insofar as companies like Google do it, and Google appears successful, and so other companies (failing to do any meaningful analysis or meta-analysis of their own) decide to model Google on the basis that surely their company will be successful just like Google. The problem, taking Google as the example, is that Google has AdWords. Which is for all intents and purposes a money printing machine. Google can be basically terrible at almost everything they do and still appear wildly successful so long as they don't disturb their money printer. As a result it's very difficult to just pattern-match to what Google does and evaluate either its benefit or its appropriateness in any context.

The other part of it is inertial. Often the wheel of hiring in a company started this way for lack of any better ideas, and then as the company grew it became proportionally more biased toward people who made it through a process like that, and then it becomes generationally perpetuated. The unfortunate side-effect of this is that biasing the employee population this way makes the job, for a new executive or manager, of changing these ineffective (and sometimes toxic) strategies extra difficult while trying to maintain team cohesion. Because it has a lasting cultural fingerprint.

Honestly, it's really a shame. I'm sorry you're having to go through it. My capacity to try to interact and change this weird marketplace phenomenon extends only about as far as the company for which I'm the Engineering hiring manager. My hope for you, and for others, is that you either find a place to work which doesn't do things this way, and/or you otherwise advance far enough in your career that nobody bothers to foist these silly ceremonies on you. Because your involvement in their pursuits is seen as a priori beneficial or existential.

</comment><comment><USER43> I can understand your situation because I was in your shoes once. I joined a place as an intern and stayed there for 6 years. Once I tried getting another offer, I realized I was a bad SWE by other company's standard. And I failed interviews after interviews. Around 25 interviews but finally nailed one which led me to path which turned my life around.

So, how did I get the last interview? Once I realized that I wasn't doing great, I started writing down all the interviews questions. The aim was to understand what was I doing wrong. But in doing so, I started to see a pattern, most interviews tend to follow a singular script. For example transverse a heat map, merge sorted array etc. And I trained on all those questions. Now this wasn't a perfect solution because I still failed 10+ interviews but over time I got better. And then around the 25th one I finally nailed one as all the questions were repeated.

Nowadays there might be a better options to do this like books/sites which throw tons of whiteboard interviews at you. So try those and best of luck.

</comment><comment><USER44> Does anybody know what the interviews at the FANGs are like for non-SWE roles? What are the interview questions for a front end developer? Do they still make you reverse binary trees?

<comment><USER45> Frontend Developers at Google (and probably the other letters in FAANG) are SWEs.

</comment></comment><comment><USER46> A lot of people recommended practicing coding problems. Along with this, I would add practice talking to people you don't know.

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.

</comment><comment><USER47> This was told to me by someone who recently got into Google:

"It is irrelevant whether you can come up a solution all by yourself. Being able to understand and remember the optimal solutions for those questions is the key. All the interviewer is looking for is whether you can write those optimal solutions literally on the whiteboard."

We can debate (and people have here) about whether it makes sense and the like, but this is the reality. Make this process as mechanical as possible, everyone knows it's a stupid game and yet we all play along.

[https://translate.google.com/translate?hl=en&sl=zh- CN&u=http...](https://translate.google.com/translate?hl=en&sl=zh- CN&u=http://www.cnblogs.com/grandyang/p/4606334.html&prev=search)

</comment><comment><USER48> I would say the biggest thing you can do is practice on Leetcode. You need to be see the different patterns that are used to solve certain classes of problems (tree problems, dynamic programming, array focused problems). There are common data structures that pop up in almost all of the questions (hashmap, linked lists, tree, bst, etc). It's just a matter of exposure but focus on the underlying pattern/technique used to solve the problem and understand how and why it's being used as opposed to rote memorization.

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.

</comment><comment><USER49> I haven't programmed much since I stepped into management 15 years ago, and while I'm not sure I could do still do Dijkstra I can still do all those silly text-book examples on a whiteboard if you gave me the business logic. From x-sort to linked lists and trees.

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.

</comment><comment><USER12> What's the pain point? The stress of being observed? Getting started? The difficulty of the problems themselves?

How long would it take you to merge two sorted arrays on a computer without internet access and no one looking?

<comment><AUTHOR> It would probably take me less time due to not having the pressure of someone looking, but it might still take me ~ 30min.

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.

<comment><USER29> Interviewers are very bad at accounting for this.

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.

<comment><USER12> >Seeing "how someone thinks" in an artificial 30-60 minute session only tests a completely separate and mostly unnecessary skill set

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.

<comment><USER29> They can ask probing technical questions about past work experience, projects and education. Pretty much like how every other industry interviews people.

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.

</comment></comment></comment></comment></comment><comment><USER50> I feel you, I also get stressed out during interviews and perform worse than normally; it was the same for me during oral exams at Uni.

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.

</comment><comment><USER51> Sometimes it's not the white board part of the interview that is the problem but the anxiety and general anger the w.b. interview generates. It's a little like getting groped by TSA at the airport.

It would go a long way towards making the experience better if the interviewer/TSA guy stated right at the beginning said _" I realize this experience is degrading and it sucks to be treated like a liar/terrorist but I'll try to make it as pleasant as possible. "_ ?

A part of the reason we have this current interview process is because there are people out there who can really "sell" themselves and have bogus resumes so they have to screen these guys out i.e. "this is why we can't have nice things".

<comment><USER52> > It would go a long way towards making the experience better if the > interviewer/TSA guy stated right at the beginning said "I realize this > experience is degrading and it sucks to be treated like a liar/terrorist but > I'll try to make it as pleasant as possible. " ?

That's why I volunteer to be massaged. Can't be forced into something you've already went along with.

</comment></comment><comment><USER53> 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.coursera.org/specializations/data-structures-algorithms) [https://www.edx.org/course/algorithms-and-data- structures](https://www.edx.org/course/algorithms-and-data-structures) [https://in.udacity.com/course/data-structures-and- algorithms...](https://in.udacity.com/course/data-structures-and-algorithms- foundation-nanodegree--nd004-indsa)

and reading the following book: [https://www.amazon.com/Introduction- Algorithms-Press-Thomas-...](https://www.amazon.com/Introduction-Algorithms- Press-Thomas-Cormen-ebook/dp/B007CNRCAO)

</comment><comment><USER54> Practice. I have a very similar reaction to those types of interview questions. Your day-to-day engineering work is entirely different, so it's no surprise you get stuck on those questions. This programming interview book [0] really helped me.

While I don't agree with this type of interview, it is the reality we live in.

Disclaimer: The book was written by a professor of mine in college. [0] [https://elementsofprogramminginterviews.com/](https://elementsofprogramminginterviews.com/)

</comment><comment><USER55> "But each failure kind of brings me down, and makes me think that I'm a bad engineer."

You're not. I do these type of interviews and there are plenty of times where a person doesn't pass but I can tell it's just because they need to prepare more. I think your strategy of applying and failing is good, but I would also supplement it with practicing these type of interviews (e.g. get a whiteboard, go to leetcode or wherever, pull up a random question and pretend like you're in the interview).

</comment><comment><USER56> Try practising speaking your ideas and approach out loud. This may do two things, which reinforce each other: giving yourself momentum and positive vibes as you say things you know are right and leading you forward towards the answer, and building a clearer idea of your skills and manner in the minds of the interviewer. In effect, you are trying to turn the liability of the audience into an asset.

</comment><comment><USER57> You are not alone on this one. I myself have also been through this experience.

Have you considered a different option ? How about building your own start-up to serve real business needs? Or working on open source projects. There are a lot of opportunities to look forward into.

Why keep banging your head multiple times on something, when you can use that energy on other meaningful ways.

<comment><USER58> I like what you're saying, but there is quite a bit of comfort and safety that comes with a $100,000+ job compared to starting up your own business. While many of us are ok with that risk, others may very well have responsibilities that dictate taking the "sure thing."[0]

0\. [https://danluu.com/startup-tradeoffs/](https://danluu.com/startup- tradeoffs/)

</comment></comment><comment><USER59> One thing people often don't realise about interviews at Google and other companies with similar interview standards. You can't casually apply for those. You have to prepare a lot. At least for a month (probably much more) before the interview you have to practice coding questions on Leetcode or similar resources.

</comment><comment><USER60> My company doesn't use this for interviews for many reasons. It's absolute nonsense.

Email me at the link on my profile if you'd like a list of our open positions.

</comment><comment><USER61> Would you get different results if you were in a room by yourself, under exam conditions? Maybe some companies would let you test that way.

</comment><comment><USER62> Having gone through the same situation, I'd advise practice and you'll eventually catch on. Hackerrank is a good place to start.

</comment><comment><USER63> Practice, practice, practice. Then practice more. It sucks, but until we get to set the rules - just practice 'till you good.

</comment><comment><USER64> Solve 150+ random leetcode questions. Play a video on YouTube of someone watching you and "taking notes."

</comment><comment><USER65> Consider freelancing or going into business for yourself.

</comment><comment><USER66> Practice on interviewing.io

<comment><USER67> I conduct interviews on interviewing.io so I'd just like to add some clarification on this advice. You don't get unlimited interviews so it's best used for interview practice, not coding practice. If you have trouble with the technical parts (sorting, trees, etc), you can learn that on your own from books/leetcode. Once you're confident in your coding and CS fundamentals, use interviewing.io for the aspects of interviewing that you can't learn from leetcode: gathering requirements from the interviewer, explaining your thought process, staying calm under pressure, time management, etc.

</comment></comment><comment><USER68> Interviewing is its own skill!! To get into eg Google you have to go through the rites of passage of learning to interview. That's not true of all positions. I give take-away assignments now. I want to see you can turn in good code. That's all I really care about. How you get there doesn't matter, your decisions do.

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

</comment><comment><USER69> you don't want to blame the process, yet you admit it brings you down every time you fail and makes you doubt of the already proven ability you have as an engineer, and the process is ok?

<comment><USER70> Your answer is not helpful on several levels and you might even know it.

<comment><USER69> he is just hurting himself by trying so hard on a already broken system, encouraging him to keep going at it like most of the user on this thread( Keep drilling! keep drilling!) will just make him more sad and doubt even more of his own skills which are already proven on his company to be good enough, if anything people should encourage him to try places that don't use such broken methods and go for companies that really value his skills and dont take such broken process seriously.

<comment><USER70> Apparently you place no value in an evaluation done within a broken process - and rightfully so.

I have to ask: how do you tell a good process from a bad one?

<comment><USER69> (personal opinion), but to me a process that encourages these kind of drills is pretty broken, these drills are ( most of the time) not related to the real world problems the company faces on a day to day basis, imo, a better process ( but not perfect) would be to test candidates on problems related to the ones you face at the company combined with cultural fit / pair programming sessions, even tho not perfect it can attract more candidates that are more fitting to the company and the team.

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.

<comment><USER70> If I understand you correctly, the bad issue is tests by drilling for drilling sake. I agree with you but follow me on this:

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.

</comment></comment></comment></comment></comment></comment><comment><USER71> Shameless plug: [https://chrisjshull.com/agent/](https://chrisjshull.com/agent/)

<comment><USER72> Meta: I downvoted you for not explaining what this random link is and how it relates to the topic.</comment></comment>


Scatter - Ajax without coding, ideal for HTML prototyping - <AUTHOR> http://blog.quplo.com/2010/11/scatter-ajax-without-coding

<comment><USER2> I downloading the js file, followed the instructions and it didn't work

A suggestion - when you post code, it's nice to have: 1) a working demo page 2) the example source code not in an image so it has to be re-typed to try

<comment><USER3> It would be hard to just copy/paste the example as it uses Quplo's proprietary syntax (flow, a prototyping markup language). You'd have to load it in quplo for it to work, and we didn't want to suggest that you needed a quplo account just to check out Scatter.

<comment><USER2> I see. I didn't look through the JS, nor have I used Quplo so I just figured i'd have to trade correct syntax for ease of prototyping using this.

I asked myself a couple of times why you'd wrap <html> in <page> lol.

</comment></comment></comment><comment><USER4> He complains about Ajax being a horrible term when it could mean something so simple, and then names his project 'Scatter'? Pot, meet kettle.

<comment><USER5> Probably the 'X' bothers him; it's always seemed silly to me to emphasize 'XML' when the most interesting uses of AJAX skip XML for raw HTML and JS, and the APIs for doing background requests only mention XML as a historic accident (like the misspelling of 'referrer' in HTTP).

It's just a matter of taste, but I prefer a vaguely evocative name like 'Scatter' to a faux-precise-acronym like 'AJAX'.

</comment></comment><comment><USER6> No comments about licensing on the blog post or in the source code. (<http://quplo.com/scatter> is not responding.)

<comment><USER2> license information is on the download page <http://code.google.com/p/scatterjs/>

but agreed, it should be in the js file itself

<comment><USER6> My bad. Thank you.

Edit: For the record, the license is MIT.</comment></comment></comment>


The Game AI Programmer's Bookshelf - <AUTHOR> http://alumni.media.mit.edu/~jorkin/aibooks.html <comment><USER2> Every href on this page is an Amazon affiliate link. Even public domain works such as Society of Mind by Minsky are directed to a for profit version. Observing this does not invalidate the judgement of the MIT student who published the list, but the profit motive should be disclosed in my opinion.

</comment><comment><USER3> A few days ago I read an article about Overmind (Starcraft: BW AI), and it got me interested in how AI is built, but I can't learn from books. Are there any blogs or such that teach this kind of stuff?

[http://arstechnica.com/gaming/2011/01/skynet-meets-the- swarm...](http://arstechnica.com/gaming/2011/01/skynet-meets-the-swarm-how- the-berkeley-overmind-won-the-2010-starcraft-ai-competition/)

<comment><USER4> (I'm one of the authors of Overmind.)

First, it's important to know that AI is a very broad term. Roughly, there's "modern" AI (machine learning and statistical modeling) and "classical" AI (mostly logic and search). Game AI (as I understand it) falls more into the "classical" AI camp, and classes these days are focusing more and more on modern non-game techniques.

kaybe's link is a good starter class for modern AI. Norvig quite literally (co)wrote the text book on AI, and Sebastian Thrun. The PI on Overmind (Dan Klein) co-taught a class on edX ([https://courses.edx.org/courses/BerkeleyX/CS188.1x/2012_Fall...](https://courses.edx.org/courses/BerkeleyX/CS188.1x/2012_Fall/info)) that you might also want to check out. They're all based on the same underlying book, just different focuses.

Overmind itself is a collection of some reasonably sophisticated ML/modern AI, classical AI (which is more common in games), and a lot of horrible hacks. Really, tons of them.

If you want, I can try to dig up the lecture slides for the "advanced" AI class we taught once that specifically focused on the kinds of techniques one would want to write StarCraft bot AIs.

<comment><USER3> Thank you very much! I'm mainly interested in Game AI, though I would not be surprised to find "modern" AI used in games at some point, either.

If it's not too much trouble, the slides sound extremely interesting.

</comment></comment></comment><comment><USER5> If you have personal experience, read, any of the books, I (and I imagine other HNers) appreciate your comments on the books.

Specifically are the "AI Game Programming Wisdom" books, the new revisions of the same thing? or they complement each other?

<comment><USER6> "Artificial Intelligence: A Modern Approach" by Russel&Norvig is one of the most used course books in AI. It covers basics of formal logic, search, making decisions, handling uncertainty etc. All at an introduction level, though, so for someone with many years of programming experience many of these things may be known already. As my adviser says: Once AI discovers something interesting, it becomes labeled something else or become a part of "standard computer science". I can recommended the book for an overview of the field and knowledge of the basic techniques, but not as something to read when game AI is the goal.

<comment><USER7> EDIT: I just looked through the table of contents again, and it does actually have useful topics in it.

I was so scarred by my godawful, incredibly academic, college AI course that I only remembered the bullshit that we actually covered in that course. Literally nothing in the course was worth wasting my time on, and it looks like we went purposefully around anything that might have been relevant or interesting.

It's baffling to me that two of the worst three computer science courses I took were AI and Algorithms & Data Structures. Both had mindbogglingly abstract, mathematically-oriented profs, who spent every lecture transcribing proofs from the textbook onto the blackboard. How do you teach a course on these subjects and have no assignments that involve writing code? This is at the place where BASIC was created, for chrissakes.

<comment><USER8> I had a very similar experience as you wrt AI and algorithms courses. Oddly enough, when I then (later) started exploring these more on my own I found them much more interesting.

</comment></comment></comment></comment><comment><USER9> Thanks for sharing - perfect timing as I just had the best gaming weekend for a very long time and to a big part that's due to the fabulous AI in Alien: Isolation (it won the aigamedev community award for best NPC 2014 [http://aigamedev.com/open/editorial/2014-awards/?utm_source=...](http://aigamedev.com/open/editorial/2014-awards/?utm_source=twitter&utm_medium=social&utm_campaign=promote#characters) ).

</comment><comment><USER10> There's nothing on that list on locomotion or physical coordination. We have enough compute power now that game characters can have robot-type control algorithms, so the motion really looks right. Toribash ([http://www.toribash.com/](http://www.toribash.com/)) does this, but that's all it does; it's more like a development environment for martial arts moves.

(Of course, if you have physically-based martial arts in a game, all the things go wrong that go wrong in a real dojo. Some people will like that; they're the ones who buy Formula I racing games where you get to tune the car.)

</comment><comment><USER11> Excellent timing for me. I was needing resources for this soon. Thanks, as alimoeeny said, any one with experience with these books would be appreciated :-)

</comment><comment><USER12> Hi there thread. I teach game AI and have spent the last couple of years researching it heavily. Here is my infodump.

The most important resources for game AI, in my opinion, are:

\-----

1\. The AI Game Programming Wisdom series, which really ought to include Game AI Pro (it's basically AI Game Programming Wisdom 5). The AI Game Programming Wisdom books are the best resource on practical game AI out there. It's surely not perfect, for several reasons:

      -- Some of the information, especially early on, is a bit dated now, as someone above said
      -- Some of the articles are not great, especially those written by academics (although they are occasionally good)
      -- Some of the articles by actual game programmers are a bit too much of "here's what I did" rather than trying to extract general principles that may be of use to other programmers

All that said, I think it's still the best resource on game AI out there. I thanked Steve Rabin once at GDC for the books, and he replied with something to the effect of "I do it because otherwise a lot of this information would never get out there". I think he's absolutely right.

2\. GDC Vault talks. I've watched/listened to almost all the game AI talks at this point. They're often very good, and again much of this information doesn't appear anywhere else. It's an expensive proposition, but if you truly care about game AI, at some point you ought to get access and go through them. Sometimes you can find the information/videos in them outside of the Vault on the devs' homepages and elsewhere, but I can tell you from experience that sometimes you can't.

3\. aigamedev.com . Alex Champandard has been writing about game AI for a long time -- note that one of the books Jeff Orkin recommends on his page is written by Champandard and is over 10 years old at this point. More than anyone else in game AI, I trust Champandard's analysis and articles, because he's written game AI in big games himself, has given many GDC talks, continues to explore AI with his collaborators in the AI Sandbox, and has interviewed hundreds of game devs personally. Yes, some of his good articles and videos cost money to view, but I really do believe it's worth it.

\-----

I realize that my picks above for game AI may not be popular, because all of them cost a decent chunk of money to access in full. But I've seen most of the free stuff out there, and if you want the best resources, written by people who actually have made AI in real games, a lot of times you're going to have to pay for it. You can piece together a lot of the knowledge without it, but it's going to be very time-consuming and you'll still have significant holes when you've finished.

I noticed above that a lot of folks recommended Peter Norvig's AI textbook, often considered the standard textbook in AI. I'm going to say something different and recommend strongly NOT to read it if you're considering making AI for games. I think most of the important knowledge and techniques you'd need to know to make good game AI are not covered anywhere in the book and your time is better spent elsewhere. I don't think it's a bad book in general, just for game AI specifically.

Other books that aren't quite as good as the first three resources I mentioned, but still quite useful:

1\. Artificial Intelligence For Games, by Ian Millington and John Funge (on Orkin's page): I think this is the best general game AI textbook out there, in large part because it's one of the few that actually attempts to be comprehensive. There's a lot of good knowledge in it. If you only bought one book I'd recommend this one, but it still has big holes and blind spots. (If you're more of "let me see the source code" kind of person and only buy one book, I'd recommend Programming Game AI By Example by Mat Buckland, also on Orkin's page.)

2\. Behavioral Mathematics For Game AI, by Dave Mark (on Orkin's page): Dave Mark is a well-known presence at GDC for running many of the AI panels and talks. His book is not a comprehensive reference, I feel, but covers utility- based AI very well. (If you like utility-based AI I'd also recommend anything written by David "Rez" Graham, currently a lead AI programmer at EA working on The Sims.)

3\. AI For Game Developers, by David M. Bourg (on Orkin's page): I like the section on neural networks from this book. It's the best I've seen in the context of games, even though it's a bit old at this point. (I would recommend Andrew Ng's online machine learning course as the best general treatment of neural networks I've seen, but it doesn't talk at all about how you'd apply them to games.)

4\. AI Techniques For Game Programming, by Mat Buckland ( [http://www.amazon.com/Techniques-Programming-Premier- Press-D...](http://www.amazon.com/Techniques-Programming-Premier-Press- Development/dp/193184108X/) ): I like the parts on genetic algorithms from this book. Like the previous link, it's the best resource I've seen that specifically relates this topic to games, even though again it's actually a bit old these days.

As far as webpages go, here are three that I think are important enough to mention (besides AIGameDev, mentioned earlier):

1\. Amit Patel's Introduction To A* ( [http://www.redblobgames.com/pathfinding/a-star/introduction....](http://www.redblobgames.com/pathfinding/a-star/introduction.html) ). Amit Patel's stuff is great in general, but his A* tutorial in particular is outstanding. It's the only outside resource on A* I recommend to my students.

2\. Digesting Duck blog ( [http://digestingduck.blogspot.com/](http://digestingduck.blogspot.com/) ). Written by Mikko Mononen, a former AI programmer for Crytek, current programmer at Unity, contributor to the Recast open source navigation mesh framework, and programmer on lots of other cool stuff. There's a lot of great info on how to actually work with navigation meshes here, and well worth reading.

3\. Steering Behaviors For Autonomous Characters ( [http://www.red3d.com/cwr/steer/](http://www.red3d.com/cwr/steer/) ). Written by the guy who got steering behaviors in games started, Craig Reynolds. Still the best place to get started with them.

I hope all this can help someone out there like me when I started researching a couple years ago. :)</comment>


It's impossible to work your way through college nowadays (now with national data) - <AUTHOR> http://www.randalolson.com/2014/03/29/its-impossible-to-work-your-way-through-college-nowadays-revisited-with-national-data/

<comment><USER2> That was my experience. That chart gives a little comfort. I dropped out for the third and final time in 2006. It was a task that I was not well prepared for (I was prepared for what I expected it to cost). In retrospect I can see things that I might have done better (can't everyone?); but a number of those things amount to 'ignore the advice of [parent, grandparent, other well- meaning people, etc]' or disregard culturally imprinted ideas x, y, and z. In that light, I won't second-guess my early-twenties self for his lack of wisdom. I don't regret my college experience. I am glad that I don't owe a large student loan debt for a failed degree attempt, but if I had taken a small amount to help me complete my last year, that might have been worth it. So maybe just the one regret.

<comment><USER3> I also worked through college, and it sucked. I managed to make it through, but there were any number of times that I almost didn't. I did have a few loans at the end, but I went to <local state school> and they were well under <$20k and where paid off within just a couple years with the new salary I could command.

>but a number of those things amount to 'ignore the advice of [parent, grandparent, other well-meaning people, etc]' or disregard culturally imprinted ideas x, y, and z.

I'm glad that you bring this up. There's a tremendous number of people and sources that want to give you advice about how to do it, but they're frequently wrong and it's _very_ hard for a 20-something just out of high school to go against those voices. Furthermore, the 20-something probably doesn't know the answers either given their experience.

It's a shame you didn't make it through, but it's never too late and if you go to local state school a class per semester, it isn't _that_ time consuming or expensive.

The only advice I can give you is that it's better to achieve the achievable and not live with that regret.</comment></comment>


'Nothing is ever dry down here. Ever.' - <AUTHOR> http://www.telegraph.co.uk/culture/books/10928588/Nothing-is-ever-dry-down-here.-Ever..html

<comment><AUTHOR> A lot of the more interesting anecdotes are in the second half of this article:

• The crew are constantly affected by nitrogen narcosis, making some behave as if they are slightly drunk

• The support team used to carry supplies down from the surface by free diving (with no oxygen), because that was much quicker, but it was impossible to enter Aquarius because breathing the higher pressure air inside could have killed them.

• Toilets are a problem due to pressure and privacy issues. The crew try to avoid using it

• A tiny puddle of spilled water can take weeks to dry inside Aquarius. Article does not explain why, unfortunately.

Aquarius site at FIU: [http://aquarius.fiu.edu](http://aquarius.fiu.edu)

Nat Geo story (2003): [http://ngm.nationalgeographic.com/ngm/0309/feature4/index.ht...](http://ngm.nationalgeographic.com/ngm/0309/feature4/index.html)

<comment><USER2> I think the puddle would take a long time to evaporate because the air is basically saturated with water vapor (100% relative humidity). Saturation at the higher pressures in Aquarius occurs at a much lower water vapor concentration than up here.

In other words, the water has nowhere to go.

<comment><AUTHOR> But they do have air conditioning, so they are able to condense water vapor out of the air. It seems like it's not very effective in that environment, so I'm curious to know why and if it could be improved. I assume the poor performance of the a/c is simply a result of the very high air pressure, but I don't know exactly why.

<comment><USER3> Breathing compressed air tastes so funky sometimes, I hope it's just nitrogen causing the narcosis.

Looks to me like the living chamber is pressurized to match the ambient water pressure, so realistically a free diver could enter but would still have the same limited "bottom-time" as when they are using scuba at that depth, otherwise the same decompression regime would be required upon ascent.

The conditioning of air for a relatively closed system should not be expected to resemble or contain the same elements as an ordinary residential application where cooling is the main consideration and moisture removal is a side-effect of the most common apparatus in humid environments.

A regenerative industrial air-drying unit could be adapted, at least I know I could do it, but may not be within their energy budget.</comment></comment></comment></comment>


Unconventional way of learning a new programming language - <AUTHOR> https://dev.to/sahildua2305/unconventional-way-of-learning-a-new-programming-language <comment><USER2> TL;DR: Contribute to "open source"

>[code review feedback] is like getting a free-of-cost personal guidance about how to write good code

It's not free for the reviewer who's trying to safeguard project quality. If they're investing in you, it's likely under the assumption that you'll contribute back. If you don't, then you're just crowdsourcing and then running off with the ill-gained knowledge, possibly having had a negative impact on the project.

<comment><USER3> Code review happens after the code is written so how could the contributor "run with ill-gained knowledge".

<comment><USER2> NOTE: I've started with 2nd person (to match the article, be more personal and appeal to the reader's conscience), so I'll be sticking with "you" instead of "the contributor".

If you're unfamiliar with programming language idioms, it is likely that your (ultimate, approved) contribution may not be be worth the time and the effort that has been put into guiding you to it. The help may instead have been given to you in hopes that it will pay off with your future contributions. If your only or main motivation is to learn a programming language, there's a greater chance that there won't be any.

Contributing out of sheer sense of obligation is hard. Even worse, it may so happen that you realize that you don't even like the language. Not only is the the time invested in teaching you the project a waste for the project, but the teaching you the language was not beneficial for other projects written in the same language. To stay interested in a project, you should be certain of your interest in some thing intrinsic to the project.

At least be very frank and clear about your intentions.

</comment></comment></comment><comment><USER4> A more unconventional (but effective) way would be writing a compiler for the language you want to learn.</comment>