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

51–60 of 344 posts

Re: Tech Interview Handbook

#51

Post by [deleted] »

sthatipamala wrote: post #12
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…

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

[deleted]

Re: Tech Interview Handbook

#52

Post by xtracto »

jiux wrote: post #25

I once interviewed at a startup for a senior engineer position and was asked “if aliens came to Earth and asked you to go into their UFO with them, would you?”... As much shit as we give white-boarding, I would have chosen it instead if it were an option.

At one time i was asked "why do frogs croak? I gave a series of answers like: to attract the opposite sex, gave some biological explanation of how they achieve that. But the stupid interviewer kept asking me why?

Needless to say after the interview ended i ran away from that deal.

Re: Tech Interview Handbook

#53

Post by povertyworld »

triceratops wrote: post #39
_hardwaregeek wrote: post #37

Earlier quoted context omitted.

Because you get the college applications problem, where you stop getting the people who have a real passion for programming and coincidentally have problem solving and algorithms skills, and start getting people who are really good at problem solving and algorithms and may or may not have a passion for programming.

> start getting people who are really good at problem solving and algorithms and may or may not have a passion for programming. Why is "passion" so important? And what even is passion? For professionals in every other field, competence, ability to deliver results, and getting along with people, are what matter. Many pros are passionate, in the sense of loving their work, but passion isn't a prerequisite for being a p…

Most programming is not solving tricky puzzles, but grinding out code.

Re: Tech Interview Handbook

#54

Post by new299 »

bpchaps wrote: post #45
new299 wrote: post #41

Earlier quoted context omitted.

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…

The fizzbuzz test is not entirely about whether someone can do it. It's also about figuring out the style of the programmer. There's a surprising amount of flexibility to fizzbuzz; how is user input handled? Do they use a linter? How are variables managed/named? There's a lot going on, and it can be gamed just like anything else on both ends. That said, the last time I had a fizzbuzz take-home test, it was infuriatin…

I guess it depends how you use it. I started hearing about FizzBuzz in the context of "why can't programmers program" [1]. I.e. that many interview candidates can't solve this problem.

It's also my experience interviewing programmers (outside SF) that most candidates can't solve simple FizzBuzz style questions. As a take-home test, I agree I can't really see the value in it.

[1] https://blog.codinghorror.com/why-cant-programmers-program/

Re: Tech Interview Handbook

#55

Post by triceratops »

povertyworld wrote: post #53
triceratops wrote: post #39

Earlier quoted context omitted.

> start getting people who are really good at problem solving and algorithms and may or may not have a passion for programming. Why is "passion" so important? And what even is passion? For professionals in every other field, competence, ability to deliver results, and getting along with people, are what matter. Many pros are passionate, in the sense of loving their work, but passion isn't a prerequisite for being a p…

Most programming is not solving tricky puzzles, but grinding out code.

> most programming is not solving tricky puzzles, but grinding out code.

Sounds like most jobs need dispassionate guns-for-hire who'll do excellent work, no matter how tedious, get paid, and go home. In other words: pros.

Re: Tech Interview Handbook

#56

Post by strikelaserclaw »

For all the negativity for these type of tech interviews, they are, from what i've seen, one of the most merit based systems out there. It is either this or we need to create some sort of national developer exam. The other alternate is to get jobs at good companies, they will only look at what school you went, whether you graduated with a CS degree, what companies you worked etc... All things which do not guarantee merit.

Re: Tech Interview Handbook

#57

Post by closeparen »

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 at the most selective tech employers. There are real business needs to hire better engineers.

Re: Tech Interview Handbook

#58

Post by new299 »

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…

This is a really interesting observation, thank you.

Is there anything they could have done differently to make the situation easier? (I would guess perhaps giving you more notice about language requirements?). Or is there a different interview format that you feel would have worked better?

Re: Tech Interview Handbook

#59

Post by jjav »

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?

This race to the bottom, as parent poster said, is from a generation of developers hyper-specializing in interview-style problems. These problems are tiny and self-contained and have a slick solution which can be regurgitated onto a whiteboard in about 30 minutes give or take.

While that is not a negative skill to have, it is also not a skill that I'd list anywhere in the Top-25 of most valuable skills for productive developers.

Re: Tech Interview Handbook

#60

Post by [deleted] »

triceratops wrote: post #55
povertyworld wrote: post #53

Earlier quoted context omitted.

Most programming is not solving tricky puzzles, but grinding out code.

> most programming is not solving tricky puzzles, but grinding out code. Sounds like most jobs need dispassionate guns-for-hire who'll do excellent work, no matter how tedious, get paid, and go home. In other words: pros.

[deleted]
Post reply on HN