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

301–310 of 344 posts

Re: Tech Interview Handbook

#301

Post by farah7 »

shagie wrote: post #217
winrid wrote: post #110

Earlier quoted context omitted.

Phone screens should prevent those candidates from ever getting onsite. You'd be surprised (or maybe not now) how many applicants for a senior frontend position can't build a progress bar for the phone screem.

I've given phone screens to individuals who turned out to be a different person when they showed up onsite. Not "nice on phone, jerk in real life" but rather "Bob does the phone screen for Charlie (and passes), Charlie shows up at the onsite."

I usually have video off during phone screens. Do you require them on?

Re: Tech Interview Handbook

#302

Post by AmericanChopper »

bradleyjg wrote: post #210
AmericanChopper wrote: post #176

Earlier quoted context omitted.

> After 3 months, the mediocre devs have friends, etc., which makes it hard to get rid of them without creating a weird morale issue and massive team disruptions I’ve seen this mistake happen so many times. Especially in early stage start ups. If you want morale issues and disruptions, you’ll achieve it 100% of the time by retaining underperforming staff. Even worse, this ultimately leads to your best team members le…

It's true that keeping on terrible employees is worse than firing them, but that's the answer to a different question. The question at hand is should you opt for a system you know is going to involve a lot of firing fast, or do your best to avoid bad hires even at the cost of a higher false negative rate?

Hiring and firing are expensive in a whole lot of different ways, but it takes time and effort to get right, and you’ll never get it right every time. So actually using the probationary period properly, and getting good at firing people are things you’ll have to do anyway.

Re: Tech Interview Handbook

#303

Post by rhizome »

nimrody wrote: post #101
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…

One company sent me (before the interview) a small technical assignment. After I had submitted the code, an interview was scheduled. The entire interview was an extended code review -- talking about trade-offs, about other potential solutions, etc. I felt this was much better in that it was less stressful, yet allowed me to demonstrate both knowledge and design skills. Another company did something similar but more t…

I've been thinking for a while that companies should create their hiring tests from bugs and/or feature requests that came from their actual software in the past. Then they can gauge the quality of the employee for their purposes by comparing the candidate's solution(s) to those the actual employees wrote.

Re: Tech Interview Handbook

#304

Post by rhizome »

detaro wrote: post #174
rhizome wrote: post #151

Earlier quoted context omitted.

Does anybody even know anything about these resume filters? They seem legendary, or I'd think there would be a best practice by now.

Various vendors of software in that space claim they are best practice, e.g. IBM: https://www.ibm.com/talent-management/hr-topic-hub/applicant... , https://appsource.microsoft.com/en-us/product/web-apps/cem_b... promotes keyword matching as a feature, ...

Oh sure, I know they exist, but on the resume side there's no common knowledge of anything besides keyword stuffing. I'm wondering if that's actuallly the best way given how the filters actually work (which I don't know).

Re: Tech Interview Handbook

#305

Post by anon44 »

choppaface wrote: post #80
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 agree a code test is necessary. I’ve seen several panels neglect to do a code test, the candidate was hired, then within a month fired because it was clear they couldn’t do anything (other than, well, argue). I’ve been in a panel where I was the only person who asked a code question, the candidate flunked, and then the VP of Engineering went over my complaints and hired the guy anyways. He had been a Professor of S…

I once had an interviewer who said my O(N) solution was actually O(2N), so my solution is wrong. There algs interview evaluations are very, very subjective and inconsistent. If places like google actually cared about getting good candidates they would have standardized tests instead.

Re: Tech Interview Handbook

#306

Post by zerr »

Jach wrote: post #263
zerr wrote: post #112

Earlier quoted context omitted.

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.

Oh, I see, they use the term "whiteboard" as a synonym for leetcode-like riddles.

Re: Tech Interview Handbook

#307

Post by alibarber »

dccoolgai wrote: post #299
mjfisher wrote: post #273

Earlier quoted context omitted.

I'm curious about the codepad/codeshare approach right at the first touch point. I fully agree that screening actual tech skill early on is important. Do you not find that you commit a lot of engineer time to codeshare interviews that don't work out further down the line?

Another idea I've heard about but never got motivated enough to set up is a system wherein the applicant submits their resume via an api with some kind of trivial challenge... like "here is an id and an integer, multiply it by 2 and submit it with the id and your resume as a json with these fields or whatever." Might try it some day, but that's another idea to get some of the technical probe out early.

There's a company, I think it's Mythic Beasts in the UK, that has or had a job application that had something along the lines of (before you got to the form) 'first prove you're not a robot do this simple maths blah...' but every time you submitted your answer, by typing in and clicking on the page, you got an error page saying 'too slow'. I wasn't looking for a job at the time but that has to easily be my favourite application process ever!

Re: Tech Interview Handbook

#308

Post by applechen777 »

This thread has been a great discussion. We are a startup and did hiring ourselves. We gave 1) algorithms, system designs type on questions 2) a mini project like build a profile in React Native. With 10 sample size, we found people who finished the project quickly and reasonably performed well at work while candidates who passed algorithms didn’t grow as fast.

The main thing is the problem solving oriented skills in a project that really makes a difference.

Thus, we pivoted to do a mini project screening automation for companies to do hirings. This site has backend to frontend tasks that come with a CLI to code the project locally. The website is called https://real.dev. We want to solve this interview problems for companies.

Re: Tech Interview Handbook

#309

Post by thelazydogsback »

> ... nobody needs to know: > Anything less recent than 3-4 years

Really? I did the most interesting and challenging projects earliest in my career (late 80's to early 2000's) -- just due to the nature of the industry, I'd think that more recent project descriptions have undergone a certain homogenization that would make them less and less an indicator of talent and varied experience.

I can chat excitedly about early projects, but now people must all be saying "cloud blah JS blah containers blah blah bit-pipes and storage blah - oh yeah, and modands!"

Re: Tech Interview Handbook

#310

Post by new299 »

mixmastamyk wrote: post #287
new299 wrote: post #79

Earlier quoted context omitted.

Is reversing a string not already "the basics"? What are you suggesting should be covered in an interview/screen prior to a trial period?

Your question was not reversing a string. You also mentioned fizzbuzz.

It’s the problem under discussion in the post you are replying to.
Post reply on HN