3 ms·

When I interview a candidate, I focus primarily on what they've done. Ideally they'd have a body of work online that I can view beforehand. Then I go through

When I interview a candidate, I focus primarily on what they've done. Ideally they'd have a body of work online that I can view beforehand. Then I go through a high level system design and have a collaborative conversation. Last, I give a pretty straightforward coding question, whose purpose is only to make sure they aren't full of shit, which often they are. The mistake I see interviewers make is that they are looking for the candidate to solve some kind of puzzle, and the focus is kept on whether they had that "ah-ha" moment vs a clean implementation. Maybe this would be a good approach for a job that required defusing a bomb, but this is relaxed desk work haha. I once had someone bomb the coding, then email me a few hours after with a clean answer. One of the best hires I ever had.

kinow 1y ago
I follow the dame process. I explain beforehand what kind of questions will be asked, and emphasize there are no tricky questions, that we are just curious about their experience, area of interest, preferences for designing ode, how they tackle ode quality and user support, etc. Haven't had any major issues hiring this way, but I did reject people that appeared to be full-of as your said, or didn't have anything public on github/company gitlab/dockerhub/researchgate/etc.. With exceptions for entry level positions and a few that worked in research or govt where work couldn't be made public (they still normally have some participation in research publications, conferences, technotes, etc.)
- quibono 1y ago
  > didn't have anything public on github/company gitlab/dockerhub/researchgate/ What if the company GitLab/DockerHub instance is restricted and you can't get code samples (I think this is very common)? Or a different example: I have a few public repositories on GitHub but most of them are private - it seems like that's something you'd perceive negatively?
  - FirmwareBurner 1y ago
    I guess they just don't want to hire/interview workers who don't have public work. Maybe they pay very well and can be selective with their candidates, especially in this market. Or they live in some SV bubble where every workers has public work so it's the norm where they live. Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier.
    - quibono 1y ago
      > Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier. This mirrors my experience as well. I tend to do some side projects on the side but, seeing as I do them for fun, I don't take them as seriously. I'd hate to be judged based on work like this over something I'd do in a professional setting. That said I understand why this is an issue and seeing a (representative) code sample is invaluable.
      - kinow 1y ago
        > That said I understand why this is an issue and seeing a (representative) code sample is invaluable. Yeah, I'd also hate to be in that position where I may be the best candidate for a position but somebody else got it just because they have public projects. But at the end, the managers/HR/technical team/etc. are all trying to minimize risks to the company and projects.
    - kinow 1y ago
      No bubble here, I think. I'm also based in EU, Spain, where job market is super competitive right now, and it's quite hard to find candidates. As I said, it doesn't need to be only public repositories. If I interview for containers, then I ask if they have something public on DockerHub, GitLab/GitHub registries. If the answer is no (happened just a few days ago), then I ask what they used. I expect them to say something like Artifactory, Nexus, a directory on a server or HPC, or just explain why they didn't need a registry. For me there is really no wrong answer here. But if they reply they don't have anything public, and have no idea what's a container registry, then that's probably bad -- this is what I think OP of this thread meant by eliminating candidates that are full of---. > Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier. My wife also works here, and she's a recruiter in a EU company, in cancer/research. Most applicants won't have things public in that case, but they can still explain things. If there is a candidate with similar profile, that managers liked, and they have a lot of good work, public, then it's up to managers. I just explain what I saw in the repositories, whether I'd work with the candidates, and the managers hiring choose based on risk for companies. As you are based in EU, you probably have the same problem that the hiring process can be expensive for company, and risky if you eliminate candidates, and have to go back during the experience/trial period of candidates.
  - kinow 1y ago
    As I replied in the other thread, then we will go through a discussion of what they had internally. Many cases I find the good engineers are able to explain that without too much trouble. Asking them about decisions in the project, issues, pros and cons of tools, etc., normally clarifies whether they understand things or not. And as I replied in the other comment too, unfortunately if there is another candidate with very similar profile & good answers, then I'll give my technical assessment to the manager of the position, and it'll be up to the manager and humans resources to choose based on risk to the company, what they can see from public papers/conferences/repositories/etc. In some cases, even if the work is not public, they can tell us what projects they worked. I work with climate models, so if they mention they don't have anything public, but they were using IFS, FESOM, ICON, SCHISM, or another model that I know/work with, then I'd direct questions on that model, to check what part of the model they worked on or used, who they worked with, etc. For me not having something public is not a blocker for hiring. Just something that simplifies the hiring process -- although, lately I've had a lot of candidates with many personal projects, no branches, no pull requests, not showing experience with Git, etc. (i.e. in some cases it seems some people try to create many repositories just to show that they have something... which can be a red flag too).
  - stevepotter 1y ago
    Great question. I'm okay with someone who doesn't have public code, although they will have to work a little harder to verify their skills match their story. You have some public repos. That's plenty. Even some gists will work I tell people all the time, if you want to make it easier to get hired, put some work online. This is especially helpful for those without great credentials or history. Take advantage of this, as it's not possible in many other professions.
    - kinow 1y ago
      Agreed. Another thing that helps is writing. If you have a blog, it helps tremendously as it's possible to learn a lot from an engineer when the posts contain some thoughts about what that person learned or worked on, some opinions, techniques and tools used, etc. Even these Linkedin posts are fine, as long as it's not an ad to some tool, or just full of buzzwords. The kind of "behind the trenches" posts are great too, to explain something that happened in a project, a challenge you had, how you debugged a problem. This saves a lot of time in the interview as I would read it all and use that to discuss with the candidate.
  - dekhn 1y ago
    What I've done is create one github project in my repo that is public, well-architected, implemented, tested, and commented. That's what I share if somebody wants a code example. I wrote the whole thing from scratch based on personal knowledge and some documentation (pyparsing and SMILES strings). I wrote it while working for a company, and went through their open-sourcing of personal work process.
