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

What I've learned from 100s of interviews with candidates at top tech companies

observer.com

Post reply on HN
Print view View original

121–130 of 225 posts

Re: What I've learned from 100s of interviews with candidates at top tech companies

#121

Post by gaylemcd »

drenvuk wrote: post #59
gaylemcd wrote: post #29

Earlier quoted context omitted.

This is actually a really interesting point. (Context: In chess, a queen can move along a row, column, or diagonal to attack. The N Queens problem is to place N queens on an NxN chessboard such that no two queens can attack each other.) No one does poorly here because they are "bad at chess algorithms." They might do poorly because they think they're bad at chess algorithms. But this is not a "chess algorithm." It's…

I have a question about the dynamic programming bit. These questions do not seem intuitive unless its one of the simple ones like, add or multiply the two previous values in the memo (fibonacci) or just check the min or max of the value and modify regarding that. Those patterns can sometimes be easy to spot. The more difficult ones feel like you absolutely have to have seen the problem before because there is complex…

Basically, yes, do more.

If you want to flip a memoization problem into bottom-up dynamic programming: 1. Make sure you really understand the memoization approach 2. Look at the base cases. What are the very last things the recursive approach does? 3. Build up the next case from the base case. 4. Repeat

Re: What I've learned from 100s of interviews with candidates at top tech companies

#122

Post by gaylemcd »

FLUX-YOU wrote: post #48
gaylemcd wrote: post #32

Earlier quoted context omitted.

When people don't get an offer after a technical interview, it's typically about technical skills. Even if they think they did well because they verified their answers online. Often, although their answers were eventually correct, it took them too long to get there which the interviewer perceived as weak problem solving skills.

>Often, although their answers were eventually correct, it took them too long to get there which the interviewer perceived as weak problem solving skills. Does CtCI publish those times for its problems? How would I know I'm too slow to solve a kind of problem before interviewing?

No, I don't publish times. The times are misleading. Interviewers often give hints, which can dramatically change the amount of time. And there can be random factors that change the amount of time.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#123

Post by rajathagasthya »

metaphorm wrote: post #105
strictnein wrote: post #71

> "One Google candidate asked his lunch interviewers where all the “hot chicks” were" It's shocking that people are this dumb, but sometimes brains just misfire in stressful interviews. Happens with the interviewer sometimes too. I was once asked, when an interviewer noticed my wedding ring, if I planned to have any kids soon and what my wife's career was, which is a definite no-no. I assumed he was joking, but he wa…

do you think he was asking in terms of a casual "get to know you" kind of question? or do you think it was more like he was trying to no-hire people with families?

I don't think asking someone who you just met about their wife and if they plan to have kids is a "get to know you" question.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#124

Post by gaylemcd »

NTDF9 wrote: post #66
6stringmerc wrote: post #57

How similar are the Odds for a BS of CS graduate in 2017 in the United States to work in Silicon Valley versus the NCAA Division I Basketball Player to make it in the NBA? Point being, this is extremely helpful batch of advice for a surprisingly narrow field. Take out the SV / Top 1% Tech Culture nuances and there's really not a lot to work with other than "Put your best foot forward, be flexible to learn new things…

>> >Either way, it’s very common for a candidate to get rejected and then get an offer a year or two later. What OP implies is that the interview process is out of candidate's control and there are many variables in play. What the OP doesn't realize is that this is the definition of a shitty process. What would you call a piece of software that cannot reliably produce the same output most of the time? vs What would y…

OP here. I do absolutely realize that candidates getting rejected and then getting an offer later is... well, not quite the "definition", but it's a sign of a flaws in a process. However, you don't scrap the buggy program if there's not a better replacement; you fix the program. And you don't scrap this interview process if the alternatives are even worse.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#125

Post by gaylemcd »

famil wrote: post #68

What do you think about take home projects/homework interviews? I've noticed that they have become much more prevalent among smaller companies as a replacement for phone screens. As a candidate, interviewing is already a time consuming hoop jumping process, so if the project will take more than 3-4 hours, I probably won't be interested but most companies I have applied to are keeping these projects short enough.

I think it's well intentioned but highly flawed.

1. The time commitment issue.

2. It allows a company to give a bunch of "interviews" (assignments) even for candidates they aren't serious about. It can waste a lot of candidate time.

3. There is so much cheating on these that you really can't use it for evaluation. It can really only be a screening tool (which makes 4+ hour assignments really unfair).

4. It primarily evaluates current skillset, not how good they'll be with a bit of training. It's the latter that you care about.

5. They're generally given with little thought about what the company really values. It's typically "uh, gee, we do iOS, give them an iOS app." These projects generally aren't very good at narrowing in on very specific things, like problem solving skills.

6. You don't get a lot of context about why the candidate did things a certain way, and how they would have done things different with some guidance. 7. The results vary dramatically based on how much time a candidate spent on something.

... among other issues.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#127

Post by gaylemcd »

NTDF9 wrote: post #64
gaylemcd wrote: post #38

Earlier quoted context omitted.

>> >> You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. >> Fine. I know this. Will this give me a job? No No, it's not about knowledge. The knowledge is needed. But the real focus of the interview is to tackle a new question. >> I want to be hired for the skills I'm bringing in and not for my ability to solve toy problems on a whiteboard. The ability to se…

>> No, it's not about knowledge. The knowledge is needed. But the real focus of the interview is to tackle a new question. >>There generally isn't. What an interviewer should be looking at is not some sort of percent correct element. It's about signal. So if a candidate is totally unable to understand an obvious, that might worry me. The signal the candidate is sending is a poor understanding of details. (Or, maybe n…

