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

431–440 of 517 posts

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

#431

Post by silverbax88 »

nilkn wrote: post #425
silverbax88 wrote: post #409

Earlier quoted context omitted.

If you write that in 2 hours, honestly I can't see that being code I'd hire someone for. You'd have to hack together garbage code and you'd look like someone who threw things together without thinking.

Alternatively, with that time limit it's just going to select for candidates who've been churning out Django/Rails/etc. webpages recently and have all the details committed to memory. That feels like premature optimization to me. I can see how it'd find generally good web developers, but I can also see how it'd produce just as many false negatives as Google's interviews do. So is it really that much of a step forward…

I completely agree with that. I was thinking, 'yeah, you could hand this to a kid who only knows surface UI and he could crank this out using Rails or something, but it would just be the same garbage that you couldn't maintain later and it wouldn't prove much more than he knows how to write simple apps.' But then maybe that's all they want?

I dunno...I've worked with a lot of people who could code a simple app but completely fail when it comes to serious programming.

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

#432

Post by collyw »

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.

Its better than being asked to do it for free.

A company recently asked me to do a task they expected me to take ten hours, unpaid of course. I told them I thought it was kind of ridiculous.

"Well do what you can in two or three hours and if you really impress us with what you have done..."

The company really didn't impress me enough to bother.

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

#433

Post by clifanatic »

silverbax88 wrote: post #409
clifanatic wrote: post #395

Earlier quoted context omitted.

> What 2 hour project can you assign that would let the candidate go into enough depth for you to judge their code, design decisions, architecture skills? Well, the movie project suggested in the article was a pretty reasonable one.

If you write that in 2 hours, honestly I can't see that being code I'd hire someone for. You'd have to hack together garbage code and you'd look like someone who threw things together without thinking.

Hm - fair point. If I was to do something like this, I'd definitely treat it as a throwaway - I'd do some cursory data modeling, put some tables into a local MySQL DB, reverse engineer that with (say) Hibernate and then throw some Jersey services and some Ajax in front of it. I wouldn't give any consideration to scalability, or security, or maintainability... one would hope that a hiring committee would take that into account, but you're probably right, the people doing the evaluating would likely immediately forget that this was supposed to be thrown together in a couple of hours, people being people as they tend to be.

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

#434

Post by Tistel »

I did CS and have been a professional programmer for more than 15 years on pretty much every platform under the sun. I am very introverted. I still panic during the whiteboard phase of the interview about 75% of the time. Like go blank on simple stuff. Some problems need collaboration but I find I can only really think clearly when alone. I have been debating taking one of those public speaking classes because I probably need to transition to more of management role (love programming, but, my hair is starting to turn grey and I hear we kick everyone out of the club when the grey happens). The public nervousness has not been very helpful in my life. I wonder what it's for? Why have that feature? Maybe it's a bug.

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

#435

Post by hinkley »

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…

We tend to think in a one size fits all manner and in a team environment I find that counterproductive or even destructive.

Every team needs a couple of people who can solve problems on the spot. They're going to fix your production issues. You need a couple of people who want to know why all the time. Someone with a big picture view. Someone with good aesthetics. Someone schedule driven, and a process nerd.

But they don't have to be the same couple of people. Diversity is more than fine, it's essential to avoid echo chamber syndrome. Some of the worst projects I've worked on had little to no dissent in the ranks. The code was self consistent but entirely wrong (bad info architecture, slow, brittle, impossible to learn after the fact).

But everyone tries to hire people that think exactly like they do. If we weren't so bad at determining that we'd probably never make anything interesting at all.

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

#436

Post by geebee »

I'm coming late to this. I've been through two take-home projects. Both of them resulted in a no-hire, and each has refined what I'm willing to do and what I'm not willing to do.

The first one was a pretty egregious experience, honestly. I never spoke with anyone other than a recruiter. The first was a 2 hour Java test. The next was a take-home that I was supposed to spend 5-7 hours on. I did it and sent it in. I knew it wasn't great, but I put a hard stop at 7 hours. It took almost a month for me to hear back, from the recruiter, "we've decided not to continue with your application at this time..."

For a while, I said never again. However, after refusing (and passing on what might have been good opportunities), I did another. Circumstances were very different. I had two extensive interviews with developers prior to the take-home, and I was interested in the job. Furthermore, they did reply with feedback, though it was through a recruiter.

