5 ms·

Am I the only one who finds it crazy that at age 50+, ostensibly after working in the industry for at least a couple of decades, a candidate would be subjected

Am I the only one who finds it crazy that at age 50+, ostensibly after working in the industry for at least a couple of decades, a candidate would be subjected to inane technical interviews and useless whiteboarding exercises? I understand that folks have to do what they need to do to stay employed, so opting out isn't possible for everyone, but this is pure insanity.

pinewurst 11y ago
No, you're not crazy at all. My last technical interview(1) was the final straw. No one cared about my knowledge and experience which was actually a specialty in what the company was doing. Someone would enter the room, immediately ask for an irrelevant whiteboard exercise then leave. Rinse and repeat. I felt about 2 inches tall when I left and decided that I had to stop being a software professional if this is how it was.(2) (1)I hate that coinage as it's no longer a dialog, but a combination of hazing and interrogation. (2)There's also the meta-issue that if my work life is dedicated to arguments about git and inheritance philosophy, then I needed a new career.
- pm90 11y ago
  Sounds like a Google interview
  - pinewurst 11y ago
    It wasn't. The Google "interview" involved being asked to regurgitate Linux header constants from memory.
    - eropple 11y ago
      Sounds fun. My last one (and probably my last one) involved being asked about inode structure in ext4 from memory.
