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

Tech Interview Handbook

yangshun.github.io

Post reply on HN
Print view View original

121–130 of 344 posts

Re: Tech Interview Handbook

#121

Post by johan_larson »

maehwasu wrote: post #86
yumraj wrote: post #64

Earlier quoted context omitted.

I really hope this fails, something I have never wished for any other startup. At least personally in my hirings I'll never use or trust anything like this. There are so many things wrong with this approach that I'm kinda speachless as to where to start.

Having a way that coders can avoid doing these types of coding problems over and over seems like a positive. Companies that aren’t interested in the approach could not use it. Most companies today are already using a version of this that is way less respectful of applicant time. But you’re speechless, so I guess there are strong points on both sides.

This is my thinking too. Having to prove, over and over, that I understand how linked lists and binary search trees work is just tiresome. Doing it once and then being able to refer to a trusted credential that certifies it would be a blessing.

I understand nobody is going to hire on the strength of one exam. Every job is a little bit different and some of them call for particular skill sets. That's fine. By all means ask questions tailored to the job at hand. But let's find a way to skip the really generic questions.

Re: Tech Interview Handbook

#122

Post by baddox »

jjav wrote: post #84
DavidWoof wrote: post #11

I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well. I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, w…

I can tell you how I do it and would certainly recommend it as the way it should be done. For some context, I've been interviewing software engineers for about 25 years in companies ranging from established multi-nationals to tiny startups in very fast headcount-growth mode. I'm in silicon valley. I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. It'd be nice to think I…

My immediate reaction is that the problem with that approach is that it’s simply too expensive for the hiring company, in the same way that take-home programming challenges are too expensive for the applicants.

A company trying to hire engineers can easily give a take-home programming challenge to a dozen engineer applicants and take very little time analyzing the submissions. That’s pretty unfair. But it also feels a bit untenable for a senior engineer at a hiring company to have very deep investigations of each applicant’s work history.

Another problem is objectivity. If your company’s engineering hiring process relies heavily on a senior engineer’s subjective impression of an applicant, you’re going to have big problems with your own engineers’ biases, whether subconscious or not. Expect to hear a lot of evaluations like “well, the applicant did seem to have good knowledge and experience, but I just wasn’t impressed for some reason.”

Re: Tech Interview Handbook

#123

Post by watwut »

DavidWoof wrote: post #11

I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well. I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, w…

I like the for loop code thing. Imo, good hiring process for hiring programmers must involve small piece of code. Not difficult or algorithmic, but something to distinguish those who can't do anything at all.

Re: Tech Interview Handbook

#124

Post by virgilp »

norcalli wrote: post #118
virgilp wrote: post #117

Earlier quoted context omitted.

> I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. This may just mean that you say a lot Of wrong “No”s. To get very high precision or very high recall is really easy... what you must measure is your F-score

The regret metric is different for a false "no" compared to a false "yes." I'd rather say "no" to someone who could've been great than "yes" to someone who wasn't, so I would say that it isn't that important.

Depends a lot on the company and situation (how easy is it to fire a bad hire? Does the company do it?) - but you can use something like F2 or F0.5 where relevant.

Remember Facebook rejected Brian Acton, and paid billions for that. An oversimplification, I agree, but the larger point is that people tend to dismiss too easily the impact of bad “no hire” decisions, compared to the bad “hire” decisions. Just because you can’t or don’t measure it, doesn’t mean that the impact may not be arbitrarily large.

Re: Tech Interview Handbook

#125

Post by username90 »

CoolGuySteve wrote: post #109
agentultra wrote: post #62

Earlier quoted context omitted.

Also 95% of job descriptions list skills candidates will never use and screen candidates with problems they will never encounter. At the final interview to join the SRE team at Google I was asked to implement the kNN algorithm. I barfed at implementing a kD-tree after regurgitating the brute force solution. Has any SRE ever had to implement a kD-tree in I asked the interviewer at the end. They had never implemented o…

The thing that really bugs me is that while Google has a reputation for asking these optimization questions, when it comes to programming artifacts one can inspect client side: - Gmail loads slower than Eudora did on dial-up - Chrome takes so much memory it’s basically a meme now - The Google homepage (a text bar on a white background) is several hundred KB. So what I want to know is, if they hire so many algorithmic…

