Live data from Hacker News

Why we don't hire programmers based on puzzles and tricks

37signals.com

401–410 of 460 posts

Re: Why we don't hire programmers based on puzzles and tricks

#401

Earlier quoted context omitted.

Usually the candidate pays all of it.

This is highly unusual (if not unheard of). A company would have to be pretty damn unique in order to justify having candidates pay for their own travel + lodging.

Most jobs are not provided by SV companies or Microsoft. Most prople are not in a career that typically hires from across the country at their own expense. Paid travel is a luxury enjoyed by a small segment of job candidates.

Re: Why we don't hire programmers based on puzzles and tricks

#402

About a year ago I travelled to the south west (of UK) for a job - A full day of interviews, product ideas, I nailed the whole lot. Apart from the obligatory coding test. I have 15 years in this game and I have coded OSS or commercial code every day or week in Python, the language of the test, since 96. It was a codility.com test - I had not actually been expecting it but, kerpow. I rewrote my own abs() because I for…

I never heard of codility so I went to take the demo test. I couldn't pass that in English, much less Java. Lol. That's not a programming test. That's a math test.

That is the perfect example of what not to do.

Re: Why we don't hire programmers based on puzzles and tricks

#403

Earlier quoted context omitted.

Reversing a string is actually an incredibly common interview question. It's a bit like FizzBuzz (IME even more common, but I can't really speak about the world at large).

It might be an incredibly common interview question, but it's not an incredibly common day-to-day task, particularly when there are methods built in to classes that perform this function. An interesting task? Perhaps. But not reflection of the dev's skills, per se. You're not asking about syntax with this. It's a problem solving question and at the end of the day, the only real metric here is not whether a dev could…

I don't see how reversing a string is a "puzzle" - I'd put its difficulty on par (or maybe slightly harder than) fizzbuzz. In most mainstream languages, it requires 2 pieces of knowledge:

1) That a string is implemented as an array of characters.

2) How to reverse an array.

The implementation is straightforward and should be trivial for just about anyone who's done much development.

I don't know that the question is that great, but it certainly isn't bad as a fizzbuzz-type question to use as a filter.

Re: Why we don't hire programmers based on puzzles and tricks

#404
post #255

One of my career goals is to get a programming job without having to show that I can add a leaf to a binary tree through recursion (again). I don't mean this as flippantly as it might sound. I used to think it was kind of fun and exciting to be at the whiteboard, thinking on my feat, dealing with various curveball data structures and algorithms questions. I certainly always read up on this stuff prior to interviews,…

"The last time I went through a massive, all day technical interview, I didn't get the job, partly because I didn't review my data structures and algorithms book (again)"

Which means you're not using that stuff on a daily basis. Which is fine. You're probably doing other things. Development is more than just data structures and algorithms. Yet, that's all many interviewers want to ask about.

Here's my guess: you probably reviewed that stuff prior to job 1. You got that job, due to short term memory, then you went to work. Now you want to go to job 2 (or 3 or 4). And you find yourself having to "review" material that doesn't stick to short term memory, but I'm sure you know damn well how to find it and interpret it if you needed to. No doubt at all.

Re: Why we don't hire programmers based on puzzles and tricks

#405
post #39

The question I always like to ask and reserve a good chunk of time for is along the lines of "What non-technical hobby or interest do you have?" and then "If you had all the technical resources you could dream of, how would you now bring something new to your hobby?" and once we've gone through that the real question is: "Given that when you're duck hunting the key is to shoot ahead of where the duck is, and that a l…

>What non-technical hobby or interest do you have? That seems like a poor choice. Are you trying to eliminate people who don't have non-technical hobbies for some reason?

It's fairly irrelevant, the last part is the important part... very rarely I do find someone who stubbornly declare that they have no other interests at all, but then I just propose for them some pastime or other that may fascinate them.

Re: Why we don't hire programmers based on puzzles and tricks

#406
post #156
post #150

The best interview I ever had, I was given a problem to solve with a system, a whiteboard and 20 minutes. I sketched out a quick ERD, and explained the high level architecture of the system. No code was written -- it was assumed that I could implement said system if I could design it. The worst job interview grilled me on low level algorithms (I'm not a CS grad) and wanted me to sketch out a quick sort. Of course, I…

Exactly. Same here. Now I give interviews, and I do the former not the later. Make sure you do the same if you get to interview others. This puzzle and brainteaser shit needs to stop.

A. Friggin. Men. I just wish they'd make it easier for us to weed ourselves out. Just come straight out and ask for CS grads only. None of that "or equivalent experience" nonsense. I also don't have a CS degree. I have the bastard stepchild degree (CIS). :-)

Just ask for CS ONLY and we can easily avoid you and make this easier on all of us.

Re: Why we don't hire programmers based on puzzles and tricks

#407
post #399
post #24

Earlier quoted context omitted.

If I was given a logic puzzle I would ask them "so how many times in the last year this company had to solve this particular puzzle here?".

And you would have gotten an instant fail on the "cultural fit" criteria.

Good!

Re: Why we don't hire programmers based on puzzles and tricks

#408

Earlier quoted context omitted.

>I don't know if this is a Silicon Valley thing or what, but the idea that someone would basically do a day's unpaid work on projects they know nothing about with three different people is just about the most foreign thing I can think of. Yep. That basically amounts to an application fee.

Which is strictly forbidden in most jurisdictions.

It depends on how it is structured.

I doubt there would be anything wrong with saying "we maintain open source project X and we only hire people who have made submissions in this project that we have accepted. If you want to be considered for employment, you must first get involved in the community."

Re: Why we don't hire programmers based on puzzles and tricks

#409

Earlier quoted context omitted.

I've worked to two programmers who could not code. I mean literally not code. You cannot imagine how frustrating this became before the managers finally got rid of them.

How can this even happen? I mean, isn't it obvious in the first week or two, month tops? If not how can they hide their cluelessness for months until they are laid off?

Month one and two they are 'ramping up' Month three and four they pick something inane like what kind of font the web site should use and schedule lots of one on one face-time meetings with higher ups. The higher the better. Month five and six they are now telling everyone their life goal is to be a project manager or that they are training to be a project/program/product manager. Their work is sort of like a project manager. They did the font project. Remember the font project? Simple game theory prevents managers from acknowledging the truth that they are loafing because that might make all management look like all they do is loaf. The guy's direct manager is overjoyed that all the higher ups are paying attention to the font project.

Re: Why we don't hire programmers based on puzzles and tricks

#410

Earlier quoted context omitted.

I think the swapping two variables has a bit more going for it if they do not know the trick. Explain the concept of invertible functions. Hopefully they would be able to come up with plus and minus - even if you have to walk them through the a=f(a,b) b=g(a,b) a=g(a,b) From there you can say that works fine with pen and paper but why might it go wrong in a program? So how do you avoid integer overflow? If the signs a…

XOR trick? I'm not sure I'd want to work for someone who didn't know about the x86 xchg opcode.

[deleted]
Post reply on HN