- geebee 11y ago
  This is such a serious problem. It took me a long time to understand why this happens. I remember going through the interview paces at a small company where I had a specialization I knew was very valuable to them. Instead, it was all technical quizzes, tree traversal, outer joins, swap two integers without creating a third integer, find the long term state probabilities in a markov chain. I remember thinking, wow, yesterday I was doing a demo of a large, mathematically involved supply chain system to clients at a huge manufacturing company, and here I am, getting paraded from room to room, where recent graduates are asking me how to find the least common ancestor of two nodes in a binary tree. There are a couple of factors going on here. First, a lot of big companies are in a state of constant recruitment, and they aren't really sure they know what they need you for. All they know is that if you can find the least common ancestor for two nodes in a binary tree, adapt merge sort to manage a search where there isn't enough memory to hold all the data at once, and prove that the dual of the primal is the primal of the dual, and you seem normal enough, then they'll have something for you. The other problem is IP - perhaps they view it as inappropriate to ask too much about what you're working on. Part of this problem flows from something very wonderful about our industry - we don't stand (too much) on formal credentials. People don't care all that much about how you learned nonlinear optimization or data structures and algorithms. As a result, the barrier to entry is… well, not low, because any entrance exam that requires proving things about convex sets and doing elaborate algorithms at a whiteboard is not a low barrier to entry, but low in the sense that institutions like law schools can't force everyone to go through three years at $45k+ tuition as a legally enforced barrier to entry (like, you'll be put in prison if you try to practice without the three year, $120K+ tuition degree that many people believe is excessive). The downside is that because software developers don't have a formal system for demonstrating competence in a way that is widely respected by our peers, we essentially have to take our entrance exams over, and over, and over. Actuaries (last I checked, the exams may have changed) have to take a test showing competence in differential equations, vector calculus, and linear algebra, but I don't think that actuaries with 15 years experience are suddenly asked to find the igon values (sorry, couldn't resist) of a matrix or saddle points in a nonlinear optimization problem with non-linear constraints on the spot during an interview. Physicians have to pass boards and exams, yes, but I don't think they're asked questions from their undergraduate organic chemistry midterm every time they interview for a job. Slowly, I am starting to think that it would help if software developers could, as a profession, take greater control over how competence is established. I've heard others here on HN say that while they aren't in favor of legally required licensing, they would be happy to study and sit a very formal exam if it meant they could finally be done with the whiteboard interview exams, at least for a period of time. I say this while acknowledging real fear of regulatory capture, but what we have now is really, really bad.
- mmmBacon 11y ago
  I see this in HW too to a lesser extent. I think a lot of this comes from insecurity by the interviewer and the interviewer's need to feel smarter than the interviewee.
jerf 11y ago
Unfortunately, I've interviewed people with 20 years of experience who were only marginally more skilled than someone with two or three years. The "1 year of experience ten times" effect is unfortunately a real one. For those of you who are early in your career, be sure to keep trying new things out every so often. It's really easy to get trapped because it sneaks up on you; you shouldn't be trying something new every week, because you need some depth, but if you've gone a year with nothing new tried, you may be in some trouble. And be sure your "something new" is a new type of thing, not just a new thing. Learning Python, then PHP, then Ruby, then Perl, is really just learning one thing, maybe 1.5 things. You ought to be learning a dynamic language, then a static one, then maybe SQL, then learning about reliable cloud programming, then perhaps a full functional language, then perhaps go write a GUI with a conventional GUI toolkit, then learn some dynamic front-end Web programming, write a compiler, write a network app starting from sockets, use SSL for something serious, etc. etc. IMHO, the truth is that the programming world doesn't move that fast, but part of the illusion that it does is that it is quite a big bigger than meets the eye at first. It looks like it is moving quickly because there are things that look new to you all the darned time. But under the hood, progress is actually pretty slow.
- gknoy 11y ago
  It's good to know that I've been doing the right thing, then. I have a hard time being confident though, and pitching the value of that breadth. Most sites like Hired or whatnot ask things like, "how much experience do you have with X", and it always leaves me worrying that at some point in a hiring process there's a rejection filter in place that will only see the shallowness of a particular skill. Do you have any advice for how I can deal with that better?
  - jerf 11y ago
    On your side, you do need depth in something. This is sometimes called a "T-shape" of skills... broad shallow sampling, and depth in some smaller set of skills. You should also be aware that hiring requirements are more the wish list of the hiring organization than hard requirements; that is to say, don't "feel bad" about not quite meeting the requirements. If you're close, go ahead and apply. Come in and shine in the interview and only hiring organizations with poor business skills will ignore that you've only got 2 years instead of 3 in Python. (Such exist, though, sadly.) However, I don't know myself how to deal with people who get too particular. When I'm writing my requirements, generally all my requirements come out as "Blah years of experience in $TECH_WE_USE or similar", and even then I'm really only saying "years of experience" because it's the standard; what I really mean is "a level of skill commensurate with what you'd usually expect after Blah years", but I can only deviate from the standard so far, you know? I don't know what to do about interviewers/organizations who think that 5 years in Perl translates out to 0 years of experience in Python. (All you can really do is comfort yourself in knowing that they're really hurting themselves with such specificity, though.)
dragonwriter 11y ago
> Am I the only one who finds it crazy that at age 50+, ostensibly after working in the industry for at least a couple of decades, a candidate would be subjected to inane technical interviews and useless whiteboarding exercises? No one should be subjected to useless whiteboarding exercise, regardless of age and experience; conversely, to the extent that skills relevant to the job can be usefully assessed via whiteboarding, there is no reason age or experience (either of which may have provided time to produce job-useful skills, but is not valuable on its own) should get you out of them. So, while I'm always unhappy with irrelevant exercises in hiring, I don't see the age/experience issue you raise as being relevant to that unhappiness.
- 7Figures2Commas 11y ago
  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.
jpollock 11y ago
Being a mid-40's dev, here's my view... It's as much a test to see if you'd like to work for that company as it is a fizzbuzz. You know going in what the process is, are you willing to prepare for it? Are you willing to expend the effort to open the text books, read papers, and arrange your day job to get the practice in? I've found that the interview prep I had to do was a good indicator of what the job was going to be. So, if you're not willing to do the prep, then perhaps the job isn't for you. Sitting on the other side of the table, the number of people who aren't able to accomplish a fizzbuzz type question is high. I also get more than just "can they code?" out of it. I check: 1) for sound engineering practices (test data!) 2) ability to communicate their process. 3) willingness to ask questions when they don't understand. 4) ability to take feedback. 5) ability to work under time pressure. The technical part is only the first bit. It's a bit hurdle, but it isn't the only one.
- mtberatwork 11y ago
  How much accurate data on a person can you reasonably get by putting them "under the gun" on a whiteboard? How are you filtering out those whose knowledge ends at the prep work they simply memorized beforehand? I find it more worthwhile to have real, in-depth conversations about code, software, infrastructure, etc. and walk through a few prior projects/code they can bring in and have to show. I find this far more insightful than barraging them with trivial coding exercises like fizzbuzz.
  - jpollock 11y ago
    You can't, any more than you can get accurate data about a person by talking to them. They both select for different groups. I understand that the research shows that the only truly accurate measure is working with someone for a week or two.
