Earlier quoted context omitted.
I get it. That said, isn't there concern about candidates just cramming on the top 100 programming puzzles just to be able to ace such interviews? I take a bit of a different approach. I want to know how they think. Pose a problem and collaboratively work through it on a white board. No code. Just state diagrams, flow charts, whatever. Not looking for a solution. Looking for the thought process. Then put up a piece o…
"Not looking for a solution. Looking for the thought process." This is the part I can't understand. When the person is on the job, the opposite is in effect. If you tell the candidate to solve a hard problem, you don't wan them to just spit out their thought process, do you? No, you want them to solve the problem. Why the opposite for interviews?
Why we don't hire programmers based on puzzles and tricks
381–390 of 460 posts
Re: Why we don't hire programmers based on puzzles and tricks
#382Earlier 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…
Sorry that you feel I was obtuse - it's a quirk and my editor side doesn't always step up. Poor communication aside, I was attempting to make a finer point than you read to it. Stress is an extremely broad term medically, and used broader still colloquially. Medically defined stress may include anxiety, but frequently will not. Anxiety, or technically in this case "performance anxiety" is a much more narrowly defined…
Other than that you are right. Propranolol is an excellent calming drug.
Re: Why we don't hire programmers based on puzzles and tricks
#383Earlier quoted context omitted.
"What is the big O time of heap sort?" vs "Would you mind writing a function that returns true if any two numbers in the list sum to zero? For example, it would return false for [2,3,5] and true for [-3,5,3]" Are completely different questions. The first is useless: It tests if someone remembers how a heap sort works, and whether or not they use the term "worst case" in the answer. The second one is much better. Some…
Very good illustration, I must say. I strongly disagreed with the GP's rant about knowing O-notation, but I realized he might have faced the first type of questions a lot (e.g tell me the O-complexity of X algorithm). My experience with Amazon was actually the opposite, but I might have been lucky. All the interviewers were very friendly and started from simple questions and went on to more complex ones. Never a "do…
Re: Why we don't hire programmers based on puzzles and tricks
#384Earlier quoted context omitted.
> It's that they are irritated by tests which don't measure what they're supposed to I disagree that programming puzzles don't measure what they're supposed to. Programming puzzles are a microcosm of what programming entails day-to-day. They test the same exact mental faculties. Sure, no one needs to write strcmp using primitives anymore, but the task of doing so exercises the same mental processes that are involved…
Sure, no one needs to write strcmp using primitives anymore, but the task of doing so exercises the same mental processes that are involved in orchestrating the various components when handling a web request. I don't know what strcmp is in the way that you're using it. Does that make me a bad web developer? Something orthogonal to this came up recently on Reddit, and it was observed that in the real world (anecdotall…
Anecdotally, perhaps, 95% of professional programmers don't know the definition of the words, "Lyskov Substitution Principle". That's not the same as not knowing what it is.
Re: Why we don't hire programmers based on puzzles and tricks
#385Re: Why we don't hire programmers based on puzzles and tricks
#386>I remember the first time I interviewed for a front-end programming position and got asked how to do something in JavaScript on a white board >how little it had to do with the actual job. That doesn't make any sense. How is solving a problem with javascript irrelevant to the job of a front end developer? That's what they do.
Re: Why we don't hire programmers based on puzzles and tricks
#387Earlier quoted context omitted.
Sure, no one needs to write strcmp using primitives anymore, but the task of doing so exercises the same mental processes that are involved in orchestrating the various components when handling a web request. I don't know what strcmp is in the way that you're using it. Does that make me a bad web developer? Something orthogonal to this came up recently on Reddit, and it was observed that in the real world (anecdotall…
I think that most interviewers will happily give you the definition of strcmp if you don't already know it. If you're not a bad web developer, you'll happily come up with some code on a whiteboard that meets the definition. Anecdotally, perhaps, 95% of professional programmers don't know the definition of the words, "Lyskov Substitution Principle". That's not the same as not knowing what it is.
Re: Why we don't hire programmers based on puzzles and tricks
#388Earlier quoted context omitted.
Nope. No wage, no tips. In my case it lasted two nights only, and was paid the third night (and making the big bucks on weekend nights within a couple of months), but I'd heard of it being as long as a week at other places. The worst part was, you wouldn't even know how long the trial period was -- they'd just ask you, last minute, if you could come in again for another trial. If it's a place you wanted to work at ev…
> "Nope. No wage, no tips." That sounds illegal, at least here in Canada.
The food service industry in the US has never had much interest in labor laws I guess
Re: Why we don't hire programmers based on puzzles and tricks
#389Earlier quoted context omitted.
I'm not sure that I have a constructive way of replying to this. Can you spell out your objections, instead of trying to jostle my imagination? You act like no one's been fired after their first day at Starbucks.
My point is that having someone work a day for free would be great in any industry, but somehow only we in tech tolerate this, why is it different?
There are a few ways to approach a job interview. The one I like is to say, "I'm a professional working in this area; those people are professionals working in this area; I should learn what they're up to and we should see if it makes sense for us to work together right now" and right now is key, because sometimes the timing or the particular projects aren't a good match, but the people are and you'll want to stay in touch in the future.
One nice non-coincidental advantage of treating it this way is that "success" is a lot easier to achieve, so the interview's going to be a lot less stressful.
So now approach it from that perspective. You could spend a day (or two hours, or two days, or whatever interview duration) chit chatting, talking to HR people about benefits, describing past projects and whatever. But time is really short and the important questions are: what are you actually going to be working on? and are the people you'll be working with any good? Are their experience, personality, skills, etc. going to set you up to do well, help your career, get stuff out the door, and whatever other concerns you have. How are you possibly going to learn any of that without talking to them at length and in detail about their projects? And the best way to "talk in detail" is to pretend you have the job for a day and get up to speed.
So are you now "working a day for free?" Not really. Because, if the people you're interviewing with are people you'd want to work with, they've had a lot longer than you to think about their problems and know a shitload about them. If you contribute anything of value that day, they probably would have gotten as much value from talking their sticking points over with any bright, engaged outsider to get a fresh perspective.
In the rare occasions where the applicant really does provide high value consulting for free for a day, he or she should have known better than to interview there in the first place. If there really was no way to know in advance, just accept that you had a dud of an interview and go on with your life. You've still learned whether that particular company is one you'd want to have a business relationship with in the future, which is valuable, and whether any of their employees are particularly good or bad, which is also valuable; and, if the company has the right values, there's a good chance that they'd want to hire you for contract work. So even those interviews still tend to work out.
tl;dr - when you interview for a job, no matter what, you're working. You'll get the most out of it as an interviewee if you take it seriously as work and try to get as close to the day-to-day job as you possibly can. If the company materially benefits as well, even better.
Re: Why we don't hire programmers based on puzzles and tricks
#390Earlier quoted context omitted.
As the person who posted that question, if you gave me that answer right away, I'd say "good, but can you do better?" "Sort and take the second highest" is a fine first answer. I'd expect most good candidates to start with that. I'd also expect them to say "but I think I can do better" on their own.
This is where I find questions like this a little confusing. To define better (at least in real world situations) the question requires more context. How many records? How are they stored? What are the characteristics of the storage? Which libraries are we using to store it and how do they behave (and in the real world there might be a few)? What are the other constraints? If we request a sort (say in a remote db) wi…