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

21–30 of 344 posts

Re: Tech Interview Handbook

#21

Post by DavidWoof »

ale22 wrote: post #14
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…

How much were you paying for these positions?

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

Re: Tech Interview Handbook

#23

Post by dmoy »

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

Re: Tech Interview Handbook

#24

Post by andrewstuart »

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…

>>> how you think it should be done. Because I have to admit I'm pretty much lost right now.

- Treat recruiting in the same way as you do software development.

- Formulate a set of requirements.

- Define interview questions that give insight into whether or not the candidate meets those requirements. This is the equivalent of "tests" in the software process.

- Specific skills with your technology stack is good, but not necessarily essential.

- Ability to discuss sophisticated software concepts, and to explain software that they have built, and how they would build out ideas given to them is good.

- Evidence that this person gets stuff done is good (ref Joel Spolsky).

Coding tests are, for the most part, garbage. Not because the test is of no value, but because you the employer probably don't evaluate the result properly.

Re: Tech Interview Handbook

#25

Post by jiux »

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.

Re: Tech Interview Handbook

#26

Post by UnpossibleJim »

triceratops wrote: post #17
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…

> The actual best method I think is a 3 month probationary period which is more or less an extended interview Most states in the US have at-will employment terms. Probationary periods are common in other countries. And yet no one seems to want to do what you're suggesting.

The problem is, most companies in the US want to hire you on as a Contractor and not a full time employee for those three months. I can't speak for everyone (but most folks, I assume), but I need medical and dental. I can't go three months for the chance of maybe getting it. I can't do it personally and i can't do that sort of thing to my family. there are other options in other countries (depending on the country). I'm a centrist by nature, but this makes a "three month interview" untenable, IMO.

Re: Tech Interview Handbook

#28

Post by new299 »

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…

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, people who could not solve this were hired for other teams. Based on their performance, I don't think I would have been comfortable working with them.

I don't think it's unreasonable. But I'm not sure I'd use it as a screen if I was hiring now. I think I'd just have a chat and try and discuss a previous project. After that I'd move to a paid take home project (ideally representing real, useful work).

[1] Take a string, for example "ABCCABC" and count the number of times each 3 character substring occurs. In this case the answer would be 2xABC 1xBCC 1xCCA 1xCAB.

Re: Tech Interview Handbook

#29

Post by chrisseaton »

rvz wrote: post #2

While this is very good to study before a technical interview, over time however I can see that this alone is going to make it 40x harder to differentiate say 100 candidates that are all perfect at interviews in general, that we are going to start asking ridiculous Oxbridge-style interview questions and expect perfect scores to advance 'good' candidates. Perhaps companies will start asking candidates to construct mat…

> Perhaps companies will start asking candidates to construct mathematical proofs of data structures, algorithms

Perhaps we’d produce better software if people prioritised correctness like this in practice!

Re: Tech Interview Handbook

#30

Post by _hardwaregeek »

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…

Where are you posting your jobs? Are you paying a recruiter? How much? Maybe you could have interviewers rank candidates (hire; competent, but no hire; slightly incompetent; how did they get here?), then see where the majority of your "how did they get here?" candidates come from.
Post reply on HN