cam- 11y ago
Whiteboarding is pretty terrible for interviewing developers, the only time they whiteboard is when interviewing.
- g8gggu89 11y ago
  It's always amazed me that they don't just give you a laptop to code on.
  - Cerium 11y ago
    That's what I do. If the candidate is in the room I hand them my keyboard. If they are on a google hangout I send them a link to collabedit.com. People seem to do a lot better with a keyboard and syntax highlighting.
  - duderific 11y ago
    This is what we do. For frontend positions, we give a laptop and a jsfiddle page to code up the answer to a technical problem that should take about 45 minutes. Then we leave the room and come back in 45 minutes and discuss how they did. I know I tend to freeze up when writing whiteboard code in front of a interviewer, so I do not want to subject somebody to that when I am interviewing. When you are looking over someone's shoulder, you are not getting a true picture of their ability. The other thing is that writing code on a whiteboard has nothing to do with coding in the real world. You write some code, test by running in a browser, command line or IDE, refactor, test again etc. Expecting someone to write perfect code without running said code is ridiculous. Whiteboards should be used for sketching out ideas, i.e. architecting different ways to solve a high level problem, like how should I organize these objects in the application? What should the interface look like?
  - baumy 11y ago
    For large companies there are legal problems there. If you can't give every single candidate the same exact experience / ability to succeed in an interview, you are open to lawsuits. If candidate A got a laptop, but candidate B didn't have the option, B can sue. So if you can't guarantee you will have a laptop at 100% of interviews for a given position, you can't offer it at all. That said I feel like interviewing is important enough that a large company with (presumably) large resources ought to be able to make sure a laptop is always there. But it isn't as simple as "just bring a laptop", you'd have to have an enforced process.
g8gggu89 11y ago
I'd guess you haven't interviewed that many people then. IME, lots of people look like they'd be good fit for a higher position like architect, but then when asked to code up a somewhat simple problem they perform far worse than average. Insanity would be you assuming they are good at problem solving and coding without even checking.
nilsbunger 11y ago
Let's say I'm trying to find the top 10% of software engineers and I'm willing to pay for it. I'm interviewing a 55 year old candidate. What kinds of questions should I ask and how should I evaluate if they are really that good? (Let's say I'm hiring at Slack, to make it more concrete). I agree with your sentiment but struggle with the question above.
- 7Figures2Commas 11y ago
  1. Walk through in real detail the candidate's past work. This requires preparation on your part, as you will need to review the candidate's past work, any code samples, etc. If you do your homework and manage the conversation well, it will be very difficult for someone faking it to get through. 2. Present one or two real-world challenges related to the work the candidate would be doing for you and talk about how he or she would solve them. If the candidate wants to draw or write code on a piece of paper or white board, fine. But this should be a conversation, not a test. 3. Although they aren't always viable, contract-to-hire relationships are your friend.
