Live data from Hacker News

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

news.ycombinator.com

101–110 of 129 posts

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

#101
"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).

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

#102
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: 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.

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

#103
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/

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

#104

> 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 ov…

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.

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.

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

#105
post #93

Earlier quoted context omitted.

> 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. This is the typical HN vs the world attitude. "Boycott the…

Anger? I am not, nor did I intend to come across as, angry. I'm just passing along interview advice. As for the myth of "world class salaries" I know, for example, that my nephew who works at one of the Top 5 companies, has a salary that is higher than I ever made. But he also lives near the company and has to share the rent with 4 other "world class salary" colleagues because he can't afford an apartment. I used to…

I used to say this about the whiteboards. Then came the take home tests.

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

#106
post #76

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…

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

You're entitled to your opinion.

I even happen to hold part of it.

But discounting the entire idea of whiteboarding is incredibly stupid.

No, you should not be writing more than pseudocode/logical outlines on the board.

But you absolutely must be able to convey ideas - and visual conveyance is the best way to convey them.

Draw basic flow diagrams.

Write logical steps.

Document, explain, and argue for not only why this approach "will work", but why it's appropriate for the given scenario (could be, "if I only have an hour to get this to work, this is how I'll do it: it will work, but it may not be efficient or pretty", or "here's the high-level overview with a couple zoom-ins - obviously the full solution will take some time to fully architect, but this is a very strong start", or "there are many better ways of solving riddles like this - I don't waste my time recalling those trivialities when I can look them up in a few seconds in ").

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

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

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

#108
post #84

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…

What's the point of the test if you can chose the input? E.g. for a sorting algorithm, you could input an already sorted list then?

I've not tried to solve this question, but I think that by "mutate the inputs", tzs means mutate them as part of the algorithm you write, not before you use the inputs in your algorithm. E.g. it could be something like take a subset of the array, solve the problem for it, save that partial solution, then overwrite that part of the array for some reason, and repeat the same sort of logic for the other parts of the array, also using that saved partial solution (maybe) for the remaining work.

It's like the difference between sorting an array in-place (mutates the array as a whole (by changing order of items), but would not be legal sorting if it deleted or added any items), versus sorting it into a different array, leaving the original array intact. E.g. the difference between Python's lis.sort() and sorted(lis) where lis is a Python list.

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

#109
post #84

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…

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

(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 
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 
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 
(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] 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] 
(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]) - s
          if 1  0:
              missing = i+1
              break
      for i in range(len(a)):
          a[i] = abs(a[i]) - s
      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 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.

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

#110
post #78
post #76

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…

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

"Automatically reject 10% of applicants. We don't hire unlucky people."
Post reply on HN