6 ms·

The problem is there are a lot of people who are still good coders who suck at white-boarding for one reason or another. I became one of them due a combination

The problem is there are a lot of people who are still good coders who suck at white-boarding for one reason or another. I became one of them due a combination of age, rustiness and an escalation of nervousness after failing a couple whiteboards out of the gate. Of course once I did land a job it took about a week to shake off the rustiness, and the company that hired me is thrilled. The point is that companies like Google and Facebook can afford to miss out on those devs. But smaller companies should be looking for diamonds in the rough, not trying to mimic the FAANGs and getting their leftovers.

dantheman 7y ago
You can offer a coding test - give them a computer, a piece of paper, etc. Let them sit a room by themselves, give them up to an hour to do a 15 minute problem. There are lots of ways to destress the coding interview, but the ability to code has to be tested.
- beat 7y ago
  What if the job doesn't really involve coding? That's true of rather a lot of senior/lead level software engineering jobs. Security analysts, devops engineers, architects, and others may never write code at all as part of their jobs. As a senior devops engineer, I write a lot of trivial Groovy code for Jenkins pipelines. But the interesting part isn't the code, which for the most part a monkey could do. It's redesigning the release process. The rest is just implementation details. Thinking coding is important is a failure mode.
  - joshuamorton 7y ago
    FWIW, I'd refuse to work for a lead or architect who wasn't tested on their ability to write code (and in my current position, my manager, their manager, their manager, and their manager all have significant work as SWEs that I can see, or passed coding interviews). The thing that I find when conducting interviews is that people who have trouble writing a concrete solution to a problem often have trouble formalizing any solution. They can handwave stuff that maybe makes sense, and given enough good faith is "correct", or at least not obviously incorrect, but at the same time it depends on a whole suite of libraries that don't exist, or a domain specific language that someone would need to come up with, or something. And if you need to invent a DSL to parse a string, I'm worried about how complicated your actual solution would be when redesigning the release process. Because sure, any monkey can write some groovy code that does something. But I'm more worried about if that code will be well designed. Note, not the system, but the code itself. Because in reality the code defines the system, and a beautiful architecture implemented terribly is still terrible to work with. To see the second thing, I need to see concrete code.
    - beat 7y ago
      When I'm interviewing experienced people, I usually gauge technical skill by picking something out of their resume and digging into it with questions. If they don't really understand what happened technically, it's immediately apparent (this is also how you catch inflated resumes). And if they do, I can just keep asking more questions to get a better sense of it. This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level.
      - joshuamorton 7y ago
        > This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level. But being able to map the macro to the micro is a vital part of being a competent SWE. This includes being an architect. If your plan only considers macro-issues, but is difficult to actually implement on a small scale, its not a good plan. I want to gauge both, and a coding test is a good way to measure the micro.
      - suzzer99 7y ago
        Yeah this is much better. This guy has the right approach imo: https://www.karllhughes.com/posts/rethinking-hiring https://www.karllhughes.com/posts/rethinking-hiring
        karlhughes 7y ago
        Thanks for sharing! I read this post and thought the same thing. I'm honestly nervous that next time I have to go out and interview, I'll be in the same shoes as OP. Despite many years of managing software for small companies, I have no desire to go back and re-learn Leetcode just to get a job.
  - suzzer99 7y ago
    One problem I have is at my level it's really more about architecting than coding. Although coding is still important. (And by the way I realize in a lot of companies, 'architect' is a completely bogus term for someone who's more of a flim-flam man than actual doer. So just substitute "staff engineer" or whatever you call it.) But the main parts of my job I have to get right are picking the right approaches technology-wise, and setting up frameworks and patterns to make devs' lives easier in building out the actual features. You can't test that stuff on a whiteboard imo. You have to just talk it through and try to get a sense of how the potential architect/lead thinks about problems. It also takes a good architect to interview an architect imo. There's plenty of great devs who just haven't acquired that level of scope yet - not of thinking not just about how easily it is for you to get something done - but how easily it will be to maintain as a team, within the greater ecosystem, over the life of the product.
    - beat 7y ago
      > It also takes a good architect to interview an architect And that's the underlying problem behind this coding-test nonsense. You don't ask an architect candidate to implement a binary tree in an interview because it's relevant - you ask that question because you don't know how to ask questions that are relevant. For anything but actual low/mid level coders, these coding tests are just evidence of a failure to interview effectively. As an aside, I don't find most architects to be "flim-flam men". They are usually quite hardworking and competent, although their job is frought with risk. They're often asked to do the impossible, and they have to do the best they can with it.
      - hellisothers 7y ago
        Why is this getting downvoted?
        beat 7y ago
        Because I keep calling the coding test mentality "nonsense".
  - rhinoceraptor 7y ago
    I think the most valuable engineering leader would be someone who can remove code, or at least prevent unnecessary code from being written and maintained. Code is a liability as much as it is an asset.