- randcraw 11y ago
  Ask an older candidate, in their experience, which tech or management practices work and which don't. Ask them why they think so. You can learn a lot about the depth of someone's understanding of the full engineering process: reqs & specs, design, implementation, test, maintenance. Among the places the candidate has worked, ask them about the strengths or weaknesses of various approaches and techniques. Ask for war stories that were learning experiences. Ask for their thoughts on which of these might be relevant within your company (or given a certain set of synthetic but plausible relevant constraints). In practice, a really large fraction of software dev practices, especially in the early phases like requirements and design, have long been suboptimal. (I'm being kind, of course.) But few bemoan this because, formally, few agree about how to correct it, largely because business problems vary widely. However if someone smart works in business long enough, and they pay attention to more than just their own code, they usually learn a lot about which approaches serve their business well and which don't. That wisdom is the greatest strength of an experienced developer/engineer. Explore that in the interview, and not just how they would code a red-black tree template in C++ on a whiteboard.
crdoconnor 11y ago
I find it insane that anybody has to do those whiteboarding exercises except maybe fresh grads. But, Google does it so it must be the best way to interview candidates. God forbid you should actually get a candidate to write some code for you with a computer or something.
gaius 11y ago
Whiteboarding stuff from your CS exams is hidden ageism. A 22-year-old can rattle off red-black trees becaue they just revised them for the test. An experienced dev can't because when would you ever actually implement it yourself?
cpitman 11y ago
It would be crazy if the candidate had been working for you for 30+ years, but different companies have different standards and different people gain experience at different rates and/or stop learning. For example, I interviewed one guy to become the Tech Lead for a client's SaaS initiatives. He had a lot of experience, but it was all experience with mainframes. And it showed in how he approached technical/architectural scenarios. Especially for senior/tech leads, you don't want to have to retrain them.
- 7Figures2Commas 11y ago
  How in the world did somebody with decades of mainframe experience wind up in an interview for a SaaS tech lead? On the surface, it sounds like there was a fairly obvious misalignment between the candidate's experience and the experience required by the role. Somebody like this almost certainly should have been filtered out at the resume review stage or in a phone screen. There is no reason a company should be investing staff time in an in-person interview before it has a clear understanding about a candidate's experience.

pinewurst 11y ago

No, you're not crazy at all. My last technical interview(1) was the final straw. No one cared about my knowledge and experience which was actually a specialty in what the company was doing. Someone would enter the room, immediately ask for an irrelevant whiteboard exercise then leave. Rinse and repeat. I felt about 2 inches tall when I left and decided that I had to stop being a software professional if this is how it was.(2) (1)I hate that coinage as it's no longer a dialog, but a combination of hazing and interrogation. (2)There's also the meta-issue that if my work life is dedicated to arguments about git and inheritance philosophy, then I needed a new career.

pm90 11y ago
Sounds like a Google interview
- pinewurst 11y ago
  It wasn't. The Google "interview" involved being asked to regurgitate Linux header constants from memory.
  - eropple 11y ago
    Sounds fun. My last one (and probably my last one) involved being asked about inode structure in ext4 from memory.
geebee 11y ago
This is such a serious problem. It took me a long time to understand why this happens. I remember going through the interview paces at a small company where I had a specialization I knew was very valuable to them. Instead, it was all technical quizzes, tree traversal, outer joins, swap two integers without creating a third integer, find the long term state probabilities in a markov chain. I remember thinking, wow, yesterday I was doing a demo of a large, mathematically involved supply chain system to clients at a huge manufacturing company, and here I am, getting paraded from room to room, where recent graduates are asking me how to find the least common ancestor of two nodes in a binary tree. There are a couple of factors going on here. First, a lot of big companies are in a state of constant recruitment, and they aren't really sure they know what they need you for. All they know is that if you can find the least common ancestor for two nodes in a binary tree, adapt merge sort to manage a search where there isn't enough memory to hold all the data at once, and prove that the dual of the primal is the primal of the dual, and you seem normal enough, then they'll have something for you. The other problem is IP - perhaps they view it as inappropriate to ask too much about what you're working on. Part of this problem flows from something very wonderful about our industry - we don't stand (too much) on formal credentials. People don't care all that much about how you learned nonlinear optimization or data structures and algorithms. As a result, the barrier to entry is… well, not low, because any entrance exam that requires proving things about convex sets and doing elaborate algorithms at a whiteboard is not a low barrier to entry, but low in the sense that institutions like law schools can't force everyone to go through three years at $45k+ tuition as a legally enforced barrier to entry (like, you'll be put in prison if you try to practice without the three year, $120K+ tuition degree that many people believe is excessive). The downside is that because software developers don't have a formal system for demonstrating competence in a way that is widely respected by our peers, we essentially have to take our entrance exams over, and over, and over. Actuaries (last I checked, the exams may have changed) have to take a test showing competence in differential equations, vector calculus, and linear algebra, but I don't think that actuaries with 15 years experience are suddenly asked to find the igon values (sorry, couldn't resist) of a matrix or saddle points in a nonlinear optimization problem with non-linear constraints on the spot during an interview. Physicians have to pass boards and exams, yes, but I don't think they're asked questions from their undergraduate organic chemistry midterm every time they interview for a job. Slowly, I am starting to think that it would help if software developers could, as a profession, take greater control over how competence is established. I've heard others here on HN say that while they aren't in favor of legally required licensing, they would be happy to study and sit a very formal exam if it meant they could finally be done with the whiteboard interview exams, at least for a period of time. I say this while acknowledging real fear of regulatory capture, but what we have now is really, really bad.
mmmBacon 11y ago
I see this in HW too to a lesser extent. I think a lot of this comes from insecurity by the interviewer and the interviewer's need to feel smarter than the interviewee.

jerf 11y ago

Unfortunately, I've interviewed people with 20 years of experience who were only marginally more skilled than someone with two or three years. The "1 year of experience ten times" effect is unfortunately a real one. For those of you who are early in your career, be sure to keep trying new things out every so often. It's really easy to get trapped because it sneaks up on you; you shouldn't be trying something new every week, because you need some depth, but if you've gone a year with nothing new tried, you may be in some trouble. And be sure your "something new" is a new type of thing, not just a new thing. Learning Python, then PHP, then Ruby, then Perl, is really just learning one thing, maybe 1.5 things. You ought to be learning a dynamic language, then a static one, then maybe SQL, then learning about reliable cloud programming, then perhaps a full functional language, then perhaps go write a GUI with a conventional GUI toolkit, then learn some dynamic front-end Web programming, write a compiler, write a network app starting from sockets, use SSL for something serious, etc. etc. IMHO, the truth is that the programming world doesn't move that fast, but part of the illusion that it does is that it is quite a big bigger than meets the eye at first. It looks like it is moving quickly because there are things that look new to you all the darned time. But under the hood, progress is actually pretty slow.

gknoy 11y ago
It's good to know that I've been doing the right thing, then. I have a hard time being confident though, and pitching the value of that breadth. Most sites like Hired or whatnot ask things like, "how much experience do you have with X", and it always leaves me worrying that at some point in a hiring process there's a rejection filter in place that will only see the shallowness of a particular skill. Do you have any advice for how I can deal with that better?
- jerf 11y ago
  On your side, you do need depth in something. This is sometimes called a "T-shape" of skills... broad shallow sampling, and depth in some smaller set of skills. You should also be aware that hiring requirements are more the wish list of the hiring organization than hard requirements; that is to say, don't "feel bad" about not quite meeting the requirements. If you're close, go ahead and apply. Come in and shine in the interview and only hiring organizations with poor business skills will ignore that you've only got 2 years instead of 3 in Python. (Such exist, though, sadly.) However, I don't know myself how to deal with people who get too particular. When I'm writing my requirements, generally all my requirements come out as "Blah years of experience in $TECH_WE_USE or similar", and even then I'm really only saying "years of experience" because it's the standard; what I really mean is "a level of skill commensurate with what you'd usually expect after Blah years", but I can only deviate from the standard so far, you know? I don't know what to do about interviewers/organizations who think that 5 years in Perl translates out to 0 years of experience in Python. (All you can really do is comfort yourself in knowing that they're really hurting themselves with such specificity, though.)

dragonwriter 11y ago

> Am I the only one who finds it crazy that at age 50+, ostensibly after working in the industry for at least a couple of decades, a candidate would be subjected to inane technical interviews and useless whiteboarding exercises? No one should be subjected to useless whiteboarding exercise, regardless of age and experience; conversely, to the extent that skills relevant to the job can be usefully assessed via whiteboarding, there is no reason age or experience (either of which may have provided time to produce job-useful skills, but is not valuable on its own) should get you out of them. So, while I'm always unhappy with irrelevant exercises in hiring, I don't see the age/experience issue you raise as being relevant to that unhappiness.

7Figures2Commas 11y ago
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.

jpollock 11y ago

Being a mid-40's dev, here's my view... It's as much a test to see if you'd like to work for that company as it is a fizzbuzz. You know going in what the process is, are you willing to prepare for it? Are you willing to expend the effort to open the text books, read papers, and arrange your day job to get the practice in? I've found that the interview prep I had to do was a good indicator of what the job was going to be. So, if you're not willing to do the prep, then perhaps the job isn't for you. Sitting on the other side of the table, the number of people who aren't able to accomplish a fizzbuzz type question is high. I also get more than just "can they code?" out of it. I check: 1) for sound engineering practices (test data!) 2) ability to communicate their process. 3) willingness to ask questions when they don't understand. 4) ability to take feedback. 5) ability to work under time pressure. The technical part is only the first bit. It's a bit hurdle, but it isn't the only one.

