Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Method I’ve Used to Eliminate Bad Tech Hires

mattermark.com

Post reply on HN
Print view View original

271–280 of 517 posts

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#271

Post by codeulike »

deepaksurti wrote: post #269

>> They refuse to do the project because “someone will hire me without it”. This is wrong in certain cases. The candidate may have significant contribution to an open source project or may have shipped an open source project as an owner. Why should that candidate not refuse? You already have the code in front of you. If you as an employer cannot take the time out to go through that and evaluate what you would otherwi…

But the method proposed is only 20% about code. It's mostly about seeing how someone approaches a piece of work and discusses a solution in a meeting. You can't get that from browsing GitHub.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#273

Post by stillworks »

TeMPOraL wrote: post #250
stillworks wrote: post #248

Earlier quoted context omitted.

Interesting to note how different people are indeed. I am fine with white board type situations, don't worry about writing code without IDEs etc (in my very first job vi editor was the only thing we had to write code so I still have instinctive memory to be resourceful without an IDE but I love IntelliJ for most things). Happy to discuss/draw out ideas/solutions on whiteboards. But find it very seriously annoying tal…

Indeed interesting how different people are. Here, I'm like you. But it carries over to normal job - I work best when left alone. Especially when I have a tough problem to solve, just having people sitting close to me makes me frustrated, and if they're talking, then I won't be able to concentrate at all. It takes a lot of energy for me to be able to work in the presence of other people.

I understand where you are coming from...

I think somehow the world was agreeable enough to drink the Pair-Programming KoolAid. The consulting companies or body shops were happy since they could bill 2x the number of heads for the same amount of time. The "buy-side" of Pair Programming were happy because the KoolAid evidently worked.

Don't get me wrong, I am all in favor of getting my code eye-balled by anybody because I know I don't write perfect code 100% of the times and always open to critique and learning.

Here's a thought experiment. Have two teams A and B. A are pair programmers i.e. |A| = 2*|B|.

Now make team A don't do any unit testing, let them purely rely on pairing to ensure quality.

Enforce team B to do TDD to the best of their efforts.

I would be personally very interested in knowing where the consumer of the code and writers of the code have more confidence on code quality and functional completeness.

Open-plan offices are hip and in Europe maybe even a requirement due to space constraints but I'd personally choose a cubicle over higher pay.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#275

Post by happywolf »

jobu wrote: post #231
blazespin wrote: post #172

Earlier quoted context omitted.

This works, but make sure they spend the 2 hours in your office and not 12 hours at home solving a 2 hour problem.. The other problem is that when you pay them you generate all sorts of nightmaris legal liabilities.

> The other problem is that when you pay them you generate all sorts of nightmarish legal liabilities. I was wondering about the tax and legal implications around paying someone for an interview challenge as well. The overall idea seems fantastic, but paying or receiving money for an interview coding challenge is a little weird.

We can treat that as a consultation gig which may lead to an offer. It is up to the candidate to declare this income to the tax authority.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#276

Post by pgl »

ceronman wrote: post #142

This is a great way of hiring, but unfortunately it doesn't fit in all scenarios. First, this model alone doesn't scale. Big companies interview hundreds of candidates every week. It's not possible to design and evaluate a weekend project for each one of them. This doesn't mean that they can't have projects, but early filters are needed. That leads to the classic phone and F2F interviews to rule out those who can't c…

> It's not possible to design and evaluate a weekend project for each one of them

Can't you just design and evaluate one project that they can all do?

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#277

Post by TeMPOraL »

stillworks wrote: post #273
TeMPOraL wrote: post #250

Earlier quoted context omitted.

Indeed interesting how different people are. Here, I'm like you. But it carries over to normal job - I work best when left alone. Especially when I have a tough problem to solve, just having people sitting close to me makes me frustrated, and if they're talking, then I won't be able to concentrate at all. It takes a lot of energy for me to be able to work in the presence of other people.

I understand where you are coming from... I think somehow the world was agreeable enough to drink the Pair-Programming KoolAid. The consulting companies or body shops were happy since they could bill 2x the number of heads for the same amount of time. The "buy-side" of Pair Programming were happy because the KoolAid evidently worked. Don't get me wrong, I am all in favor of getting my code eye-balled by anybody becau…

I'd love to see that experiment, as I'm actually more inclined to believe in (occasional) pair programming (by the virtue of enforcing some focus) than in TDD.

> Open-plan offices are hip and in Europe maybe even a requirement due to space constraints but I'd personally choose a cubicle over higher pay.

Yeah. When I was still a high-schooler and later a university student, I used to laugh at cubicles. Oh, the corporate culture, oh, the rat race, etc. Now that I spent some time in this career, I would voluntarily go to cubicle and even take a pay cut. I now understand that cubicles were a good idea of solving the space/cost constraints.

Hell, every now and then I think about building my own cubicle out of pizza boxes, but I'm pretty sure the management wouldn't be happy about it. Over-the-ear headphones suffice for eliminating sound for now, but I still can't focus when I have people walking behind my back.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#278

Post by StreamBright »

pakitan wrote: post #259
StreamBright wrote: post #254

Earlier quoted context omitted.

Sorry but this is simply not true. After a while we decided to do exactly the thing that the article describes as our preliminary interviewing process at Amazon. We also had extensive onsite interviews, however we did not ask candidates to code at the whiteboard. Btw, when you work for such companies it is expected that you spend 10% of your time on hiring. Getting hiring right is one of the most important things tha…

I'm curious if you have any statistics about the different interview styles/processes. Obviously it's hard to figure out the false negatives (good engineers you didn't hire) but how about false positives? Also, is homework assignment now a part of the standard interview process at Amazon or is this just your team/department?

Sorry but no stats. Amazon has different hiring procedures for different teams. This was for a particular team in one branch.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#279

Post by ubernostrum »

blazespin wrote: post #172
zachd1_618 wrote: post #49

This. 100% this. As many others are saying, I find that this is the most comfortable way for me as an interviewee to demonstrate that I do in fact know what I'm talking about. Put me in front of a room full of people and a whiteboard and throw something at me, and I'll freeze. Freezing in that situation and being a bad engineer are wholly separate things. Anecdotally, when I get one of these problems, I spent 20 minu…

This works, but make sure they spend the 2 hours in your office and not 12 hours at home solving a 2 hour problem.. The other problem is that when you pay them you generate all sorts of nightmaris legal liabilities.

This works, but make sure they spend the 2 hours in your office and not 12 hours at home solving a 2 hour problem..

Yes. And to make sure they don't cheat on it, maybe don't let them use a computer or the internet. A whiteboard ought to be enough. And just to be really sure, make them explain what they're doing in real time as they do it.

That will do quite well, and offer a wonderful alternative to the standard, awful, whiteboard coding interview.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#280

Post by dksidana »

shandor wrote: post #233

This seems like a pretty popular take on the interview process here on HN. However, there's one pretty glaring flaw that I've never seen discussed: if the interviewee can take the problem home, what prevents them setting up a hackathon with their friends at their place, and making the interview problem a team effort? A couple of knowledgeable friends can do wonders, and if you also prep with them a little you can pro…

I have solved and implemented workaround of this. Rather than only one home assignment of 2 hours, I give one assignment for home. Next assignment, which is enhancement of first assignment, is given when they appear of face 2 face interview.

This makes sure that if someone has not solved home assignment with other's help.

Post reply on HN