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

171–180 of 344 posts

Re: Tech Interview Handbook

#171

Post by alkonaut »

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…

If you risk having a bullshitter you need some way of identifying them. The best way is through references, personal projects etc.

But if you need to recruit someone without any such credentials then you may need to do a simple coding aptitude test. Could be a code review or a simple excercise but whatever you do, don’t do whiteboard coding and don’t have people recite/implement memorized CS textbook algorithms. Anyone can do that and still no code.

Re: Tech Interview Handbook

#172

Post by dustfinger »

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…

> Everyone has the same canned answers to the stupid behavioral questions.

If the person conducting the interview thinks the behavioral questions are stupid, then perhaps they are. In that case, don't ask "stupid" behavioral questions.

> Resumes are meaningless, and often re-written by recruiters to match the job anyway

Was the position entry level? Students coming right out of compsci often have little to no practicable experience. They may have difficulty thinking about what to put in their resume. After one or two years of full time experience that should no longer be an issue.

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

Asking those "stupid" behavioural questions and receiving the same canned answers also demonstrates a willingness to study for an interview.

The coding problem should be testing a candidate's problem solving capabilities as practicably required by the role being interviewed for. The chosen problem should reflect the types of problems that they will actually need to solve if hired. For example, you could select a small PR from one of projects being actively developed by the company. The selected PR should involve only one or two classes (assuming a language with classes) and require improvement. You can look through the history of a PR and just pull out a segment that was selected for improvement by the reviewer(s), or have the team select it for you. Then ask the candidate:

- to conduct a code review of the PR

- to improve the code

Re: Tech Interview Handbook

#173

Post by ritchiea »

wincent wrote: post #157
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…

These questions should definitely be part of the interview process, but not all of it. I've done a lot of these kinds of interviews and I've definitely seen candidates that speak impressively but fail basic technical tests. If you don't actually verify the technical problem-solving ability of the candidate in some way you're forgoing signal that can massively increase the confidence you can have in your decision.

I’ve failed technical tests because I found the interview process stressful, or felt nervous or uncomfortable in the moment or was having a bad day. I recently did a round of interviewing for jobs and realized the real key for me was handling my emotions in these situations so I can bring the same approach I bring to my work to the interview. And it’s not the same as your day to day work because if I’m writing an algorithm or solving a problem at work finding the solution usually happens in my head rather than out loud. This difference is meaningful.

After a few bad interviews I got the hang of it and aced a couple algos interviews. I’ve worked as a developer for 8 years, have tons of software in production, have some open source contributions and have worked productively on several teams.

Interviewing is a skill. I understand why a company wouldn’t hire someone who doesn’t pass a programming test but failing a programming test doesn’t mean you can’t do the job.

Re: Tech Interview Handbook

#174

Post by detaro »

rhizome wrote: post #151
jishnum wrote: post #111

Earlier quoted context omitted.

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.

Does anybody even know anything about these resume filters? They seem legendary, or I'd think there would be a best practice by now.

Various vendors of software in that space claim they are best practice, e.g. IBM: https://www.ibm.com/talent-management/hr-topic-hub/applicant..., https://appsource.microsoft.com/en-us/product/web-apps/cem_b... promotes keyword matching as a feature, ...

Re: Tech Interview Handbook

#175

Post by maehwasu »

ixtli wrote: post #27

What if people not being able to answer simple programming questions is a problem with the interviewers, and not the interviewees?

This is one of those ideas that sounds really sophisticated, but is just wrong.

The fact is that there a tons of people out there representing themselves as programmers who actually can’t perform basic tasks.

The HN population massively selects for competence, so people here have a hard time imagining what things are like from the interviewer side.

Re: Tech Interview Handbook

#176

Post by AmericanChopper »

DavidWoof wrote: post #19
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 (…

> 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

I’ve seen this mistake happen so many times. Especially in early stage start ups. If you want morale issues and disruptions, you’ll achieve it 100% of the time by retaining underperforming staff. Even worse, this ultimately leads to your best team members leaving if it’s an issue you can’t solve. Fail fast applies to HR too, you need to learn to fire fast.

Re: Tech Interview Handbook

#177

Post by darkerside »

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

Have you let new hires go in the first 90 days? That's just one of the ways personal regret is probably not the best metric here.

Re: Tech Interview Handbook

#178

Post by detaro »

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…

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

How did you run these? While it sounds like something that should be ok even on paper, you can vary comfort a lot through the medium. E.g. for the last interview I had with a substantial coding part, I think being able to do it on my personal machine made a big difference. (I obviously was told before what kind of environment I'd need to have ready)

Re: Tech Interview Handbook

#179

Post by libria »

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…

> nested for-loop problem

> > No puzzles, no trivia-pursuit style questions.

I swear HN technical interview threads are the poster child of talking past one another. First, for-loop is nowhere near a trivia-pursuit question. Second, different companies of different sizes/industries/goals have different requirements. Let's all move forward with this discussion and acknowledge that we can't all use the same process because we're not all hiring for the same type of job. If the engineers you hire consider for-loops a "puzzle" that's totally fine and OP using it doesn't invalidate your process for your multi-national or startup companies.

> I can say that I've never regretted a hire I said yes to

The real question is, has anyone else regretted that hire, which unfortunately can't be answered as they may not tell you.

> To some of the younger generations, I've been told it sounds crazy.

Doesn't sounds crazy at all. A single process guaranteed to work for everyone? Now that sounds crazy.

Re: Tech Interview Handbook

#180

Post by kidintech »

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…

Am I misunderstanding your problem, or would this be a valid solution: https://pastebin.com/GWKr4AQ8

If so, then the company you're interviewing for must not be attractive to first-class CS grads (top 10-20% I think) from any non-online university.

As a comparison, any FAANG + Palantir/Jane Street/Two Sigma in the UK have tougher questions as their FIRST phone interview for INTERNSHIPS. (Palantir requires you to go through 6-8? interviews before getting an offer)

If this is a job that requires actual software engineers, I think rejecting everyone that failed this question would be perfectly reasonable.

Post reply on HN