Web Engineer. Working mostly with PHP, Symfony and Golang.
Entusiast about Engineering Best Practices, Continuous Delivery and DevOps.
Sports and FC Porto fan!
"You already know what you know, No need to prepare!"
Great quote that matches exactly my way of thinking as well. :)
You definitely raise some interesting points in the article.
I have started doing interviews for my company some months ago, so I can see both sides now, here is my take on this:
No matter what interview process you have, it will be impossible to have a process that works for everyone. Whiteboard and leet code exercises favors candidates with CS Background or "geeks" that like to do this kind of things in their free time. Take Home exercises discriminates parents or people with lot´s of other responsibilities. Live coding discriminates against anxious persons or that cannot perform well under pressure.
Even "discussion based" interviews, can discriminate against introverts or people with vocal related disabilities for example.
So IMO, the best way to approach is to always give the candidate choice, what it works better for them. I agree in having a positive and inclusive process where the candidate can show their strengths, instead of an exclusive process or the interviews are designed for the candidates to fail.
My current company does a take home exercise as the 2nd stage of the hiring process, after a first technical interview. Personally I would gladly don´t require these if a candidate has some other code examples that they can show (like open source / personal projects or projects from his previous job, if possible.
But I have to see sort some code., if possible in a similar type of what they would do in the job.
I love great technical and architectural discussions about real world scenarios with the candidates and you can definitively get a lot of information from this, but there are some details I have not found yet a way to replicate in other form, without seeing code. And I also think these types of interviews are probably more appropriate for more senior level engineers, where we can really go deep in many topics.
Some things I access in the coding exercise, include :
Tests. The candidate might say he know all the types of tests and do TDD and all that. but what they do in practice? The coding exercise allows me to asset that. How they think about the test scenarios? what kind of tests they do? Unit? Integration? An exercise without any tests is a red flag for me.
Documentation - Does they write documentation and explain their thoughts (a Readme file indicating how to start the project is enough in most cases).
Code structure - How they structure their code? Is it readable or they like to over engineer? do they provide meaningful names on the variables/functions? How they handle errors, logging, etc.
Infrastructure - Can we run the application without errors? Candidates that provide a Dockerfile/Docker-compose or some sort of script to boot the application are appreciated.
A good example, I have from a candidate that I hired last month. The exercise my company provides, includes a "list" REST endpoint with Pagination. From like 10 candidates, I saw one, that have handled edge cases like negative numbers on the pagination for example. While definitely not a requirement, it´s a nice touch that caught my attention and shows some attention to detail and that differentiates from other candidates.
This is the kind of things I look on the code exercise. I don´t need them to solve a very complex problem or algorithm. Even an "hello world" like API project, could give me enough information.
I am of course, willing to learn new ways to make the process the better possible for the candidate and for the company.
I'm a Senior Advocate @ Unity, a Developer Advocate and Software Engineer with 9+ years of development and industry experience. Love just creating stuff and putting it out there!
So IMO, the best way to approach is to always give the candidate choice,
what it works better for them.
I agree in having a positive and inclusive process where the candidate can show >their strengths, instead of an exclusive process or the interviews are designed for >the candidates to fail.
I love the idea of having a deep consideration about what works best for the candidate for them to shine in the interview scenario. Our goal is to hire the best candidate for the role. not the person who fails the least.
I read somewhere that one tendency that an interviewer has to try to avoid is the tendency to hire "Yourself". It's easy to sit across from a person and try to see if they pass the test of being as "good as you".
In almost every discipline that exists, diversity of thought is ALWAYS an advantage and I think overly rigid interviewing requirements or the lack of flexibility to approach candidates in a way that helps them shine is detrimental to the whole process.
It takes more works and "care" but engineering your interview process to best suit the various candidates is absolutely the best approach.
Thanks for sharing your thoughts. Gave me more insight into other's interviewing processes and things that I think every interviewer (and interviewee) should consider.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great quote that matches exactly my way of thinking as well. :)
You definitely raise some interesting points in the article.
I have started doing interviews for my company some months ago, so I can see both sides now, here is my take on this:
No matter what interview process you have, it will be impossible to have a process that works for everyone. Whiteboard and leet code exercises favors candidates with CS Background or "geeks" that like to do this kind of things in their free time. Take Home exercises discriminates parents or people with lot´s of other responsibilities. Live coding discriminates against anxious persons or that cannot perform well under pressure.
Even "discussion based" interviews, can discriminate against introverts or people with vocal related disabilities for example.
So IMO, the best way to approach is to always give the candidate choice, what it works better for them. I agree in having a positive and inclusive process where the candidate can show their strengths, instead of an exclusive process or the interviews are designed for the candidates to fail.
My current company does a take home exercise as the 2nd stage of the hiring process, after a first technical interview. Personally I would gladly don´t require these if a candidate has some other code examples that they can show (like open source / personal projects or projects from his previous job, if possible.
But I have to see sort some code., if possible in a similar type of what they would do in the job.
I love great technical and architectural discussions about real world scenarios with the candidates and you can definitively get a lot of information from this, but there are some details I have not found yet a way to replicate in other form, without seeing code. And I also think these types of interviews are probably more appropriate for more senior level engineers, where we can really go deep in many topics.
Some things I access in the coding exercise, include :
Tests. The candidate might say he know all the types of tests and do TDD and all that. but what they do in practice? The coding exercise allows me to asset that. How they think about the test scenarios? what kind of tests they do? Unit? Integration? An exercise without any tests is a red flag for me.
Documentation - Does they write documentation and explain their thoughts (a Readme file indicating how to start the project is enough in most cases).
Code structure - How they structure their code? Is it readable or they like to over engineer? do they provide meaningful names on the variables/functions? How they handle errors, logging, etc.
Infrastructure - Can we run the application without errors? Candidates that provide a Dockerfile/Docker-compose or some sort of script to boot the application are appreciated.
A good example, I have from a candidate that I hired last month. The exercise my company provides, includes a "list" REST endpoint with Pagination. From like 10 candidates, I saw one, that have handled edge cases like negative numbers on the pagination for example. While definitely not a requirement, it´s a nice touch that caught my attention and shows some attention to detail and that differentiates from other candidates.
This is the kind of things I look on the code exercise. I don´t need them to solve a very complex problem or algorithm. Even an "hello world" like API project, could give me enough information.
I am of course, willing to learn new ways to make the process the better possible for the candidate and for the company.
Incredibly well said and great insight!
I love the idea of having a deep consideration about what works best for the candidate for them to shine in the interview scenario. Our goal is to hire the best candidate for the role. not the person who fails the least.
I read somewhere that one tendency that an interviewer has to try to avoid is the tendency to hire "Yourself". It's easy to sit across from a person and try to see if they pass the test of being as "good as you".
In almost every discipline that exists, diversity of thought is ALWAYS an advantage and I think overly rigid interviewing requirements or the lack of flexibility to approach candidates in a way that helps them shine is detrimental to the whole process.
It takes more works and "care" but engineering your interview process to best suit the various candidates is absolutely the best approach.
Thanks for sharing your thoughts. Gave me more insight into other's interviewing processes and things that I think every interviewer (and interviewee) should consider.