Earlier quoted context omitted.
Also, it depends on which language you're using... $ irb irb(main):001:0> a = 1 => 1 irb(main):002:0> b = 2 => 2 irb(main):003:0> b, a = a, b => [1, 2] irb(main):004:0> puts "#{a} #{b}" 2 1 => nil (obviously this has the same flaw you mention, the interpreter is doing stuff for you. It follows the letter of the 'no intermediate variables' only.)
You can also follow the letter in C, Java, etc.: a ^= b b ^= a a ^= b
Why we don't hire programmers based on puzzles and tricks
281–290 of 460 posts
Re: Why we don't hire programmers based on puzzles and tricks
#282Earlier 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. That being said, I've never done any pairing so maybe it would work better in that type of environment.
A job interview is going to take at least a day of your time anyway. What does it matter if that time is spent programming, talking over coffee, sketching on a whiteboard, or whatever?
Re: Why we don't hire programmers based on puzzles and tricks
#2831. Junior developer code review where a save method included a call to a list method "because it's more efficient" than making a separate ajax call. Explain to the junior developer why that's not necessarily a good idea.
2. UI wants a tree view of categories where each category has a name and a parent category. The number of categories can be arbitrarily large. Discuss problems you might run into using a database agnositic approach (e.g. Hibernate) and what solutions you'd propose.
3. Prototyping a new app, two potential clients in the same domain have widely different ideas of how those domains should be represented (i.e. obviously similar domain class names, very different properties). Discuss ways of modeling domain classes such that each client sees the data in their preferred format.
All in all, I think the interview went pretty well because the discussion questions led to discussing all sorts of related topics that gave me a good feel for the types of problems the candidate had run into and if he had success in dealing with them.
It was great giving an interview without arcane things like explain the yield keyword in C# and how it might be used.
Re: Why we don't hire programmers based on puzzles and tricks
#284Re: Why we don't hire programmers based on puzzles and tricks
#285Earlier quoted context omitted.
One thing you're testing for is how well their brain works with an excess of adrenaline floating around in their body. All of the best interviewers I've known take great pains to make the interviewer feel comfortable and chatty - after all, they aren't going to be filled with interview anxiety when they're actually working there. A minority of your applicants are going to perform badly in that situation because the a…
"A minority of your applicants are going to perform badly in that situation because the adrenal glands will effectively reduce the output prefrontal cortex below an acceptable level" I have an off topic question. I don't see what the problem being discussed has to do with how glands reduce activity in certain parts of the brain. Sounds to me like a fancy way of saying 'people don't perform well under stress'. You cou…
Re: Why we don't hire programmers based on puzzles and tricks
#286Earlier quoted context omitted.
Anyone who's studied information theory would destroy that puzzle though. In the same way that someone with a physics degree would perform way above average on a "count the stars" question. Or someone whose dissertation was on computational biology would excel at a string-matching algorithm question. It is an example of the interviewer (or company/process) mistaking a specific problem as representative of all problem…
You can interpret the response more broadly, though. In this case, it was probably pretty apparent that the person hadn't worked through the problem before, so it is indicative of problem-solving and attitude. If he'd recited the answer from memory that usually comes across and then you have to pick something from a different area. If, as an interviewer, you literally can't find a problem that the interviewee hasn't…
Re: Why we don't hire programmers based on puzzles and tricks
#287Earlier quoted context omitted.
A job interview is going to take at least a day of your time anyway. What does it matter if that time is spent programming, talking over coffee, sketching on a whiteboard, or whatever?
Many interviews I've had are 2 hour affairs, including jobs I've received where interviews were 45 minutes.
Re: Why we don't hire programmers based on puzzles and tricks
#288Sigh. This is the issue that will just never die. Let's just summarize the points: - Not everyone can produce real-world code. Most of what we do for a living belongs to our employer. Side projects, particularly in the US, can be an issue for IP reasons (California is somewhat of an exception here); - Side projects, even open source projects, can be of questionable "real world" value; - I've personally encountered ma…
I don't even know for certain if such an approach does maximize your time versus finding-good-programmers ratio but let's assume it does.
The thing is you are willing to maximize this ratio by doing things that treat some portion people who have ability as if they don't (even it's also treating people without ability fairly)?
I'd claim that doing that sets you for up an adversarial relationship with everyone in the workplace - the people hire you can feel they're under-the-gun. I strongly suspect that the "almost no one can code" crowd are the people who live in these adversarial environments, which produce bad code through all the emotional and organizational games this implies.
Re: Why we don't hire programmers based on puzzles and tricks
#289Earlier quoted context omitted.
Usually the candidate pays all of it.
Really? Of the three job interviews I've traveled for in the last year, all were paid by the company 100%.
Re: Why we don't hire programmers based on puzzles and tricks
#290Earlier quoted context omitted.
"A minority of your applicants are going to perform badly in that situation because the adrenal glands will effectively reduce the output prefrontal cortex below an acceptable level" I have an off topic question. I don't see what the problem being discussed has to do with how glands reduce activity in certain parts of the brain. Sounds to me like a fancy way of saying 'people don't perform well under stress'. You cou…
My thought is that it's a real phenomenon that occurs in a certain subset of people during a job interview, therefore, its obviously relevant
* Does a stressful interview necessarily actually increase adrenaline? * Is there actually a link between incresed adrenaline and reduced prefrontal cortex output? * What role does the prefrontal cortex play in answering interview questions?
And while these may all have good answers, it just throws up a whole bunch of mental '[citation needed]' annotations all over the whole argument, that can just be skipped entirely if we aren't talking about neuro-science. And if we insist on talking about the bio-chemestry, we should probably go into the details.