The feedback was mixed, some things were good, others were bad. Unfortunately, though, it was a hard stop. I didn't get and presumably will never get a chance to defend my choices. Although I understand the company probably doesn't want to open up a debate, they've moved on, it rankles that someone got to say those things about my code and I never got a chance to reply.

So, am I at the point where I'd never do it again? Almost. I think I would insist on an opportunity to defend my code base, at least one back and forth, before calling it quits.

It sounds like this company (mattermark) does this, which is a positive thing. You do get a chance to argue (though maybe they do cut some people off when the project is terrible, and who knows, maybe the people who rejected mine (no connection to mattermark) were just taking it a little easy on me, but were genuinely not interested after seeing it).

I don't actually care about getting paid for the project time, if it's a good opportunity. I have to spend as much time re-studying my data structures and algorithms book for whiteboard interviews anyway, and I actually my learn something from the take-home.

I'll probably talk to a buddy I consider to be a really good programmer who works in this area, and see what his take is on my project, asking him to be pretty brutally honest about his assessment.

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

#437

Post by ebrenes »

ar15saveslives wrote: post #375
blowski wrote: post #240

Earlier quoted context omitted.

Sounds like I'm completely the opposite of you! I'm fine with someone sitting next to me - I love pair programming. But cutting off internet access means no StackOverflow, no online documentation. The test should be very similar to normal working conditions.

Pair programming is not the same as writing code on an interview.

It's completely different in my opinion, the only similarity is that you have two people and one computer.

In pair programming you're both working together, complementing each other to tackle a particular problem or issue. In a good pair programming session we'll both work together to surpass an obstacle.

In an interview, one person is observing, testing and ultimately judging the other person, while actively ensuring they do not contribute to the solution of the problem so as not to skew results. Only one person is truly working towards the programming goal, and both participants know this.

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

#438

Post by RandomOpinion »

edpichler wrote: post #294

Digest: pay for a task before deciding to contract. On the article, Amir wrote: "They refuse to do the project because “someone will hire me without it”. On book "Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent" Joel said that the "the best developers usually have lots of proposals, so they don't spend time doing tests for interviews" . I think Joel and Amir are right.

#11 of the Spolsky test is "Do new candidates write code during their interview?". I think Joel would agree that a take-home test would fall under that.

http://www.joelonsoftware.com/articles/fog0000000043.html

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

#439

Post by stillworks »

yesiamyourdad wrote: post #383
stillworks wrote: post #273

Earlier quoted context omitted.

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 think somehow the world was agreeable enough to drink the Pair-Programming KoolAid. Not sure what you mean. In 25 years, my latest job is the only one that pair, and even then it's only a few teams in a very large organization. I don't think your AB test makes much sense. The two practices are orthogonal. Complementary, but orthogonal. If I had to take one over the other, I'd to TDD, or at least strive for excell…

> Not sure what you mean

Try enlisting services of a consulting company such as ThoughtWorks, Accenture etc. Talk to the people who are already using such consultancies.

Every single job interview I have had this year involved a pair programming session and lists pair-programming as a "culture-fit" requirement.

The very latest one I had to go to, I had already warned the recruiter that that is not my strong point but he still sent me in anyways !

>But they really don't have anything to do with each other

I was trying to propose that maybe enforced pair programming is actually of no real value or very little value it at all and hence pair-programming has nothing to do with anything actually.

I value formal code-reviews. I have ZERO love for being forced into pair-programming be it in a real job or during an interview.

Somehow pair-programming caught on because KoolAid happens.

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

#440

Post by ska »

majormajor wrote: post #186
ghaff wrote: post #180

Earlier quoted context omitted.

>I don't understand the paid part at all. There's a concept around a lot of preliminary engagements between two entities called "skin in the game." The idea is that when something is completely free the other party will take advantage of it without any real serious intent to follow through on anything. Mostly this seems a reaction to the homework-type assignments where candidates are expected to spend a lot of time o…

I get this in theory, but the numbers sound too low for that to make a difference still. I could run 50 candidates through a $200 problem for 10K. That's still a pretty large mismatch between "amount of work done by the candidate" and "amount of work done by the interviewer," and is cost-of-doing-business money for recruiting for a lot of companies currently. Compare that to the cost of me flying people out (which is…

The big expense for the company isn't the $200, it's the time. If the hiring manager is doing their job, and you have a few people in the physical interview (plus follow up, etc.), then that's the dominating cost.

If you're running 50 people through this, you're doing it wrong (unless you have 20+ positions).

Post reply on HN