61–70 of 127 posts
> Those who code at an alarmingly rapid rate, who get complex code compiled and running the first time around. One word: Emergent design. Coding shouldn't be done in large patches of perfect code, it should be done in small segments of perfect code that are individually tested for their correctness and build up the whole solution. The fact I couldn't run my code every few lines would completely destroy my ability to…
blond = old.
Earlier quoted context omitted.
I believe that /this/ is short sighted. I do interviews, I care less about the right answer than I do about the problem solving approach. I interview electrical engineers and I make them do simple transistor problems. If someone gave up and said that they couldn't do it without some sort of SPICE program, I'd cut the interview pretty short. But if the fundamentals are there, even if they don't remember something stup…
My point is that a person's inability to code on a whiteboard has little to do with the value they can provide to the business. Some people just aren't good at it, and why should they be penalized for it? There are other ways to get programmers to write code in an interview, and a simple "Do you prefer to code on the whiteboard or on a computer?" can resolve this. It's not as though that's a huge burden on the busine…
Is it that you just don't like the kind of problems that are being asked (fundamental computer science) and would rather see more real-world problems? Or do you genuinely think the wide, stubby pen and vertical orientation impairs some people's coding ability? Just to note, I can see the performance aspect of the whiteboard is stressful, but coding on a machine with everyone looking at you is stressful too.
This is why I don't ask candidates to code. I ask them to describe concepts, articulate trade-offs, and/or walk me through their process of solving a real problem (usually something I've just solved so that I'm intimately familiar with the space).
I need to see someone code.
This is why I don't ask candidates to code. I ask them to describe concepts, articulate trade-offs, and/or walk me through their process of solving a real problem (usually something I've just solved so that I'm intimately familiar with the space).
I hired someone who did brilliantly on walking and talking through all the conceptual issues. Turned out they couldn't code, and they couldn't touch someone else's code without breaking it. I need to see someone code.
No interview process can be perfect, so unfortunately the trick is in correcting hiring mistakes early.
Earlier quoted context omitted.
I disagree. If you know what a binary search tree or linked list is, you should be able to code them. If you can't do something this simple, how can you be expected to actually solve a problem that you can't just look up the answer too?
Well I know that I've solved a few problems in my time: like developing a multi-threaded distributed object-oriented control system, implementing a JPEG2000 encoder, a convolutional neural net, as well as solving a number of debugging problems that escaped my colleagues. I also know I failed miserably at a trivial coding task in an interview. So I don't know. If I'm the only one who has that kind of problem, maybe my…
This blog post strikes home. Anyone who has worked with me or seen my work has identified me as a top-tier developer, and yet I rarely nail any interviews because I never "sound" how the hiring manager thinks a good candidate should sound. I've boiled it down to my salesmanship, or lack thereof. I don't like talking myself up, and therefore I have difficulty conveying myself confidently. And, as it goes with vicious…
This is why I don't ask candidates to code. I ask them to describe concepts, articulate trade-offs, and/or walk me through their process of solving a real problem (usually something I've just solved so that I'm intimately familiar with the space).
I hired someone who did brilliantly on walking and talking through all the conceptual issues. Turned out they couldn't code, and they couldn't touch someone else's code without breaking it. I need to see someone code.
Earlier quoted context omitted.
I hired someone who did brilliantly on walking and talking through all the conceptual issues. Turned out they couldn't code, and they couldn't touch someone else's code without breaking it. I need to see someone code.
Yeah, but then there's that whole other class of people who are great but can't deal with the pressure and awkwardness of coding on a whiteboard in an interview. No interview process can be perfect, so unfortunately the trick is in correcting hiring mistakes early.
> people who are great but can't deal with the pressure
> and awkwardness of coding on a whiteboard in an interview.
Additionally, in our line of work sometimes you have to program in a team under extreme time pressures. We've found that most people who can't talk about programming while sketching ideas and solutions in interview, can't do it for real.
The upshot is that you should always be testing for what you actually want. We want programmers who can design solutions, work in a team, get stuff done, ask questions when unsure, make decisions when necessary, change their mind when appropriate, and write programs that work. That's what we try to test for in interview, and before.
All these tests are really assignments from Data Structures and Algorithms class, and being fresh out of college can help here a lot.