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

111–120 of 344 posts

Re: Tech Interview Handbook

#111

Post by jishnum »

jjav wrote: post #108
goatinaboat wrote: post #105

Earlier quoted context omitted.

This is just how interviewing was done in the 90s I agree with your approach and use it myself but one thing is different now and that’s the proliferation of tiny skills. Back then you would have a few big skills, you would claim to know one or two main languages, one or two databases and so on. Now people list hundreds - literally hundreds - of skills sometimes. And there’s no way to tell on reading if they really k…

If we're talking about the same kind of thing, I don't consider those to be skills. For example I've seen resumes which list every javascript library they've ever used. Or every UNIX command they know how to run or similar minutia. This tells me the person doesn't know the difference between skills and implementation details, so I don't need to proceed to an interview.

I'd argue that this is a resume overindexed on getting past recruiting filters looking for specific JavaScript libraries or UNIX commands. Even the recruiters action may not be necessarily bad - startups with a decided tech stack might decide they are not able to provide the time for a new hire to ramp up.

Effectively you penalise not catering the candidate resume to what you are looking for or deem important.

Re: Tech Interview Handbook

#112

Post by zerr »

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…

I wonder if there is a list of companies doing interviews this way.

Re: Tech Interview Handbook

#113

Post by 13thThief »

jjav wrote: post #59
triceratops wrote: post #18

Earlier quoted context omitted.

> Can only imagine what this is doing to code quality... Why would studying algorithms and data structures affect code quality? They would similarly be able to learn to write quality code once they're inside the company, no?

This race to the bottom, as parent poster said, is from a generation of developers hyper-specializing in interview-style problems. These problems are tiny and self-contained and have a slick solution which can be regurgitated onto a whiteboard in about 30 minutes give or take. While that is not a negative skill to have, it is also not a skill that I'd list anywhere in the Top-25 of most valuable skills for productive…

Just curious, could you list the top 25 (anecdotal?) valuable skills for a productive developer? Thanks.

Re: Tech Interview Handbook

#114

Post by Consultant32452 »

DavidWoof wrote: post #93
Consultant32452 wrote: post #63

Earlier quoted context omitted.

Every decent sized contracting firm I've ever worked with offered benefits. It's more expensive, but you just price that into your rate. So I don't understand what the concern is. Is it the risk that after 3 months you won't be brought on full time?

Upheaval is the issue. First, most contracting firms have pretty crappy medical plans. Secondly, there's generally a wait period before full benefits kick in. Thirdly, you wind up switching your medical plan multiple times in a short period. That's fine if you're single, but if you've got kids that might mean switching doctors multiple times, which is a gigantic huge deal. Also, you have multiple periods of time wher…

Your description sounds like this should only be a problem for families with serious medical issues, which would be the minority. I do have a kid. If your kid is relatively healthy then pediatricians are basically replaceable widgets. If it's important to you, just pay the cash rate for your favorite pediatrician during that 3 month period. If you're really hung up on it, you can just choose the COBRA option and keep your old insurance during your trial period. It's very expensive, but again, you just calculate that into your contracting rate.

>And keep in mind it's definitely a seller's market if you're a good dev. It's incredibly unlikely that the 3-month contract is the only offer on the table. So all things being equal, who would take it?

I don't feel any additional security whatsoever being a least tenured employee vs contractor. Maybe there's some statistical benefit, but it seems pretty small. So for me, it's practically zero cost to do the contract-to-hire thing. Any financial costs are just built into my rate. I'd rather spend my hiring currency on other stuff like working remote full time and extra vacation days.

It probably makes a difference that I spent a big chunk of my career as a self employed consultant. I do remember feeling some anxiety when I first transitioned from a regular employee to consulting. But I quickly learned my anxiety was unfounded.

Re: Tech Interview Handbook

#115

Post by fogetti »

solipsism wrote: post #99
fogetti wrote: post #96

Earlier quoted context omitted.

I guess the reason is that if it would work we would already know about it and there would be a bullet-proof way to prove it

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.

Re: Tech Interview Handbook

#116

Post by kthejoker2 »

jjav wrote: post #108
goatinaboat wrote: post #105

Earlier quoted context omitted.

This is just how interviewing was done in the 90s I agree with your approach and use it myself but one thing is different now and that’s the proliferation of tiny skills. Back then you would have a few big skills, you would claim to know one or two main languages, one or two databases and so on. Now people list hundreds - literally hundreds - of skills sometimes. And there’s no way to tell on reading if they really k…

If we're talking about the same kind of thing, I don't consider those to be skills. For example I've seen resumes which list every javascript library they've ever used. Or every UNIX command they know how to run or similar minutia. This tells me the person doesn't know the difference between skills and implementation details, so I don't need to proceed to an interview.

Algorithmic HR has ruined any chance you won't see an SEO centric resume ever again.

"I need my resume to show up in your filter, relevance to the actual job functions be damned."

Re: Tech Interview Handbook

#117

Post by virgilp »

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…

> 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

Re: Tech Interview Handbook

#118

Post by norcalli »

virgilp wrote: post #117
jjav wrote: post #84

Earlier quoted context omitted.

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…

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

Re: Tech Interview Handbook

#119

Post by jackmodern »

yumraj wrote: post #7

Given the current state of tech interviews, they have more or less become like standardized tests, such as SAT, ACT, GMAT, GRE... with guides, cheat sheets and perhaps neighborhood coaching institutes on the horizon with instructors who have cleared tech interviews in FAANGs. Are we going to see tech recruitment become more and more like college admissions where a top score in the interview is just one of the criteri…

The next step is back channel reference checks

Re: Tech Interview Handbook

#120

Post by norcalli »

zerr wrote: post #112
jjav wrote: post #84

Earlier quoted context omitted.

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…

I wonder if there is a list of companies doing interviews this way.

I use the same technique (and I'm 26 now, so relatively young) and it's how I've always interviewed others. Granted, I've only worked at smallish startups, but, either way, the company didn't care about my technique for evaluation, and just my final "yes", "no," or "maybe." So, I think it depends on the engineer.

If someone can keep up in a technical conversation about their background with me and answer every question I have about a technical project they did, then basically they pass. It works especially well even if I'm not familiar with their project, because I have an opportunity to learn, so I can ask any question that comes to mind until they teach me what they learned.

I did hire someone that I regretted, though, but to be fair, this was among my first interviews. The mistake I made was getting too easily caught talking about programming and technical things without specifically diving deep into his past project. He and I vibed quickly and I liked him, and that felt like enough, but after only a week it seemed obvious that he wasn't going to be producing much code, and we let him go. Otherwise, I've been happy and my ability to discern has only gotten better as I became more experienced.

I got a little offtopic, but my main answer to your question was "if the company leaves the decision up to a majority of engineers saying 'yes', then a lot of companies do this." Google does this, the startups I've worked at do this, and some of my friends companies do this.

Post reply on HN