mtberatwork 11y ago
How much accurate data on a person can you reasonably get by putting them "under the gun" on a whiteboard? How are you filtering out those whose knowledge ends at the prep work they simply memorized beforehand? I find it more worthwhile to have real, in-depth conversations about code, software, infrastructure, etc. and walk through a few prior projects/code they can bring in and have to show. I find this far more insightful than barraging them with trivial coding exercises like fizzbuzz.
- jpollock 11y ago
  You can't, any more than you can get accurate data about a person by talking to them. They both select for different groups. I understand that the research shows that the only truly accurate measure is working with someone for a week or two.

cam- 11y ago

Whiteboarding is pretty terrible for interviewing developers, the only time they whiteboard is when interviewing.

g8gggu89 11y ago
It's always amazed me that they don't just give you a laptop to code on.
- Cerium 11y ago
  That's what I do. If the candidate is in the room I hand them my keyboard. If they are on a google hangout I send them a link to collabedit.com. People seem to do a lot better with a keyboard and syntax highlighting.
- duderific 11y ago
  This is what we do. For frontend positions, we give a laptop and a jsfiddle page to code up the answer to a technical problem that should take about 45 minutes. Then we leave the room and come back in 45 minutes and discuss how they did. I know I tend to freeze up when writing whiteboard code in front of a interviewer, so I do not want to subject somebody to that when I am interviewing. When you are looking over someone's shoulder, you are not getting a true picture of their ability. The other thing is that writing code on a whiteboard has nothing to do with coding in the real world. You write some code, test by running in a browser, command line or IDE, refactor, test again etc. Expecting someone to write perfect code without running said code is ridiculous. Whiteboards should be used for sketching out ideas, i.e. architecting different ways to solve a high level problem, like how should I organize these objects in the application? What should the interface look like?
