Tech Interview Handbook • Hacker News Board

Re: Tech Interview Handbook

#151

Post by rhizome » Sun, Aug 18, 2019, 9:54 AM UTC

jishnum wrote: post #111

jjav wrote: post #108

Earlier quoted context omitted.

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.

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

Re: Tech Interview Handbook

#152

Post by lawn » Sun, Aug 18, 2019, 9:56 AM UTC

triceratops wrote: post #18

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?

Because these problems encourages you to write unreadable code. It makes sense when you write it, because you can fit it in your head, but you never have to revisit it after having passed the problem. It encourages one letter variable names and other quick hacks in the name of speed.

They work against creating readable, understandable and debuggable code which is much more important in general than being able to solve algorithimical problems you'll almost never see in real life.

I've seen this first hand where some were brilliant at these problems but wrote the worst code imaginable. I would rather hire someone who can write clean and simple code and teach them how to solve these problems than the reverse.

Re: Tech Interview Handbook

#153

Post by rimliu » Sun, Aug 18, 2019, 9:59 AM UTC

novok wrote: post #97

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…

It’s also very subjective and hard to train for or to audit externally. When a company gets too big, you can’t properly vet hiring personally anymore, so you have to scale it. You don’t want ‘bozo cliques’ to form, so you make a semi-objective process like ‘solve this algorithmic question’ as part of the interview loop. I think execs and the founders doing a final review before hiring all engineers comes from that fe…

Well, if you get too big to get things done well, maybe not get too big?

Re: Tech Interview Handbook

#154

Post by ozim » Sun, Aug 18, 2019, 10:00 AM UTC

EliRivers wrote: post #150

baddox wrote: post #122

Earlier quoted context omitted.

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…

My immediate reaction is that the problem with that approach is that it’s simply too expensive for the hiring company Is it? The cost of hiring the wrong person can be huge. Not just agency fees if they came through a recruiter (those aren't cheap!), but also all the time people then spend on the bad employee and all the damage that person does before the mistake is rectified. If this system of reading the resumes an…

If it really would be, then current state of things would not go into "making it cheap". I think for entry level employee, or just a regular employee, cost of bad hire is not that high. If turnover on those positions is high, then it also makes things cheaper just to fill in the seat.

I have seen not that brilliant employees that still were earning company money. Just you know "we hire only best of the best" is a scam.

Hiring bad manager or a senior dev, can be bad I agree. So it is not so good to use the same hiring way for seniors and juniors, but unfortunately companies treat senior devs also like juniors.

Re: Tech Interview Handbook

#155

Post by rimliu » Sun, Aug 18, 2019, 10:02 AM UTC

lolptdr wrote: post #94

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…

Thank you for your refreshing point of view. I'm a mid-level software developer and I was on the other side of the table as a junior web developer and encountered this same style of questioning and embraced it. This is my go-to style when interviewing because if you are confident in the lingo and zeitgeist of development, there is no way they can bullshit there way and lie through their teeth on their own experiences…

Exactly. If you were really working with the stuff you do you will know all the common pain points, workarounds, etc. Unless the interviewer is alien to those things themselves there can be instant "one of us" recognition.

Re: Tech Interview Handbook

#156

Post by username90 » Sun, Aug 18, 2019, 10:03 AM UTC

lawn wrote: post #152

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?

Because these problems encourages you to write unreadable code. It makes sense when you write it, because you can fit it in your head, but you never have to revisit it after having passed the problem. It encourages one letter variable names and other quick hacks in the name of speed. They work against creating readable, understandable and debuggable code which is much more important in general than being able to solv…

> I would rather hire someone who can write clean and simple code and teach them how to solve these problems than the reverse.

Why? Teaching people to write readable code happens automatically during code reviews, teaching people how to think is a lot harder.

Re: Tech Interview Handbook

#157

Post by wincent » Sun, Aug 18, 2019, 10:06 AM UTC

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…

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.

Re: Tech Interview Handbook

#158

Post by fogetti » Sun, Aug 18, 2019, 10:07 AM UTC

username90 wrote: post #148

fogetti wrote: post #144

Earlier quoted context omitted.

That's an interesting theory. But this problem is actually not confined to the industry, it impacts academia too. Even just as a purely theoretical statistical problem since there is enough data and easy access to that data we should already have some research in this field which sheds some light on the hiring issue.

You have everyone's interview scores, performance feedback and promotion histories in a database at a company with tens of thousands of employees. You also have the interview scores for everyone who failed the interview process. Put a statistician on that for a day and you will get a lot of significant data about your hiring pipeline. It is not hard to do, the data just isn't public and such data will never become pu…

I didn't want to call it bullshit but you are not the first who wants to walk me down the bullshit lane.

Here is the thing: this discussion is not about scores or about candidate performance. It's about the question whether the same candidate would be better assessed with a technical interview over a non-technical interview. Since you are not even addressing the question at hand I call it bullshit.

Also, something which has no written proof of and there is no consensus about among at least a group of respectable people and/or institutions is just a theory.

And the third one, you somehow assume that public sector is somehow an inferior player to the market who might not even have relevant data. That's again a theory though and not necessarily correct, here are a few examples of publicly funded software engineer employers: CERN, NASA and the US Army.

Re: Tech Interview Handbook

#159

Post by supercanuck » Sun, Aug 18, 2019, 10:10 AM UTC

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…

>It is, however, vital that the interviewer must be a expert in the field.

This is key. There are a lot of hiring managers masquerading as experts and are frustrated when cargo culting hiring processes falter and lack the people skills to diagnose a situation. You'd also be amazed at the quality of resumes a high, advertised salary will bring.

Re: Tech Interview Handbook

#160

Post by new299 » Sun, Aug 18, 2019, 10:14 AM UTC

PeterisP wrote: post #140

new299 wrote: post #28

Earlier quoted context omitted.

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…

Your problem actually is a good illustration of the whiteboard test problems. I just tried it, and it was trivial to do in a minute or two on my laptop. However, I did took note of two syntax mistakes that I made in the python REPL that were immediately obvious there and took seconds to fix, but which I most likely would not have noticed on a whiteboard. So there's quite a bunch of problems where if the acceptable "f…

Do you think you could rough out an answer on a whiteboard that would have roughly the right structure?

When I used this question I wasn't looking for accurate syntax. If it was a solution that looked like it would work, after some debugging etc. I'd consider that a pass.

Regardless most people couldn't answer it, which I considered surprising.