Tech Interview Handbook • Hacker News Board

Re: Tech Interview Handbook

#11

Post by DavidWoof » Sun, Aug 18, 2019, 2:47 AM UTC

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, we included what we thought was a trivial nested for-loop problem and virtually nobody could even get started on it.

Is this kind of code problem too complicated in your opinion? For all I join in when complaining about irrelevant algorithmic questions, I have to admit that they at least test something, even if it's just willingness to study for the interview.

Instead of reading everybody's complaints about interviewing, I'd love to hear how you think it should be done. Because I have to admit I'm pretty much lost right now.

Re: Tech Interview Handbook

#12

Post by sthatipamala » Sun, Aug 18, 2019, 2:47 AM UTC

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…

There's a YC company that's literally making a standardized test for programmers: https://cspa.io/

Re: Tech Interview Handbook

#13

Post by [deleted] » Sun, Aug 18, 2019, 2:52 AM UTC

codingslave wrote: post #4

Two outcomes for the technical industry: 1.) Everyone is studying these problems all of the time and they finally disappear. 2.) Other outcome is a dystopian field fueled by a race to the bottom where everyone is practicing algorithms problems all of the time. If you read the blind forums, some people are completing 500-1000 leetcode problems before heading into interviews. I'm putting my money on number 2, which is…

[deleted]

Re: Tech Interview Handbook

#14

Post by ale22 » Sun, Aug 18, 2019, 2:53 AM UTC

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…

How much were you paying for these positions?

Re: Tech Interview Handbook

#15

Post by leovander » Sun, Aug 18, 2019, 2:53 AM UTC

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…

Nest for loop for the technical interview? Where do I apply?

Re: Tech Interview Handbook

#16

Post by momokoko » Sun, Aug 18, 2019, 2:55 AM UTC

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…

Is there any chance you could share the problem? Changed enough to protect your identity, of course.

Re: Tech Interview Handbook

#17

Post by triceratops » Sun, Aug 18, 2019, 2:56 AM UTC

kthejoker2 wrote: post #10

Having hired dozens of devs, I can confidently say there is absolutely 0% chance to consistently successfully identify good developers in any reasonable amount of interviewing / assessment time period. The best way is someone brings in an existing code portfolio and discusses it. The second best way is someone completes multiple design and development exercises of varying complexity, constraints, and use cases. The t…

> The actual best method I think is a 3 month probationary period which is more or less an extended interview

Most states in the US have at-will employment terms. Probationary periods are common in other countries. And yet no one seems to want to do what you're suggesting.

Re: Tech Interview Handbook

#18

Post by triceratops » Sun, Aug 18, 2019, 2:57 AM UTC

codingslave wrote: post #4

Two outcomes for the technical industry: 1.) Everyone is studying these problems all of the time and they finally disappear. 2.) Other outcome is a dystopian field fueled by a race to the bottom where everyone is practicing algorithms problems all of the time. If you read the blind forums, some people are completing 500-1000 leetcode problems before heading into interviews. I'm putting my money on number 2, which is…

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

Re: Tech Interview Handbook

#19

Post by DavidWoof » Sun, Aug 18, 2019, 2:59 AM UTC

kthejoker2 wrote: post #10

Having hired dozens of devs, I can confidently say there is absolutely 0% chance to consistently successfully identify good developers in any reasonable amount of interviewing / assessment time period. The best way is someone brings in an existing code portfolio and discusses it. The second best way is someone completes multiple design and development exercises of varying complexity, constraints, and use cases. The t…

#1 is great, but impossible for a lot of people due to NDAs. The 3-month probationary period is indeed the only way to really evaluate devs, but I'm not so sure it's a good way to hire them. After 3 months, the mediocre devs have friends, etc., which makes it hard to get rid of them without creating a weird morale issue and massive team disruptions. And then you have to add in the limiting effect on the hiring pool (though I wonder if that really matters, I suspect good devs know who they are).

Number 3 is my favorite, but there's a trade-off: almost anything large enough to allow for multiple designs is probably too large to require all applicants to complete. But I also love having a candidate discuss their own code. I'm really curious what types of exercises you have for this kind of thing, and where it fits in the interview process?

Re: Tech Interview Handbook

#20

Post by leovander » Sun, Aug 18, 2019, 3:00 AM UTC

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…

I went to a Cal State, and I recall in the last few years Google has taken professors to their campus and pretty much preach Cracking the Code Interview. So it looks like schools are already making that their standard. I have yet to see what classes look like but I could see there being a required technical interview course you have to take in order to increase school’s numbers on where their alumni work.