- baumy 11y ago
  For large companies there are legal problems there. If you can't give every single candidate the same exact experience / ability to succeed in an interview, you are open to lawsuits. If candidate A got a laptop, but candidate B didn't have the option, B can sue. So if you can't guarantee you will have a laptop at 100% of interviews for a given position, you can't offer it at all. That said I feel like interviewing is important enough that a large company with (presumably) large resources ought to be able to make sure a laptop is always there. But it isn't as simple as "just bring a laptop", you'd have to have an enforced process.

g8gggu89 11y ago

I'd guess you haven't interviewed that many people then. IME, lots of people look like they'd be good fit for a higher position like architect, but then when asked to code up a somewhat simple problem they perform far worse than average. Insanity would be you assuming they are good at problem solving and coding without even checking.

nilsbunger 11y ago

Let's say I'm trying to find the top 10% of software engineers and I'm willing to pay for it. I'm interviewing a 55 year old candidate. What kinds of questions should I ask and how should I evaluate if they are really that good? (Let's say I'm hiring at Slack, to make it more concrete). I agree with your sentiment but struggle with the question above.

7Figures2Commas 11y ago
1. Walk through in real detail the candidate's past work. This requires preparation on your part, as you will need to review the candidate's past work, any code samples, etc. If you do your homework and manage the conversation well, it will be very difficult for someone faking it to get through. 2. Present one or two real-world challenges related to the work the candidate would be doing for you and talk about how he or she would solve them. If the candidate wants to draw or write code on a piece of paper or white board, fine. But this should be a conversation, not a test. 3. Although they aren't always viable, contract-to-hire relationships are your friend.
randcraw 11y ago
Ask an older candidate, in their experience, which tech or management practices work and which don't. Ask them why they think so. You can learn a lot about the depth of someone's understanding of the full engineering process: reqs & specs, design, implementation, test, maintenance. Among the places the candidate has worked, ask them about the strengths or weaknesses of various approaches and techniques. Ask for war stories that were learning experiences. Ask for their thoughts on which of these might be relevant within your company (or given a certain set of synthetic but plausible relevant constraints). In practice, a really large fraction of software dev practices, especially in the early phases like requirements and design, have long been suboptimal. (I'm being kind, of course.) But few bemoan this because, formally, few agree about how to correct it, largely because business problems vary widely. However if someone smart works in business long enough, and they pay attention to more than just their own code, they usually learn a lot about which approaches serve their business well and which don't. That wisdom is the greatest strength of an experienced developer/engineer. Explore that in the interview, and not just how they would code a red-black tree template in C++ on a whiteboard.

crdoconnor 11y ago

I find it insane that anybody has to do those whiteboarding exercises except maybe fresh grads. But, Google does it so it must be the best way to interview candidates. God forbid you should actually get a candidate to write some code for you with a computer or something.

gaius 11y ago

Whiteboarding stuff from your CS exams is hidden ageism. A 22-year-old can rattle off red-black trees becaue they just revised them for the test. An experienced dev can't because when would you ever actually implement it yourself?

cpitman 11y ago

It would be crazy if the candidate had been working for you for 30+ years, but different companies have different standards and different people gain experience at different rates and/or stop learning. For example, I interviewed one guy to become the Tech Lead for a client's SaaS initiatives. He had a lot of experience, but it was all experience with mainframes. And it showed in how he approached technical/architectural scenarios. Especially for senior/tech leads, you don't want to have to retrain them.

7Figures2Commas 11y ago
How in the world did somebody with decades of mainframe experience wind up in an interview for a SaaS tech lead? On the surface, it sounds like there was a fairly obvious misalignment between the candidate's experience and the experience required by the role. Somebody like this almost certainly should have been filtered out at the resume review stage or in a phone screen. There is no reason a company should be investing staff time in an in-person interview before it has a clear understanding about a candidate's experience.