3 ms·

A business wants to hire you to solve business problems. Coding is the manifestation of the solutions. To me the white board session is to understand if you can

by snissn 10y ago

A business wants to hire you to solve business problems. Coding is the manifestation of the solutions. To me the white board session is to understand if you can take new problems and understand them enough to sketch out a solution. As a hiring manager, I'm glad you've written code before, I want to understand on a day to day basis if you can transform business problems into solutions.

lostboys67 10y ago
exactly the code is just a means to an end ie solving a real world problem
logfromblammo 10y ago
At most of the companies I have worked for, the difficult part of my job is taking the pre-existing code that barely works under the old internal proprietary framework and rehabilitating it into the new internal proprietary framework with a bare minimum of new development. Showing off that I know how to write (or recognize and copy) good code from scratch does not signal for that. I can't tell you how many times I have had to code something that is objectively incorrect because the old version did it that way, and the customer doesn't want the new version to be different. The problem with the whiteboard interview is that you can't show an old, crufty code base on it, and ask the candidate to sketch out how to implement a simple feature request without overhauling the whole thing to use industry best practices. And you can't show an existing relational database schema that is pathetically ill-designed and ask about a new report for the customer. Those are the sorts of problems businesses have. They don't suck it up and pay the big bucks for a software pro until after the amateurs have already tried fixing it with an Excel spreadsheet or an Access database. And they don't want you to mess up the solution they already have, no matter how much baling wire and duct tape is holding it together. Not everyone that can write code can also work well within an existing codebase. The only situation in the wild that I would trust to indicate that skill for my company is someone who actively contributes to an open-source project with a lot of other active contributors. A one-person side project that shows off everything you can do all by yourself won't reassure me. In fact, if it's too good, I might be worried that you will want to overhaul working code just because it's really, really ugly, and you can detect multiple code smells when you look at it.
at-fates-hands 10y ago
>> To me the white board session is to understand if you can take new problems and understand them enough to sketch out a solution. Honestly? This should be ferreted out in a screening interview. As someone who's hired developers both as a manger and a senior dev, you know what's really important to me? Knowing where your head is at as a developer. What I really want to know is: 1 - When shit hits the fan and you're buried under a mountain of stress, how are you going to handle that? Are you going to fight through it, or just give up? 2 - I want to know if you're open to other approaches to coding? What about other frameworks or tools? Do you believe there is one way to achieve a result, or multiple ways? 3 - Does your code have be perfect on the first try, or do you get something working first and then worry about how sweet the code looks later? 4 - How do you feel about fixing bugs? What if I made you fix bugs for 6 months before you started working on any project, how would you feel about that? 5 - Do you have the courage to stand up and say something if you feel like it will negatively impact a project you're working on? Knowing how to solve basic coding problems at a whiteboard can't substitute for an impending deadline and tons of work that needs to get done in two days. I'd rather have an average developer who can handle a shit ton of stress and get his job done, then some rock star developer who folds like a lawn chair when things get tough. I want the developer who sees a tough deadline as a challenge, rather than the dev who whines constantly about it. You can't figure that out by standing at a whiteboard. You need to sit down and actually talk to the person to get to that stuff.

by snissn 10y ago

lostboys67 10y ago

exactly the code is just a means to an end ie solving a real world problem

logfromblammo 10y ago

At most of the companies I have worked for, the difficult part of my job is taking the pre-existing code that barely works under the old internal proprietary framework and rehabilitating it into the new internal proprietary framework with a bare minimum of new development. Showing off that I know how to write (or recognize and copy) good code from scratch does not signal for that. I can't tell you how many times I have had to code something that is objectively incorrect because the old version did it that way, and the customer doesn't want the new version to be different. The problem with the whiteboard interview is that you can't show an old, crufty code base on it, and ask the candidate to sketch out how to implement a simple feature request without overhauling the whole thing to use industry best practices. And you can't show an existing relational database schema that is pathetically ill-designed and ask about a new report for the customer. Those are the sorts of problems businesses have. They don't suck it up and pay the big bucks for a software pro until after the amateurs have already tried fixing it with an Excel spreadsheet or an Access database. And they don't want you to mess up the solution they already have, no matter how much baling wire and duct tape is holding it together. Not everyone that can write code can also work well within an existing codebase. The only situation in the wild that I would trust to indicate that skill for my company is someone who actively contributes to an open-source project with a lot of other active contributors. A one-person side project that shows off everything you can do all by yourself won't reassure me. In fact, if it's too good, I might be worried that you will want to overhaul working code just because it's really, really ugly, and you can detect multiple code smells when you look at it.

at-fates-hands 10y ago

>> To me the white board session is to understand if you can take new problems and understand them enough to sketch out a solution. Honestly? This should be ferreted out in a screening interview. As someone who's hired developers both as a manger and a senior dev, you know what's really important to me? Knowing where your head is at as a developer. What I really want to know is: 1 - When shit hits the fan and you're buried under a mountain of stress, how are you going to handle that? Are you going to fight through it, or just give up? 2 - I want to know if you're open to other approaches to coding? What about other frameworks or tools? Do you believe there is one way to achieve a result, or multiple ways? 3 - Does your code have be perfect on the first try, or do you get something working first and then worry about how sweet the code looks later? 4 - How do you feel about fixing bugs? What if I made you fix bugs for 6 months before you started working on any project, how would you feel about that? 5 - Do you have the courage to stand up and say something if you feel like it will negatively impact a project you're working on? Knowing how to solve basic coding problems at a whiteboard can't substitute for an impending deadline and tons of work that needs to get done in two days. I'd rather have an average developer who can handle a shit ton of stress and get his job done, then some rock star developer who folds like a lawn chair when things get tough. I want the developer who sees a tough deadline as a challenge, rather than the dev who whines constantly about it. You can't figure that out by standing at a whiteboard. You need to sit down and actually talk to the person to get to that stuff.