nobleach 1y ago
I did this once! I was given a "create Battleship" take-home assignment. Normally, I'd say, "yeah, I don't have time for this". But I happen to really like that game and had never thought of how to model it in code. So I took up the challenge. I spent time whiteboarding classes, interfaces, writing tests... in the end, I had a solid solution. I submitted my code and as I was doing so, I thought, "you know, this really could be handled by a couple of Set data structures. After hitting send, I did a quick follow-up with, "you know, this has a very simple solution" and typed some example code right in the body of the email. I love it when I can't just leave a problem alone. The hiring manager appreciated it too!
- dekhn 1y ago
  Isn't it fun when you can take a game you play and write an implementation (both the game and the solver), thinking through all the details, and at the end, the solution is simple, elegant, and enlightening? For many years I played Peg Solitaire, and after reading Norvig's AI:AMA, realized that Peg Solitaire was a fairly easy game to write a solver for. It wasn't that hard to write, but it turns out that I've only ever implemented recursion using function calls to implement a stack, rather than the iterative equivalent (using a python list as a stack, and a Set to save previously visited boards). Having the confidence of the working recursive version, and then reading up on iterative implementations, i was finally able to get a working iterative version (for some reason it's really unnatural-feeling to me) working.
jasonjmcghee 1y ago
I think it's a great idea to ask what someone might have done differently if they'd built one of those bodies of work professionally. Priorities are often different with experiments and side projects. I also think why someone built something can be more meaningful than how.
pak9rabid 1y ago
Coding is like sex, both are susceptible to performance anxiety when made to be done in front of others.
- MathMonkeyMan 1y ago
  It gets easier with practice.
ls-a 1y ago
[flagged]
heresie-dabord 1y ago
> When I interview a candidate, I focus primarily on what they've done. I like to hear candidates explain how they understood and met the customer's requirements. The code is only part of the success.
- stevepotter 1y ago
  Agree, although this is often an undeveloped skill in newer folks. There are many other things I like to discuss in an interview: past mistakes, things they are especially proud of, times they trimmed scope to meet a deadline, working with difficult people, etc. My goal for interviewing is to either hire the person, or not hire the person but have them walk away feeling like they got something out of our time together. Often I can quickly tell that the person isn't right for the role, in which case I will politely explain that to them and offer whatever advice I can.

kinow 1y ago

I follow the dame process. I explain beforehand what kind of questions will be asked, and emphasize there are no tricky questions, that we are just curious about their experience, area of interest, preferences for designing ode, how they tackle ode quality and user support, etc. Haven't had any major issues hiring this way, but I did reject people that appeared to be full-of as your said, or didn't have anything public on github/company gitlab/dockerhub/researchgate/etc.. With exceptions for entry level positions and a few that worked in research or govt where work couldn't be made public (they still normally have some participation in research publications, conferences, technotes, etc.)

quibono 1y ago
> didn't have anything public on github/company gitlab/dockerhub/researchgate/ What if the company GitLab/DockerHub instance is restricted and you can't get code samples (I think this is very common)? Or a different example: I have a few public repositories on GitHub but most of them are private - it seems like that's something you'd perceive negatively?
- FirmwareBurner 1y ago
  I guess they just don't want to hire/interview workers who don't have public work. Maybe they pay very well and can be selective with their candidates, especially in this market. Or they live in some SV bubble where every workers has public work so it's the norm where they live. Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier.
  - quibono 1y ago
    > Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier. This mirrors my experience as well. I tend to do some side projects on the side but, seeing as I do them for fun, I don't take them as seriously. I'd hate to be judged based on work like this over something I'd do in a professional setting. That said I understand why this is an issue and seeing a (representative) code sample is invaluable.
    - kinow 1y ago
      > That said I understand why this is an issue and seeing a (representative) code sample is invaluable. Yeah, I'd also hate to be in that position where I may be the best candidate for a position but somebody else got it just because they have public projects. But at the end, the managers/HR/technical team/etc. are all trying to minimize risks to the company and projects.
  - kinow 1y ago
    No bubble here, I think. I'm also based in EU, Spain, where job market is super competitive right now, and it's quite hard to find candidates. As I said, it doesn't need to be only public repositories. If I interview for containers, then I ask if they have something public on DockerHub, GitLab/GitHub registries. If the answer is no (happened just a few days ago), then I ask what they used. I expect them to say something like Artifactory, Nexus, a directory on a server or HPC, or just explain why they didn't need a registry. For me there is really no wrong answer here. But if they reply they don't have anything public, and have no idea what's a container registry, then that's probably bad -- this is what I think OP of this thread meant by eliminating candidates that are full of---. > Where I live in Europe 90%+ of workers barring those currently in academia, have no public work because most companies don't publish their work, so you'd never hire anyone with that barrier. My wife also works here, and she's a recruiter in a EU company, in cancer/research. Most applicants won't have things public in that case, but they can still explain things. If there is a candidate with similar profile, that managers liked, and they have a lot of good work, public, then it's up to managers. I just explain what I saw in the repositories, whether I'd work with the candidates, and the managers hiring choose based on risk for companies. As you are based in EU, you probably have the same problem that the hiring process can be expensive for company, and risky if you eliminate candidates, and have to go back during the experience/trial period of candidates.
- kinow 1y ago
  As I replied in the other thread, then we will go through a discussion of what they had internally. Many cases I find the good engineers are able to explain that without too much trouble. Asking them about decisions in the project, issues, pros and cons of tools, etc., normally clarifies whether they understand things or not. And as I replied in the other comment too, unfortunately if there is another candidate with very similar profile & good answers, then I'll give my technical assessment to the manager of the position, and it'll be up to the manager and humans resources to choose based on risk to the company, what they can see from public papers/conferences/repositories/etc. In some cases, even if the work is not public, they can tell us what projects they worked. I work with climate models, so if they mention they don't have anything public, but they were using IFS, FESOM, ICON, SCHISM, or another model that I know/work with, then I'd direct questions on that model, to check what part of the model they worked on or used, who they worked with, etc. For me not having something public is not a blocker for hiring. Just something that simplifies the hiring process -- although, lately I've had a lot of candidates with many personal projects, no branches, no pull requests, not showing experience with Git, etc. (i.e. in some cases it seems some people try to create many repositories just to show that they have something... which can be a red flag too).
- stevepotter 1y ago
  Great question. I'm okay with someone who doesn't have public code, although they will have to work a little harder to verify their skills match their story. You have some public repos. That's plenty. Even some gists will work I tell people all the time, if you want to make it easier to get hired, put some work online. This is especially helpful for those without great credentials or history. Take advantage of this, as it's not possible in many other professions.
  - kinow 1y ago
    Agreed. Another thing that helps is writing. If you have a blog, it helps tremendously as it's possible to learn a lot from an engineer when the posts contain some thoughts about what that person learned or worked on, some opinions, techniques and tools used, etc. Even these Linkedin posts are fine, as long as it's not an ad to some tool, or just full of buzzwords. The kind of "behind the trenches" posts are great too, to explain something that happened in a project, a challenge you had, how you debugged a problem. This saves a lot of time in the interview as I would read it all and use that to discuss with the candidate.
- dekhn 1y ago
  What I've done is create one github project in my repo that is public, well-architected, implemented, tested, and commented. That's what I share if somebody wants a code example. I wrote the whole thing from scratch based on personal knowledge and some documentation (pyparsing and SMILES strings). I wrote it while working for a company, and went through their open-sourcing of personal work process.

nobleach 1y ago

I did this once! I was given a "create Battleship" take-home assignment. Normally, I'd say, "yeah, I don't have time for this". But I happen to really like that game and had never thought of how to model it in code. So I took up the challenge. I spent time whiteboarding classes, interfaces, writing tests... in the end, I had a solid solution. I submitted my code and as I was doing so, I thought, "you know, this really could be handled by a couple of Set data structures. After hitting send, I did a quick follow-up with, "you know, this has a very simple solution" and typed some example code right in the body of the email. I love it when I can't just leave a problem alone. The hiring manager appreciated it too!

dekhn 1y ago
Isn't it fun when you can take a game you play and write an implementation (both the game and the solver), thinking through all the details, and at the end, the solution is simple, elegant, and enlightening? For many years I played Peg Solitaire, and after reading Norvig's AI:AMA, realized that Peg Solitaire was a fairly easy game to write a solver for. It wasn't that hard to write, but it turns out that I've only ever implemented recursion using function calls to implement a stack, rather than the iterative equivalent (using a python list as a stack, and a Set to save previously visited boards). Having the confidence of the working recursive version, and then reading up on iterative implementations, i was finally able to get a working iterative version (for some reason it's really unnatural-feeling to me) working.

jasonjmcghee 1y ago

I think it's a great idea to ask what someone might have done differently if they'd built one of those bodies of work professionally. Priorities are often different with experiments and side projects. I also think why someone built something can be more meaningful than how.

pak9rabid 1y ago

Coding is like sex, both are susceptible to performance anxiety when made to be done in front of others.

MathMonkeyMan 1y ago
It gets easier with practice.

ls-a 1y ago

[flagged]

heresie-dabord 1y ago

> When I interview a candidate, I focus primarily on what they've done. I like to hear candidates explain how they understood and met the customer's requirements. The code is only part of the success.

stevepotter 1y ago
Agree, although this is often an undeveloped skill in newer folks. There are many other things I like to discuss in an interview: past mistakes, things they are especially proud of, times they trimmed scope to meet a deadline, working with difficult people, etc. My goal for interviewing is to either hire the person, or not hire the person but have them walk away feeling like they got something out of our time together. Often I can quickly tell that the person isn't right for the role, in which case I will politely explain that to them and offer whatever advice I can.