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

81–90 of 344 posts

Re: Tech Interview Handbook

#81

Post by DavidWoof »

bradlys wrote: post #44
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…

I never had any technical interview prep when I started. I could code just fine. I demonstrated that at my other jobs and in school well enough. Then I started interviewing for SF positions that did these interviews. I froze up. I couldn't talk and think at the same time. I didn't have the skillset for doing this in a very intense scenario. In my case, I was homeless and needed a job ASAP. Every interview felt like l…

Whenever I ask coding problems during an interview, I emphasize any language at all including pseudocode. And if they still struggle, I ask if they could just walk me through it verbally and we can work out the syntax together.

I realize people can still freeze up, but at some point I think there's just no solution to that unless the candidate can produce a significant portfolio. Also, I read your post and it sounds to me like to gained confidence in this area as your coding skills improved, which I don't think is as much a coincidence as you seem to believe.

Re: Tech Interview Handbook

#82

Post by shivawu »

yumraj wrote: post #64
sthatipamala wrote: post #12

Earlier quoted context omitted.

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

I really hope this fails, something I have never wished for any other startup. At least personally in my hirings I'll never use or trust anything like this. There are so many things wrong with this approach that I'm kinda speachless as to where to start.

Why do you think it would fail? Curious about your reasoning

Re: Tech Interview Handbook

#83

Post by maehwasu »

numakerg wrote: post #32
DavidWoof wrote: post #21

Earlier quoted context omitted.

Slightly above market rate for the area, all in the low-to-mid six figures.

Was this a position where they were expected to write code? I'm surprised that developers making six figures couldn't solve a problem that an interviewer considered trivial. Any chance of a sample or maybe an alternate version of the problem?

I have had similar experiences as an interviewer. It’s one of those things that you really have to see to believe, but it’s definitely a real thing.

Re: Tech Interview Handbook

#84

Post by jjav »

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 have some special skill here but I really don't. This is just how interviewing was done in the 90s. To some of the younger generations, I've been told it sounds crazy.

If you send me your resume I'll actually read it, carefully. If the person described in this resume fits the background experience the role needs, you get an interview.

During the interview we'll talk about all those projects you worked on that are relevant to this role. Which parts you enjoyed the best and why? Which parts were boring and why? Which parts were the most challenging and why? What you find too easy and why? What would you have done differently? Could you have? If you were to do the same project all over how would you approach it? Other open ended conversations along these lines.

I don't ask anyone to whiteboard code, that's not part of the job so it's not part of the interview. No puzzles, no trivia-pursuit style questions.

It works great. You can't BS your way through such a conversation with a senior technical peer if you didn't actually do the work described in the resume. You just can't.

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

Re: Tech Interview Handbook

#85

Post by DavidWoof »

momokoko wrote: post #16
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.

It was very similar to the “given an array of stock prices, find the optimal buy and sell indices for the biggest profit" problem that somebody referenced above.

But we emphasized repeatedly we weren't looking for the O(n) solution, just the brute force naive solution was 100% OK. And it definitely didn't look like people were freezing up trying to figure out the optimal problem, they were struggling on the basic nested loop.

Re: Tech Interview Handbook

#86

Post by maehwasu »

yumraj wrote: post #64
sthatipamala wrote: post #12

Earlier quoted context omitted.

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

I really hope this fails, something I have never wished for any other startup. At least personally in my hirings I'll never use or trust anything like this. There are so many things wrong with this approach that I'm kinda speachless as to where to start.

Having a way that coders can avoid doing these types of coding problems over and over seems like a positive. Companies that aren’t interested in the approach could not use it.

Most companies today are already using a version of this that is way less respectful of applicant time.

But you’re speechless, so I guess there are strong points on both sides.

Re: Tech Interview Handbook

#87

Post by habitue »

closeparen wrote: post #73
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…

How often are you hiring people whose professional work is open source? How often are you hiring people for roles where their professional work will be open source?

the OP isn't saying it's always possible, just that it's the best way if it is possible

Re: Tech Interview Handbook

#88

Post by solipsism »

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

I don't get why no one seems to consider the possibility that these sorts of interviews actually do get high quality engineers in the door.

I get downvoted for raising the question every time. But isn't it possible this interview style actually works, even though it doesn't resemble real coding and even though many of us hate it?

I have yet to see any compelling argument for why I should believe these interview practices don't work. And yet the fact that so many companies, with so many resources to change things up if they felt it was in their best interest, keep interviewing this way must at least suggest the possibility that maybe it works?

Re: Tech Interview Handbook

#89

Post by seventhtiger »

closeparen wrote: post #57
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…

Bright high school students are vastly oversupplied compared to seats in elite colleges. Graduation rates are in the high 90s. There are many more than 5,000 kids who can handle the workload; which 5,000 you pick is arbitrary. Engineering competence is not even slightly oversupplied compared to useful engineering work. Project failures, incompetent people, and systematically incompetent orgs are still very much alive…

Admission at Georgia Tech has spoken on this online. Per their analysis, they can definitely differentiate the top 30% of applicants from the rest and it makes a difference in performance. Within the 30% they have found no differentiator that significantly impacts their academic performance.

So they have a full 30% of their applicants qualified to be there but they have to narrow it to 1%. Whatever method they choose must have the appearance of meritocracy, abide by laws and regulations, be resistant to corruption, achieve goals other than academic performance such as culture, volunteering, and sports, and so on.

I think the same must be true for companies. At some point in the elimination process everyone is technically qualified, so they might as well hire someone "because we like his face". But that's demoralizing and corrupt so they invent some criteria that on its face seems useful, even though it's truly not.

Re: Tech Interview Handbook

#90

Post by raincom »

agentultra wrote: post #62
dmoy wrote: post #23

Earlier quoted context omitted.

> Is this kind of code problem too complicated in your opinion? For all I join in when complaining about irrelevant algorithmic No. Just programming is actually not easy and a lot of people apply for jobs they can't do. Plus, a nonzero number of people freeze up in any interview situation. I once failed an interview loop because I forgot how bucket sort works.

Also 95% of job descriptions list skills candidates will never use and screen candidates with problems they will never encounter. At the final interview to join the SRE team at Google I was asked to implement the kNN algorithm. I barfed at implementing a kD-tree after regurgitating the brute force solution. Has any SRE ever had to implement a kD-tree in I asked the interviewer at the end. They had never implemented o…

They could be looking for those who participate in competitive programming contests.
Post reply on HN