Tech Interview Handbook • Hacker News Board

Re: Tech Interview Handbook

#261

Post by scarejunba » Sun, Aug 18, 2019, 5:16 PM 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…

Yeah but there's a difference. We're immersed in a state of better knowledge. It took centuries for us to go from the forms of knowledge that are "truth is self-evident" to "verification:of consequents is the pre-eminent method of knowledge acquisition" to "failure to reject falsifiable ideas is the best method to acquire knowledge". But I took that same path without reading the philosophers in approximately ten years. How? Because the cultural milieu is different. I am a unit of a more capable civilization and I am therefore enhanced.

So am I smarter than Karl Popper? Not really. It's just easier to learn something than to find it. So, yes, I know the linked list answer.

Re: Tech Interview Handbook

#262

Post by non-entity » Sun, Aug 18, 2019, 5:17 PM 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…

This is how much of my interviews have been and how I wish (however unlikely) my future ones will be. Unfortunately I rarely get to the interview stage of things as my resume is filtered out

Re: Tech Interview Handbook

#263

Post by Jach » Sun, Aug 18, 2019, 5:20 PM UTC

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.

Not exactly that, but you might like to peruse https://github.com/poteto/hiring-without-whiteboards

Reader beware, of course, I know at least one company on there shouldn't be.

Re: Tech Interview Handbook

#264

Post by raincom » Sun, Aug 18, 2019, 5:21 PM UTC

risubramanian wrote: post #8

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…

You joke, but I've seen several applications where I've been asked questions like "What achievement are you proudest of?" and "How would you contribute to the diversity of our team?". Also cover letters cover some of this. Actually, I wouldn't mind a standardized test like the GRE, where a good score might actually keep your resume from getting thrown out immediately.

If there were a standardized Programming GRE, it will end up increasing the competition for jobs thanks to the future Kaplan/Princeton/local training centers. What would companies do then? Start another layer of programming interview on top of this programming GRE. Eventually, we will reach a point where companies don't trust such GRE scores.

Re: Tech Interview Handbook

#265

Post by raincom » Sun, Aug 18, 2019, 5:24 PM UTC

yodsanklai wrote: post #166

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

There is nothing you could do. Just like when you are new to the dating world, you are just new to the recruitment world: when the company wants, they will send you emails, call you, etc. When you don't hear from them, don't even bother sending emails. That's why you should interview with multiple companies, in the hope that one of them will offer you a job.

Re: Tech Interview Handbook

#266

Post by raincom » Sun, Aug 18, 2019, 5:28 PM UTC

decebalus1 wrote: post #42

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…

I started leetcoding again this year because I want to jump ship and holy crap! I used to solve problems on leetcode 5 years ago (last time I switched jobs) and it was pretty laid back. Nowadays, I'm seeing dynamic programming with 3D memoization arrays like it's something normal. It all started like a way to check if someone knows how to write code or knows data structures and basic algorithms but now it's competiti…

That's what happens whenever there is a competitive exam. Look at math olympiad papers from 1970's, and compare them to the recent olympiad math test. Tougher than 1970s. It is the same about many entrance exams we see in China, India, etc: older exams are easier than the recent ones.

People just master the foundations behind the old test material. Now that stuff has become trivia of the today. So, they need some advanced stuff to test the test takers.

Re: Tech Interview Handbook

#267

Post by [deleted] » Sun, Aug 18, 2019, 5:29 PM UTC

bakuninsbart wrote: post #182

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…

As a very fresh junior developer, crafting a CV is extremely exhausting, because it is very hard to gauge what you can put in. Take git as an example: I used it for a couple of personal programs, read part of the documentation, had some errors and managed to get rid of them. I know the theory of how to use it on large projects. I even know enough to know that I'm pretty much just scratching the surface, but so are pr…

[deleted]

Re: Tech Interview Handbook

#268

Post by LanceH » Sun, Aug 18, 2019, 5:30 PM UTC

DavidWoof wrote: post #257

dorfsmay wrote: post #194

Earlier quoted context omitted.

Can you elaborate? What did he do or say that made you think he could do the job even though it looks like he wasn't able to work with other people code?

Not OP, but there's a group of people who have essentially a good manager's understanding of a project. They understand the trade-offs, they can talk intelligently about technical choices and architecture, and to some degree can even talk about individual modules and classes and language choices. But they blank at code and struggle with the basics. They get lost for hours at the most trivial bugs. It's weird, but it'…

I have (half?) jokingly said that hiring could be done by selecting people who try to right click something when confronted with a windows task they don't know how to do.

Re: Tech Interview Handbook

#269

Post by itronitron » Sun, Aug 18, 2019, 5:32 PM UTC

new299 wrote: post #41

lacker wrote: post #36

Earlier quoted context omitted.

Of course some people will consider that question to be too hard. But you may not want to hire those people. The point of an interview process is for you to pick the people you want to hire, not to ask questions that everyone agrees aren’t too hard.

I'm curious to hear the opinions of people who think that the question is too hard (i.e. it's too complex of a question to ask in an interview situation). Perhaps some people might feel that while they could write code to solve this problem (or similar problems) outside of an interview. However, under the pressure of an interview they would not be able to solve the problem (due to anxiety, stress etc.). If that was r…

a nested for loop is certainly not hard ... however ... they describe the problem as something we thought was a trivial nested for-loop problem which suggests that maybe it wasn't. if the problem was presented in a more abstract fashion, such as print all filenames 'within' a directory, then a candidate may have stalled on which approach to take.

also, someone who has only ever written code using lambda expressions might have difficulty writing a nested for loop

Re: Tech Interview Handbook

#270

Post by DavidWoof » Sun, Aug 18, 2019, 5:33 PM UTC

ryandrake wrote: post #253

norcalli wrote: post #118

Earlier quoted context omitted.

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.

This comment boils down precisely what I’ve always thought is the key problem in tech hiring. Companies overestimate the cost of a bad hire and underestimate the benefit of taking a risk and having it pay off. To borrow from poker: it’s commonly understood that if you’re not “caught bluffing” at least a little, it means you’re not bluffing enough. If your hiring process results in zero bad hires, you are playing it w…

I think you're wrong. I think companies are completely correct in assessing the cost of a bad hire to be much greater than the loss of a good hire, assuming you're getting enough good hires to fill the positions available.

Now, this assumes that you're not missing out on great hires; in other words, it assumes that the good hires you miss are at the bottom of your hiring range. Your point might be that this can't be guaranteed, and while that may be true, it's unlikely that any tweaks to a given hiring process are going to bring them in either.