5 ms·

Asking a developer with a decade-plus of demonstrable experience to whiteboard is like asking an F1 mechanic to draw an engine and label the parts.

g8gggu89 11y ago
How do you get them to demonstrate successful problem solving and coding and design abilities without seeing them code, then? You're right that it's kind of a silly test, but the problem is that it's a key part of their job and there's no other way to check for these skills, that I know of. And there's also plenty of people who have the experience on the resume and just can't design or code much. It's hardly like the whiteboarding is done for no reason - there are plenty of people it weeds out. A much better analogy would be asking an F1 mechanic to look at a car you had up on a lift. Sure, they don't fix Hondas all day log, but if they can't see obvious problems and don't know how to solve those obvious problems, it would be a serious red flag. Even in your silly example, you'd be smart to question it if the mechanic couldn't label a lot of parts they should be able to label, and it would itself only be a small part of the interview.
- randcraw 11y ago
  A good way to confirm that they know their stuff is to talk to their references. What tasks did they do there? What problems were solved using what tools and techniques used? Nobody knows their skills better than those who already worked with them. If their reference seems to be an idiot, that's informative too. Ask them to bring in an interesting example of their own code to the interview. Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs.
  - g8gggu89 11y ago
    > A good way to confirm that they know their stuff is to talk to their references. What tasks did they do there? What problems were solved using what tools and techniques used? Nobody knows their skills better than those who already worked with them. If their reference seems to be an idiot, that's informative too. Really? You could easily fake that, have a friend who still works somewhere say anything. > Ask them to bring in an interesting example of their own code to the interview. That's great if you're willing to weed out people who only code at work. > Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs. That's what you can do without their own code, but it fails to prove they really wrote it.
- jpindar 11y ago
  No one asks an electrical engineer to design a circuit in an interview, or to identify a bunch of parts. All my interviews have involved talking about projects I've worked on, and about type of work the company does - no test type questions at all. Why are electrical engineers able to evaluate each other through conversation when software engineers apparently are not?
  - rfdave 11y ago
    Earlier in my career, I have been asked to design circuits in interviews. Phone screens have also included in depth discussions of component tradeoffs for various circuits. My most recent interview, after 20+ years of experience, wasn't very technical at all, mostly focusing on team fit and personalities. The whole discussion here of software engineers with 20+ years of experience having to code up fairly simple things on a white board is very strange to me, and fairly far outside my experience.
    - g8gggu89 11y ago
      > The whole discussion here of software engineers with 20+ years of experience having to code up fairly simple things on a white board is very strange to me, and fairly far outside my experience. Once you start interviewing people with a lot of experience and see how poorly some do with FizzBuzz or 'merge 2 sorted arrays', it becomes immediately obvious why this is done. If 20 years experience was a good indicator, it would be used instead. For positions where there's no coding, this wouldn't be asked. All at least in my experience.
      - JoeAltmaier 11y ago
        Maybe its a mismatch between practice and experience. When asked how to map phone numbers into words in a dictionary (or whatever), I don't start coding. I draw pictures and data maps and constraints. Maybe I write a critical condition algebraically. After fleshing out all the corners and dark places, then I may choose a programming language and code approach. So coding exams are almost a litmus test for "inexperienced programmer" in my view. Because an experienced developer doesn't start by coding at all.

g8gggu89 11y ago

How do you get them to demonstrate successful problem solving and coding and design abilities without seeing them code, then? You're right that it's kind of a silly test, but the problem is that it's a key part of their job and there's no other way to check for these skills, that I know of. And there's also plenty of people who have the experience on the resume and just can't design or code much. It's hardly like the whiteboarding is done for no reason - there are plenty of people it weeds out. A much better analogy would be asking an F1 mechanic to look at a car you had up on a lift. Sure, they don't fix Hondas all day log, but if they can't see obvious problems and don't know how to solve those obvious problems, it would be a serious red flag. Even in your silly example, you'd be smart to question it if the mechanic couldn't label a lot of parts they should be able to label, and it would itself only be a small part of the interview.

randcraw 11y ago
A good way to confirm that they know their stuff is to talk to their references. What tasks did they do there? What problems were solved using what tools and techniques used? Nobody knows their skills better than those who already worked with them. If their reference seems to be an idiot, that's informative too. Ask them to bring in an interesting example of their own code to the interview. Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs.
- g8gggu89 11y ago
  > A good way to confirm that they know their stuff is to talk to their references. What tasks did they do there? What problems were solved using what tools and techniques used? Nobody knows their skills better than those who already worked with them. If their reference seems to be an idiot, that's informative too. Really? You could easily fake that, have a friend who still works somewhere say anything. > Ask them to bring in an interesting example of their own code to the interview. That's great if you're willing to weed out people who only code at work. > Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs. That's what you can do without their own code, but it fails to prove they really wrote it.
jpindar 11y ago
No one asks an electrical engineer to design a circuit in an interview, or to identify a bunch of parts. All my interviews have involved talking about projects I've worked on, and about type of work the company does - no test type questions at all. Why are electrical engineers able to evaluate each other through conversation when software engineers apparently are not?
- rfdave 11y ago
  Earlier in my career, I have been asked to design circuits in interviews. Phone screens have also included in depth discussions of component tradeoffs for various circuits. My most recent interview, after 20+ years of experience, wasn't very technical at all, mostly focusing on team fit and personalities. The whole discussion here of software engineers with 20+ years of experience having to code up fairly simple things on a white board is very strange to me, and fairly far outside my experience.
  - g8gggu89 11y ago
    > The whole discussion here of software engineers with 20+ years of experience having to code up fairly simple things on a white board is very strange to me, and fairly far outside my experience. Once you start interviewing people with a lot of experience and see how poorly some do with FizzBuzz or 'merge 2 sorted arrays', it becomes immediately obvious why this is done. If 20 years experience was a good indicator, it would be used instead. For positions where there's no coding, this wouldn't be asked. All at least in my experience.
    - JoeAltmaier 11y ago
      Maybe its a mismatch between practice and experience. When asked how to map phone numbers into words in a dictionary (or whatever), I don't start coding. I draw pictures and data maps and constraints. Maybe I write a critical condition algebraically. After fleshing out all the corners and dark places, then I may choose a programming language and code approach. So coding exams are almost a litmus test for "inexperienced programmer" in my view. Because an experienced developer doesn't start by coding at all.