Yeah, there are interviewers who run crappy interviews. This is not a flaw with the process though. If you replace it with any other process, you're going to find interviewers who are bad at evaluating those too.

For example, on behavioral questions, I've seen many interviewers who think "In our company, we handle disagreements by doing X. So I'm going to see if, when the candidate hit a disagreement, they handled it by doing this."

But that's not right. Different companies have different cultures. What's good in one company is bad in another. This is essentially the behavioral question equivalent of the scenario you're raising for technical interviews -- people looking for particular answers, and not considering the context.

Both situations definitely happen, and are very common. But that doesn't make the process flawed. It generally means that the company hasn't adequately trained interviewers.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#128

Post by gaylemcd »

ewjordan wrote: post #25
gaylemcd wrote: post #14

Earlier quoted context omitted.

While you sort of have a point there, there's much more diversity in how people dress at top tech companies than in, say, finance or consulting. It seems you're upset that an interviewer might be biased against someone for wearing a suit. That's fair; an interviewer shouldn't be biased against a candidate for that. And most wouldn't be -- consciously. But subconscious bias can still exist. It's best to skip the suit,…

While maybe it shouldn't be a strong signal, showing up for a tech interview in a suit is kinda like showing up for a finance interview in jeans and a hoodie. It indicates that you're either unfamiliar with the norms in the industry, or deliberately violating them, and neither one is a great first impression. The typical interview rule, IMO, is a good one, at least for men (women unfortunately are under very differen…

Yes and no.

Dressing abnormally does indeed show that you're either unfamiliar with the norms in the industry or you're deliberately violating them. Agreed.

In finance, it's sort of reasonable to be concerned about someone showing up in jeans and a hoodie. A good part of that job is being able be "corporate" and adhere to norms. If you can't do that in an interview, how will you treat clients?

In a coding interview for a tech company, adherence to social norms is not particularly valued. Weirdness is tolerated, if not celebrated. So it's fairly different.

Tech companies would be far more accepting of a candidate in a suit than a finance firm would be of a candidate in jeans and hoodie. That said... it's still probably best to just avoid the risk of subconscious (or even unfair conscious) bias.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#129

Post by gaylemcd »

siliconc0w wrote: post #100
gaylemcd wrote: post #22

Earlier quoted context omitted.

1. No, you don't need to know everything. You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. (If a company is requiring this knowledge, then they're doing whiteboard interviews poorly [or they have a very specific skillset needed]. That's not a problem with whiteboard interviews. That's a problem with that company or interviewer. It takes maybe a week for a…

Wow - this kinda blew up. 1. Obviously you have a lot of experience with this but I just can't see how a week is anywhere near accurate judging from my personal experience, people I've talked to, and the numerous online stories of people's personal experience. 2. To be honest, I kinda expect the world's smartest organization to find some better way to evaluate talent. Google says they want diversity but requiring a m…

1. I'm not saying a week for preparation overall. I'm saying a week to learn the core algorithms and data structures. Frankly, that's probably much less than a week to learn.

2. Yes, it does throw false negatives. Lots of people get hired with zero prep though. I generally say about a month of prep is where you hit pretty low returns from more time. But that doesn't mean that you need a month, or that a month will be enough for you.

3. I'm not sure I see your point here. If coding interview prep is a different skillset from coding competitions, then you wouldn't do coding competitions in order to do interview preps.

4. Some candidates do shut down because it's not what they're used to. A well-trained interviewer can mitigate this to some extent (not always). Some people will also shut down at a computer. Interviews will always be an artificial environment and people can freeze for different reasons. At a whiteboard, it's often a bit easier to unfreeze candidates and create a happier atmosphere.

5. That's fine. As long as I can read it, it's fine. And if I can't read it and you can explain to me what you're writing, that will also work.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#130

Post by kafkaesq »

A mixture of some good observations... with some regretabble bits of fanboy-ism thrown in. For example:

Don’t. Give. Up. Ever.

What they’re testing is your ability—and your willingness—to tackle problems that seem completely baffling. They are looking for you to keep working toward a better and better answer. If you’re ever about to give up remember this: The interview process is designed to challenge you, and even the best candidates feel “stumped.” The question is this: What do you do next?

Just when we thought the fad had finally crested on this patently useless, and more to the point, gratuitously toxic style of interviewing... here's another puff piece to keep the cargo cult going for another 12 months or so. As if the interviewers (themselves most likely just a couple of year out of college) could even hope to simulate the pressures of genuine, real-life, high-pressure technical or operational dilemmas through the device of a made-up puzzle problem or two.

Especially since, about 97 percent of the time, the quality and caliber of grit that brings the most value in business environments isn't of the "solve this made up problem, which I know the answer to (but am hiding from you so I can, you know, watch you think on your feet) -- or hit the road, Jack" variety. But rather of the "no one has any idea where this problem came from yet, let alone whether it's even really solvable" sort. And for which the most effective response, in the vast majority of cases, is decidedly not to go down the next immediately visible rabbit hole and fight the problem to the death... but rather to find a way to avoid going down said rabbit holes in the first place. (Typically by revisiting the stated requirements, and finding what the true customer need is, for example).

And if people think they can simulate these kinds of dilemmas -- let alone "test for" a candidate's ability to tackle them, in an interview context... frankly, they're kidding themselves. Which, being as the true "purpose" of these questions seems to be to buttress the egos of those asking... is apparently perfectly fine, in some quarters.

Post reply on HN