- suzzer99 7y ago
  Yeah but then inevitably the company starts grading on a curve. Did the dev nail every single possible mistake or bug? Did they add any extra flourishes? So you're not just testing for basic competence anymore. You're testing for devs who are really good at timed coding challenges - just like with challenges where it's tough to get the right answer in the allotted time. Companies don't get excited about a dev who just passes. Even though that dev might be by far the best candidate - they just need a few days to chew on various architectures - or they take the test literally and don't add bells and whistles. Etc. Companies get excited about a dev who aces it with flying colors.
  - raincom 7y ago
    That's what FB does these days: how fast can one code, how bug free, etc.
  - HillaryBriss 7y ago
    > inevitably the company starts grading on a curve which explains the paradox of too many developers chasing too few jobs versus all these companies complaining that they cannot find enough good developers
baron_harkonnen 7y ago
There's also a lot of senior devs who think they are a false negative who are not. I speak from personal experience. I failed my first FAANG style interview both because I had not prepared nor understood how white board interviews really work and because a huge subset of my skill had gotten rusty over the years. But when I first failed I was really upset and very quickly wrote off the entire process as a ridiculous test. Looking back I was a true negative and needed to brush up on a range of skills. When I was a junior dev I spent nearly all my time studying programming, CS and software. But as I got more senior I definitely relaxed a bit on all of that and coasted more on the inertia of past successes than I should have. Yes I was good at my current job, and the ones before it, but those only represent a small subset of the skills a senior engineer should have. What made me a great engineer in one specific company allowed me to let other skills that I wasn't using decline a bit. By being a bit more honest with myself I spent a long time getting back into the things that I used to love and also learned how to practice whiteboards. All my white board interviews after that were a success. I think a huge push back by senior devs against these interviews is that they don't want to admit that, while they have gained a ton of valuable experience, they might not be as strong of a software engineer as they once were.
- malvosenior 7y ago
  This is such a great response and I've had similar experiences. As you become more senior you also get more managerial responsibilities which can eat into your time/energy budget to stay up to date on tech not directly related to your job. You may also get more life responsibilities as you age (family...) that further erode your technical edge. Good on you for having the introspective skills and awareness to identify the problem and do something about it.
  - wuliwong 7y ago
    I don't understand how this is a problem? If OP is a Senior Dev and interviewing for another Senior Dev role, wouldn't you assume that this new role is probably going to require similar skills to perform similar managerial type responsibilities? I mean, sure go ahead and prepare for interviewing, brush up on whatever you think will help. But if a company has a policy of consistently rejecting candidates based on testing of skills that are never used on the job, it sounds like there's a lot of room to improve that interview process.
C1sc0cat 7y ago
Even FANGS need developers who can get stuff done to make up for all the JIRA jockeys.
everdev 7y ago
> companies like Google and Facebook can afford to miss out on those devs. But smaller companies should be looking for diamonds in the rough I'd say it's the opposite. Big companies can afford to take a shot on someone and miss without materially impacting the business. If I'm hiring developer #2 at my 5 person startup, I want someone confident and cool under pressure who has done something similar to what I'm building so many times in real life that the coding test is a cake walk. A dev hire on a small engineering team (< 5 people) can make or break the business. I'm trying to de-risk that hire as much as possible. I want to design a test that 90% of people will fail so I can find that top 10% developer. Once I get to 15-20+ devs, I'm much more likely to relax my criteria and look for a diamond in the rough.
- stuxnet79 7y ago
  I agree. Hiring has both a non-trivial time and money cost. The very same companies that would benefit from finding diamonds in the rough usually don't have the resources to find these devs in the first place. The modern coding interview is designed for the processes and needs of larger tech cos with large amounts of resources. Cargo cult at your own discretion.
- justfor1comment 7y ago
  This is reasonable from your vantage point. But why should that talented person work for your fledgling startup? Wouldn't he or she have more options on the table?
  - everdev 7y ago
    Absolutely. Then it's all about selling the team, the company and it's potential. If you can't sell your vision to your employees you probably won't be able to sell to your customers either.
