Tech Interview Handbook • Hacker News Board

Re: Tech Interview Handbook

#161

Post by dustfinger » Sun, Aug 18, 2019, 10:15 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…

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

May you please post the problem so that we can provide you with meaningful feedback regarding said problem?

Re: Tech Interview Handbook

#162

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

fogetti wrote: post #158

username90 wrote: post #148

Earlier quoted context omitted.

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 wh…

> It's about the question whether the same candidate would be better assessed with a technical interview over a non-technical interview.

I don't understand the problem here, all technical interviews are also non-technical interviews since they are still communicating with a human and not just doing problems on a computer. If we didn't care about the human interaction part we'd just put them in a room alone with a set of problems.

Also I think you don't understand how much recruiters hate this process, they'd do anything to remove it since they have no way to game technical interviews. So they work hard to change the interview process at Google to something more soft like we have in other areas, but the evidence points to soft interviews being worse.

And you might not believe me, but I definitely believe me and the people deciding how to hire people at these companies certainly believe in the studies they do, so there is no way they will change the process. These interviews are here to stay, and until we have some new methods nobody has tried yet it won't change. You can complain all you want, but the best companies will be using this process as they scale up since nothing else works at the moment. Some other things might work for small companies, but as soon as the founder can't interview everyone himself it breaks.

Re: Tech Interview Handbook

#163

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

Consultant32452 wrote: post #114

DavidWoof wrote: post #93

Earlier quoted context omitted.

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…

I do a lot of consulting as well and am comfortable with it. But most people with families want more stability. I don't know why you're pretending to be surprised by this.

Your personal preferences aren't really the topic at hand.

Re: Tech Interview Handbook

#164

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

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.

Anecdotal but we've hired an engineer who was pretty decent in the interview but couldn't figure out how an if statement worked in a legacy codebase.

Yes, I wrote that right. He struggled to understand conditionals in general when building his own logic. The guy even had a masters degree.

Re: Tech Interview Handbook

#165

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

new299 wrote: post #160

PeterisP wrote: post #140

Earlier quoted context omitted.

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.

Sure, the structure is obvious; one was an issue of a method being named differently than I remembered, the other was an off-by-one error that'd show up in testing.

Re: Tech Interview Handbook

#166

Post by yodsanklai » Sun, Aug 18, 2019, 10:34 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…

> some people are completing 500-1000 leetcode problems before heading into interviews.

Over the course of one year, I completed, classified, commented 200 leetcode problems. I also taught algorithms to third and fourth year university students not too long ago. I believe I write readable code, I know perfectly the language I'm using (at least for that purpose), I'm totally fine with complexity, and I know most methods involved in these algorithms, including more advanced algorithms such as KMP.

Yet... I failed my round of interviews at Google. After this preparation, I'm still not able to solve quickly any leetcode problem in the context of an interview. On a whiteboard, with an interviewer in my back, in a stressful situation. I need to practice more if I want to get consistent results.

So I agree with your conclusion. We are competing with a lot of people who train using the same resources. Including young graduates who have a lot of free time on their hand.

On a positive side, I'm thankful to Google for giving me a shot. Based on my resume (40+ with little experience in software industry), I'm not sure I would have been interviewed in a more traditional company, let say a bank.

To come back to my interviews, system design went very well. Algorithms quite well too but not well enough. Couldn't solve one problem, and a bit slow on an other one.

The recruiter first told me I passed, and that they were going to find a team for me and make me an offer. But they finally asked me to re-take the algorithmic interviews a few months later, to "make a stronger point to the hiring committee".

Never heard from them since then, about 8 months ago. Recruiter doesn't answer emails. I think she moved to a different position. Not sure what to do now?

Re: Tech Interview Handbook

#167

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

rimliu wrote: post #153

novok wrote: post #97

Earlier quoted context omitted.

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?

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

I love this idea but my old history professor (who I pretty much disagree with on everything except this) used to always say "follow the money". What are the incentives that all the parties have for and against growing companies bigger?

Re: Tech Interview Handbook

#168

Post by boltzmann_brain » Sun, Aug 18, 2019, 10: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…

Actually there is a better way assuming a candidate with experience: discuss what they did, ask questions like: "why did you chose this solution?", "what were the main challenges you encountered?", "how would you change your solution in hindsight?", etc. There is no way to bullshit through this or such attempt will be quickly clearly apparent.

Re: Tech Interview Handbook

#169

Post by rapht » Sun, Aug 18, 2019, 10:58 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…

I don't work in tech (though I sometimes think about uuyýjmq

Re: Tech Interview Handbook

#170

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

goatinaboat wrote: post #107

non-entity wrote: post #43

Earlier quoted context omitted.

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 was like this a couple years ago. I was a self taught, "college is a scam", "practical experience" type guy. I now, however do see immense value in the ability to be able to work through these algorithm questions,especially if you ever want to do something besides web / app develo…

Algorithms are great but in the real world what matters is being able to recognise a class of problem then go to the literature e.g. Knuth to find the right one. No working programmers know every algorithm off the top of their heads. The classic detect a loop in a linked list question. The original guy took years to devise the algorithm for it. In an interview either you’ve seen it before, in which case you rattle it…

This. The problem a programmer needs to solve isn’t remembering or applying the algorithm, it’s identifying what needs to be done.

“This problem is (analogous to) loop detection”

“This problem requires a sorted list”

“This problem can be solved by depth first traversal”

Actually sorting a list or doing a traversal is easy after that crucial step. You can look it up. You can’t look up the step that told you what algorithm or data structure to use though.