Very few at Google work at client side stuff, most sought after positions are many layers down the stack like machine learning, distributed infrastructure, programming languages or operative systems.

Re: Tech Interview Handbook

#126

Post by masonic »

CoolGuySteve wrote: post #109
agentultra wrote: post #62

Earlier quoted context omitted.

Also 95% of job descriptions list skills candidates will never use and screen candidates with problems they will never encounter. At the final interview to join the SRE team at Google I was asked to implement the kNN algorithm. I barfed at implementing a kD-tree after regurgitating the brute force solution. Has any SRE ever had to implement a kD-tree in I asked the interviewer at the end. They had never implemented o…

The thing that really bugs me is that while Google has a reputation for asking these optimization questions, when it comes to programming artifacts one can inspect client side: - Gmail loads slower than Eudora did on dial-up - Chrome takes so much memory it’s basically a meme now - The Google homepage (a text bar on a white background) is several hundred KB. So what I want to know is, if they hire so many algorithmic…

The (free) Google desktop suite has so many visible fails, it constantly surprises me. Gmail search gives a superset of results. Contacts editing is so slow, it must be doing something artificial behind the scenes. Contacts and Calendar entries rescroll back to the beginning whenever you change context. Even Gmail Labels are sorted differently between desktop and mobile, and navigating within a Label contents can lead you to a dead end that makes you reload Gmail.com from scratch.

Re: Tech Interview Handbook

#127

Post by lifeisstillgood »

new299 wrote: post #28
DavidWoof wrote: post #11

I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well. I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, w…

Personally I can't see an issue with very simple FizzBuzz style programming interview questions. I used to ask a simple "count duplicate substrings" question [1]. Maybe some people consider this too hard? I never used to require exact syntax, and would have been happy with pseudo-code. Using libraries is fine etc.. I also found very few people could solve this (similar non-SF large city location). Occasionally, peopl…

That beats fizzbuzz for me - I think I shall steal it. It's simple enough that it can be done in five minutes but it has enough edges that people could go down the wrong rabbit hole

Re: Tech Interview Handbook

#128

Post by username90 »

driven20 wrote: post #102
firstplacelast wrote: post #75

Earlier quoted context omitted.

I mean it's all a game as much as it sucks. One of my best friends in high school was a salutatorian because the school didn't wait grade. She took zero AP classes and very few honors classes. She knew what she was doing. Friends in college took less challenging majors to boost GPA for med school (business admin, environmental policy, etc) to boost grades and there core classes were easy so it gave them more time to…

I don't understand why you are discrediting people who are taking the better path to med school. Work smarter, not harder. There is also short game vs long game. For example, if you cheat on a test without learning the material. You might win the short game, but if that material was important and you need it later you're losing the long game. That said, if the material was just fluff and no one really cares. It's act…

People who take the easy way or cheats to get around bureaucracy will do the same thing after you hire them at the job. They will do things like avoid password salting for your database unless you explicitly tell them to do it etc.

In other words, I don't want to hire "smart" people, I want to hire intelligent people who take pride in what they do and don't try to take shortcuts to make their lives easier at the expense of others.

Re: Tech Interview Handbook

#129

Post by danmaz74 »

DavidWoof wrote: post #11

I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well. I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, w…

I use basically the same process, but use a very simple programming problem at the end - simple, but amenable to discussing optimization and edge cases. I let the candidate choose the language (or just use pseudo code) and don't care at all about the syntax.

I find that this is very useful especially when interviewing juniors who don't have many projects under their belt for the first part. It's also useful when a candidate has good verbalisation skills, but poor programming ones (which happens).

Re: Tech Interview Handbook

#130

Post by username90 »

fogetti wrote: post #115
solipsism wrote: post #99

Earlier quoted context omitted.

Can you help me follow, because that seems like a leap of logic. Why would that imply there's a bullet-proof way to prove it?

Because if you can't prove it works, you cannot know it works. You can only assume then.

The companies using it has statistics that it works. They have no reason to publish such statistics since it would help their competitors.
Post reply on HN