- HillaryBriss 7y ago
  yes. also factor in the probability of receiving a huge number of qualified applicants: for Google it is as close to 1 as it is for any company. for the startup it's far lower. Google does not need to take these risks.

dantheman 7y ago

You can offer a coding test - give them a computer, a piece of paper, etc. Let them sit a room by themselves, give them up to an hour to do a 15 minute problem. There are lots of ways to destress the coding interview, but the ability to code has to be tested.

beat 7y ago
What if the job doesn't really involve coding? That's true of rather a lot of senior/lead level software engineering jobs. Security analysts, devops engineers, architects, and others may never write code at all as part of their jobs. As a senior devops engineer, I write a lot of trivial Groovy code for Jenkins pipelines. But the interesting part isn't the code, which for the most part a monkey could do. It's redesigning the release process. The rest is just implementation details. Thinking coding is important is a failure mode.
- joshuamorton 7y ago
  FWIW, I'd refuse to work for a lead or architect who wasn't tested on their ability to write code (and in my current position, my manager, their manager, their manager, and their manager all have significant work as SWEs that I can see, or passed coding interviews). The thing that I find when conducting interviews is that people who have trouble writing a concrete solution to a problem often have trouble formalizing any solution. They can handwave stuff that maybe makes sense, and given enough good faith is "correct", or at least not obviously incorrect, but at the same time it depends on a whole suite of libraries that don't exist, or a domain specific language that someone would need to come up with, or something. And if you need to invent a DSL to parse a string, I'm worried about how complicated your actual solution would be when redesigning the release process. Because sure, any monkey can write some groovy code that does something. But I'm more worried about if that code will be well designed. Note, not the system, but the code itself. Because in reality the code defines the system, and a beautiful architecture implemented terribly is still terrible to work with. To see the second thing, I need to see concrete code.
  - beat 7y ago
    When I'm interviewing experienced people, I usually gauge technical skill by picking something out of their resume and digging into it with questions. If they don't really understand what happened technically, it's immediately apparent (this is also how you catch inflated resumes). And if they do, I can just keep asking more questions to get a better sense of it. This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level.
    - joshuamorton 7y ago
      > This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level. But being able to map the macro to the micro is a vital part of being a competent SWE. This includes being an architect. If your plan only considers macro-issues, but is difficult to actually implement on a small scale, its not a good plan. I want to gauge both, and a coding test is a good way to measure the micro.
    - suzzer99 7y ago
      Yeah this is much better. This guy has the right approach imo: https://www.karllhughes.com/posts/rethinking-hiring https://www.karllhughes.com/posts/rethinking-hiring
      - karlhughes 7y ago
        Thanks for sharing! I read this post and thought the same thing. I'm honestly nervous that next time I have to go out and interview, I'll be in the same shoes as OP. Despite many years of managing software for small companies, I have no desire to go back and re-learn Leetcode just to get a job.
- suzzer99 7y ago
  One problem I have is at my level it's really more about architecting than coding. Although coding is still important. (And by the way I realize in a lot of companies, 'architect' is a completely bogus term for someone who's more of a flim-flam man than actual doer. So just substitute "staff engineer" or whatever you call it.) But the main parts of my job I have to get right are picking the right approaches technology-wise, and setting up frameworks and patterns to make devs' lives easier in building out the actual features. You can't test that stuff on a whiteboard imo. You have to just talk it through and try to get a sense of how the potential architect/lead thinks about problems. It also takes a good architect to interview an architect imo. There's plenty of great devs who just haven't acquired that level of scope yet - not of thinking not just about how easily it is for you to get something done - but how easily it will be to maintain as a team, within the greater ecosystem, over the life of the product.
  - beat 7y ago
    > It also takes a good architect to interview an architect And that's the underlying problem behind this coding-test nonsense. You don't ask an architect candidate to implement a binary tree in an interview because it's relevant - you ask that question because you don't know how to ask questions that are relevant. For anything but actual low/mid level coders, these coding tests are just evidence of a failure to interview effectively. As an aside, I don't find most architects to be "flim-flam men". They are usually quite hardworking and competent, although their job is frought with risk. They're often asked to do the impossible, and they have to do the best they can with it.
    - hellisothers 7y ago
      Why is this getting downvoted?
      - beat 7y ago
        Because I keep calling the coding test mentality "nonsense".
