4 ms·

I have been interviewing technical candidates for decades. I have found the most effective approach is to deep dive into systems the interviewee has built. This

I have been interviewing technical candidates for decades. I have found the most effective approach is to deep dive into systems the interviewee has built. This puts them comfortably in areas they should know, and very quickly how shallow or deep their knowledge is. Asking random questions about technology mostly tests their ability to memorize facts. I want people who know how to build things in the real world, not those who excel at adding certifications to their LinkedIn. A parting word - if you are leaning towards Uncle Bob for wisdom, you are heading in the wrong direction.

mtriassi 3y ago
I'd love to know a little bit more about how you do that. I'd typically feel wrong asking a candidate to show code they've written at a previous employer. Do you just ask them to walk you through the architecture by memory? If so what how do you come up with questions about their choices without the specificities of the actual way they wrote their code?
- mixmastamyk 3y ago
  Don’t believe GP was talking about previous code, rather previous design. Perhaps diagraming on a whiteboard.
  - EchoChamberMan 3y ago
    You don't need a whiteboard to talk.
- jareklupinski 3y ago
  > Do you just ask them to walk you through the architecture by memory? depends on the role, e.g. for infra work i can ask "if you had complete autonomy to stand up this project again, what would be your first step" and then we go from there
- Scubabear68 3y ago
  No, I don’t ask them to show me any code or artifacts, but to simply describe the architecture, how it’s put together. Any novel code or algorithms they are proud of. Areas of the code that were problematic, and how they would fix them if they had the chance. Talk about non functional requirements and if the architecture addressed them or not. Basically see if they could communicate how the system worked, it’s good points and bad points, and how deep they could go. This quickly separates the good developers from the cargo culters and pretenders. It also is a good gauge of how much real experience they have had. Generally, if someone can’t describe at least the rough outline of the architecture of an application they have worked on, that’s a strong signal they are going to struggle as a developer
arcbyte 3y ago
Definitely agree with the first part. The most important thing you interview for is passion and any discussion that lets the candidate show that more is great. Hard disagree on the bit about uncle Bob. Everything he says isn't gold but his take on clean architecture and use case driven development is pure magic.
- deleted 3y ago
  [deleted]
- galoisscobi 3y ago
  What has he built other than peddling his books and courses that we use on a daily basis? I don’t know if he meets the bar of an exemplary engineer by that standard. Coders at work was a far better resource in that regard, every person that was interviewed has made significant impact in the world of computing and is discussing hard earned lessons about building software.
  - arcbyte 3y ago
    > What has he built other than peddling his books He wrote the books. That's what he did. What was in the books let me build things faster and with more malleability that has been a game changer in my career.
agumonkey 3y ago
This is so rare. I thought that the github repo trend would lead to more of this type of interviews but so far I hit none. Either people say "cool" and never mention your repo ever again or they straight say "we don't care about repos". So strange

mtriassi 3y ago

I'd love to know a little bit more about how you do that. I'd typically feel wrong asking a candidate to show code they've written at a previous employer. Do you just ask them to walk you through the architecture by memory? If so what how do you come up with questions about their choices without the specificities of the actual way they wrote their code?

mixmastamyk 3y ago
Don’t believe GP was talking about previous code, rather previous design. Perhaps diagraming on a whiteboard.
- EchoChamberMan 3y ago
  You don't need a whiteboard to talk.
jareklupinski 3y ago
> Do you just ask them to walk you through the architecture by memory? depends on the role, e.g. for infra work i can ask "if you had complete autonomy to stand up this project again, what would be your first step" and then we go from there
Scubabear68 3y ago
No, I don’t ask them to show me any code or artifacts, but to simply describe the architecture, how it’s put together. Any novel code or algorithms they are proud of. Areas of the code that were problematic, and how they would fix them if they had the chance. Talk about non functional requirements and if the architecture addressed them or not. Basically see if they could communicate how the system worked, it’s good points and bad points, and how deep they could go. This quickly separates the good developers from the cargo culters and pretenders. It also is a good gauge of how much real experience they have had. Generally, if someone can’t describe at least the rough outline of the architecture of an application they have worked on, that’s a strong signal they are going to struggle as a developer

arcbyte 3y ago

Definitely agree with the first part. The most important thing you interview for is passion and any discussion that lets the candidate show that more is great. Hard disagree on the bit about uncle Bob. Everything he says isn't gold but his take on clean architecture and use case driven development is pure magic.

deleted 3y ago
[deleted]
galoisscobi 3y ago
What has he built other than peddling his books and courses that we use on a daily basis? I don’t know if he meets the bar of an exemplary engineer by that standard. Coders at work was a far better resource in that regard, every person that was interviewed has made significant impact in the world of computing and is discussing hard earned lessons about building software.
- arcbyte 3y ago
  > What has he built other than peddling his books He wrote the books. That's what he did. What was in the books let me build things faster and with more malleability that has been a game changer in my career.

agumonkey 3y ago

This is so rare. I thought that the github repo trend would lead to more of this type of interviews but so far I hit none. Either people say "cool" and never mention your repo ever again or they straight say "we don't care about repos". So strange