Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 129 posts

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

#111

Post by protonimitate »

warrenm wrote: post #106
daly wrote: 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…

I don't have really have a problem with white-boarding in theory, and as one part of the interview process to help make a judgement call. E.g. if the candidate is weak in talking in one area but strong enough in white-boarding to balance it out.

What I, personally, have a problem with is using it as the catch-all filter to weed out 'bad candidates' when in reality all it does is prove someone can grind leetcode and is good under pressure. Arguments can be made that those are desirable skills to have, but I hate that it's becoming the default pass/fail section of an interview.

In OPs case, and what I am generally against, is that white boarding is being weighted more than any other portion, including relevant and measurable experience. Sure, give a simple problem if you're worried the candidate is BSing about their experience/skills, but it should be set up for success and not failure.

Unfortunately, as long as the 'best companies' (i.e. FANG) are doing it, everyone else will follow suit. And yeah, it'd be great if job seekers had the opportunity to walk away from these types of interviews, but in reality it is very much a company favored market when it comes to hiring in tech right now. Despite the constant supply of new job openings, nobody seems desperate enough for engineers to change things up.

There's also a bit of engineer hubris involved. Most people who are into CS seem to be highly competitive and willing to show off, and white boarding sets up a great environment to get your ego stroked over how well you can optimize something for no reason at all.

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

#112

Post by tzs »

vram22 wrote: post #108
Double_a_92 wrote: post #99

Earlier quoted context omitted.

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

Exactly. On LeetCode, and similar sites, you write some function whose prototype they supply. They evaluate your solution by calling your function with assorted inputs for which they know the correct answer.

Here's what they want you to write for the first missing positive problem if you are using Python3:

  class Solution:
      def firstMissingPositive(self, nums):
        """
        :type nums: List[int]
        :rtype: int
        """
If you are allowed to mutate the input, you can use nums.sort(). If you are not allowed to mutate input, you would need to do something like sortedNums = sorted(nums) if you needed a sorted version of nums.

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

#113

Post by chrisbennet »

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

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

#114

Post by OrwellianChild »

jaredklewis wrote: post #60

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…

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.

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

#116

Post by soreally »

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

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

#117

Post by [deleted] »

tzs wrote: 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…

[deleted]

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

#118

Post by monksy »

chrisbennet wrote: post #113

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

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

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

#119

Post by daly »

monksy wrote: post #105
daly wrote: post #93

Earlier quoted context omitted.

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.

Send your architect home to build a rocking chair over his weekend. See if he calls you back on Monday.

A take home test is a very clear statement by management that your time is less important than their process.

As a professional, you only have your time and skill as your saleable assets. You have the choice of giving them away for free. You could, of course, take the test and then present them a bill for your services.

Another interesting question to ask would be: "How many of your senior management were hired as programmers who passed a whiteboard test or a take home test?" Clearly, according to the market myth, those who did pass were "the best and the brightest". It only stands to reason that upper management is composed of programmers.

Ball-pits are in plain sight, if you choose to see. Ball-pit companies who whiteboard and use take home tests are also in plain sight, if you choose to see beyond the "best and brightest" market hype.

I really respected a Lisp legendary programmer, Daniel Weinreb. He worked at ITA software on airline reservation software. We had many discussions. I'd love to have worked with him. But ITA has the same testing game and I couldn't convince myself to bother. I'm certain I could pass their tests. I've been programming in Lisp since the 1970s. And ITA was a 5-star restaurant kind of company. But those tests are a "Clown-Nose" warning to me. I just walked away.

Walking away has a cost. But so does management games like quarterly status reviews, yearly performance reviews, monthly reports, 1 to 5 rating scales, etc. Clueless management does things like make a rating scale of 1 to 5 and then fires the 5 performers. They have never heard of the Deming Prize (https://en.wikipedia.org/wiki/Deming_Prize), and never bothered to learn what Deming makes painfully obvious. You really should watch Demings Red Bead test https://www.youtube.com/watch?v=ckBfbvOXDvU

Ball-pits and Clown-noses are a sure sign that managers are not well trained, indeed that they are not themselves professional managers.

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

#120

Post by daly »

sonnyblarney wrote: post #97
daly wrote: 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…

"We, as professionals, should consider whiteboarding as an insult. Just walk away." Absolutely disagree. There are tons of developers who have many years under their belt and have glaring holes in their skillsets, or have a complete skillset mismatch, or who are simply not very bright. Conversely, there are some people who are absolutely brilliant, or deeply knowledgable in some areas, and this is one way to possibly…

Yes, I agree that walking away from whiteboarding is displaying "negative signals".

It is a sign of "an attitude and discipline problem", what IBM Research used to call "wild ducks". They placed great value on finding and hiring "wild ducks" (well, they used to, until they decided to "manage" IBM Research). A wild duck doesn't look for the most efficient algorithm, they look for the most efficient solution. They are rarely the same thing.

Most companies decide to hire someone when they have a problem that needs a solution, when they plan to expand in a new direction, to enhance the skillset of a team, or to cover work based on a new or expanded contract. It is very odd to hire because, hey, we want "the best and the brightest".

So the most efficient method of hiring for a solution, direction, skillset, or contract work is DISCUSSION between the person who has the problem and the person who might be the right fit for the problem. If you're looking to move your bank into digital currency it is a pointless waste of everyone's time to schedule interviews with four bank tellers.

Also, in my experience, whiteboarding is usually conducted by new hires (maybe it's just me?) who recently graduated. So their questions involve either an algorithm they know well or a discussion of the order complexity of the algorithm. Odds are good the questions were on their data structures final exam last semester. Perhaps I never get past this level because I don't know how to program.

Whiteboarding is the same level of nonsense as the old Microsoft "How many gas stations are there in NYC?" interviews. It is supposed to show that you can "reason" and give you an idea of how intelligent someone is. In my experience interacting with intelligent people, their "intelligence" shines through in conversation.

Post reply on HN