- rhinoceraptor 7y ago
  I think the most valuable engineering leader would be someone who can remove code, or at least prevent unnecessary code from being written and maintained. Code is a liability as much as it is an asset.
suzzer99 7y ago
Yeah but then inevitably the company starts grading on a curve. Did the dev nail every single possible mistake or bug? Did they add any extra flourishes? So you're not just testing for basic competence anymore. You're testing for devs who are really good at timed coding challenges - just like with challenges where it's tough to get the right answer in the allotted time. Companies don't get excited about a dev who just passes. Even though that dev might be by far the best candidate - they just need a few days to chew on various architectures - or they take the test literally and don't add bells and whistles. Etc. Companies get excited about a dev who aces it with flying colors.
- raincom 7y ago
  That's what FB does these days: how fast can one code, how bug free, etc.
- HillaryBriss 7y ago
  > inevitably the company starts grading on a curve which explains the paradox of too many developers chasing too few jobs versus all these companies complaining that they cannot find enough good developers

baron_harkonnen 7y ago

There's also a lot of senior devs who think they are a false negative who are not. I speak from personal experience. I failed my first FAANG style interview both because I had not prepared nor understood how white board interviews really work and because a huge subset of my skill had gotten rusty over the years. But when I first failed I was really upset and very quickly wrote off the entire process as a ridiculous test. Looking back I was a true negative and needed to brush up on a range of skills. When I was a junior dev I spent nearly all my time studying programming, CS and software. But as I got more senior I definitely relaxed a bit on all of that and coasted more on the inertia of past successes than I should have. Yes I was good at my current job, and the ones before it, but those only represent a small subset of the skills a senior engineer should have. What made me a great engineer in one specific company allowed me to let other skills that I wasn't using decline a bit. By being a bit more honest with myself I spent a long time getting back into the things that I used to love and also learned how to practice whiteboards. All my white board interviews after that were a success. I think a huge push back by senior devs against these interviews is that they don't want to admit that, while they have gained a ton of valuable experience, they might not be as strong of a software engineer as they once were.

malvosenior 7y ago
This is such a great response and I've had similar experiences. As you become more senior you also get more managerial responsibilities which can eat into your time/energy budget to stay up to date on tech not directly related to your job. You may also get more life responsibilities as you age (family...) that further erode your technical edge. Good on you for having the introspective skills and awareness to identify the problem and do something about it.
- wuliwong 7y ago
  I don't understand how this is a problem? If OP is a Senior Dev and interviewing for another Senior Dev role, wouldn't you assume that this new role is probably going to require similar skills to perform similar managerial type responsibilities? I mean, sure go ahead and prepare for interviewing, brush up on whatever you think will help. But if a company has a policy of consistently rejecting candidates based on testing of skills that are never used on the job, it sounds like there's a lot of room to improve that interview process.

C1sc0cat 7y ago

Even FANGS need developers who can get stuff done to make up for all the JIRA jockeys.

everdev 7y ago

> companies like Google and Facebook can afford to miss out on those devs. But smaller companies should be looking for diamonds in the rough I'd say it's the opposite. Big companies can afford to take a shot on someone and miss without materially impacting the business. If I'm hiring developer #2 at my 5 person startup, I want someone confident and cool under pressure who has done something similar to what I'm building so many times in real life that the coding test is a cake walk. A dev hire on a small engineering team (< 5 people) can make or break the business. I'm trying to de-risk that hire as much as possible. I want to design a test that 90% of people will fail so I can find that top 10% developer. Once I get to 15-20+ devs, I'm much more likely to relax my criteria and look for a diamond in the rough.

stuxnet79 7y ago
I agree. Hiring has both a non-trivial time and money cost. The very same companies that would benefit from finding diamonds in the rough usually don't have the resources to find these devs in the first place. The modern coding interview is designed for the processes and needs of larger tech cos with large amounts of resources. Cargo cult at your own discretion.
justfor1comment 7y ago
This is reasonable from your vantage point. But why should that talented person work for your fledgling startup? Wouldn't he or she have more options on the table?
- everdev 7y ago
  Absolutely. Then it's all about selling the team, the company and it's potential. If you can't sell your vision to your employees you probably won't be able to sell to your customers either.
HillaryBriss 7y ago
yes. also factor in the probability of receiving a huge number of qualified applicants: for Google it is as close to 1 as it is for any company. for the startup it's far lower. Google does not need to take these risks.