Mixing
How can I tell if a job applicant has the right technical skills? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
I recently held a couple of interviews with possible candidates for a possition as "software developer", and in order to get a sense of their technical skills and way of reasoning, I gave them a small problem to be solved in collaboration with me. But as I wrote about in this question, that didn't quite go as well as expected as they seemed to lack even very fundamental programming skills. Maybe due to extraordinary nervousness, maybe due to cultural differences (they were from India, and perhaps questioning their expertise is rude?), and maybe due to plain-old lack of technical skills. I don't know, and specifically I don't know if I can use a poor performance to conclude lack of skills.
That leads me to: if asking the applicant to solve a technical problem, in collaboration with me, is not the best way to see if he is really a skilled programmer or skilled specialist, what strategy should I then use? What would be a good way of telling if a candidate is really a good technical match for the job?
interviewing developer new-hires
edited Apr 13 '17 at 12:48
Community♦
1
asked Nov 18 '14 at 11:26
someName
1633
closed as too broad by Jim G., gnat, Joe Strazzere, Telastyn, Garrison Neely Nov 18 '14 at 20:05
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
suggest improvements |Â
up vote
2
down vote
favorite
I recently held a couple of interviews with possible candidates for a possition as "software developer", and in order to get a sense of their technical skills and way of reasoning, I gave them a small problem to be solved in collaboration with me. But as I wrote about in this question, that didn't quite go as well as expected as they seemed to lack even very fundamental programming skills. Maybe due to extraordinary nervousness, maybe due to cultural differences (they were from India, and perhaps questioning their expertise is rude?), and maybe due to plain-old lack of technical skills. I don't know, and specifically I don't know if I can use a poor performance to conclude lack of skills.
That leads me to: if asking the applicant to solve a technical problem, in collaboration with me, is not the best way to see if he is really a skilled programmer or skilled specialist, what strategy should I then use? What would be a good way of telling if a candidate is really a good technical match for the job?
interviewing developer new-hires
edited Apr 13 '17 at 12:48
Community♦
1
asked Nov 18 '14 at 11:26
someName
1633
closed as too broad by Jim G., gnat, Joe Strazzere, Telastyn, Garrison Neely Nov 18 '14 at 20:05
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
will you collaborate on real projects...why on interview problem theN?
– amar
Nov 18 '14 at 12:28
This is not a bad question, though it could be cleaned up to be more readable. Just because the question is difficult does not mean that the question is off topic.
– IDrinkandIKnowThings
Nov 18 '14 at 18:01
This and its links answers your question wonderfully blog.codinghorror.com/why-cant-programmers-program
– Dave Johnson
Nov 18 '14 at 18:26
suggest improvements |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I recently held a couple of interviews with possible candidates for a possition as "software developer", and in order to get a sense of their technical skills and way of reasoning, I gave them a small problem to be solved in collaboration with me. But as I wrote about in this question, that didn't quite go as well as expected as they seemed to lack even very fundamental programming skills. Maybe due to extraordinary nervousness, maybe due to cultural differences (they were from India, and perhaps questioning their expertise is rude?), and maybe due to plain-old lack of technical skills. I don't know, and specifically I don't know if I can use a poor performance to conclude lack of skills.
That leads me to: if asking the applicant to solve a technical problem, in collaboration with me, is not the best way to see if he is really a skilled programmer or skilled specialist, what strategy should I then use? What would be a good way of telling if a candidate is really a good technical match for the job?
interviewing developer new-hires
edited Apr 13 '17 at 12:48
Community♦
1
asked Nov 18 '14 at 11:26
someName
1633
I recently held a couple of interviews with possible candidates for a possition as "software developer", and in order to get a sense of their technical skills and way of reasoning, I gave them a small problem to be solved in collaboration with me. But as I wrote about in this question, that didn't quite go as well as expected as they seemed to lack even very fundamental programming skills. Maybe due to extraordinary nervousness, maybe due to cultural differences (they were from India, and perhaps questioning their expertise is rude?), and maybe due to plain-old lack of technical skills. I don't know, and specifically I don't know if I can use a poor performance to conclude lack of skills.
That leads me to: if asking the applicant to solve a technical problem, in collaboration with me, is not the best way to see if he is really a skilled programmer or skilled specialist, what strategy should I then use? What would be a good way of telling if a candidate is really a good technical match for the job?
interviewing developer new-hires
edited Apr 13 '17 at 12:48
Community♦
1
asked Nov 18 '14 at 11:26
someName
1633
edited Apr 13 '17 at 12:48
Community♦
1
edited Apr 13 '17 at 12:48
Community♦
1
edited Apr 13 '17 at 12:48
Community♦
1
1
asked Nov 18 '14 at 11:26
someName
1633
asked Nov 18 '14 at 11:26
someName
1633
asked Nov 18 '14 at 11:26
someName
1633
1633
closed as too broad by Jim G., gnat, Joe Strazzere, Telastyn, Garrison Neely Nov 18 '14 at 20:05
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as too broad by Jim G., gnat, Joe Strazzere, Telastyn, Garrison Neely Nov 18 '14 at 20:05
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
will you collaborate on real projects...why on interview problem theN?
– amar
Nov 18 '14 at 12:28
This is not a bad question, though it could be cleaned up to be more readable. Just because the question is difficult does not mean that the question is off topic.
– IDrinkandIKnowThings
Nov 18 '14 at 18:01
This and its links answers your question wonderfully blog.codinghorror.com/why-cant-programmers-program
– Dave Johnson
Nov 18 '14 at 18:26
suggest improvements |Â
will you collaborate on real projects...why on interview problem theN?
– amar
Nov 18 '14 at 12:28
This is not a bad question, though it could be cleaned up to be more readable. Just because the question is difficult does not mean that the question is off topic.
– IDrinkandIKnowThings
Nov 18 '14 at 18:01
This and its links answers your question wonderfully blog.codinghorror.com/why-cant-programmers-program
– Dave Johnson
Nov 18 '14 at 18:26
will you collaborate on real projects...why on interview problem theN?
– amar
Nov 18 '14 at 12:28
will you collaborate on real projects...why on interview problem theN?
– amar
Nov 18 '14 at 12:28
This is not a bad question, though it could be cleaned up to be more readable. Just because the question is difficult does not mean that the question is off topic.
– IDrinkandIKnowThings
Nov 18 '14 at 18:01
This is not a bad question, though it could be cleaned up to be more readable. Just because the question is difficult does not mean that the question is off topic.
– IDrinkandIKnowThings
Nov 18 '14 at 18:01
This and its links answers your question wonderfully blog.codinghorror.com/why-cant-programmers-program
– Dave Johnson
Nov 18 '14 at 18:26
This and its links answers your question wonderfully blog.codinghorror.com/why-cant-programmers-program
– Dave Johnson
Nov 18 '14 at 18:26
suggest improvements |Â
3 Answers
3
active
oldest
votes
up vote
2
down vote
I think a technical test is fine if the role is a technical role. Let's face it if they can't do a simple test under interview conditions, how well are they going to cope in your organization if things get stressful?
The only thing to be mindful of is that your test is geared towards the right skill level for the role you're advertising. If it's a junior/entry-level position then don't make the test include advanced topics that they are unlikely to know about. Assuming you're a technical person then you should be able to use your own judgment and experience to know what sort of capabilities you need from a successful candidate, and gear the test accordingly.
I would say in your current situation that it sounds like the applicants so far are just unsuitable for the role and you shouldn't be afraid to turn them down if you don't think they're up to the task. I've recruited for technical positions many times before and only once have I made the mistake of giving someone a chance that I knew deep down was probably under-qualified.
answered Nov 18 '14 at 11:37
Will Appleby
48634
There are very different kinds of stress and you can't conclude that because somebody handles on kind of stress well/badly that it's the same for other kinds of stress.
– CodesInChaos
Nov 19 '14 at 10:01
suggest improvements |Â
up vote
2
down vote
Some companies like to screen candidates before an interview by asking them to solve a few basic problems through a web-based platform with a time limit. The nice thing about this approach is that it more closely simulates the real world, where developers have access to other resources, including the Internet for help. It also means that, due to the time limit, you get a pretty good idea of how good they really are before having to interview them. To verify that they didn't cheat and had someone else write the code, you can quiz them about their responses during the in-person interview. If you're concerned about having to interview unqualified candidates, this is a way to screen them.
With that said though, you should still ask them some other basic questions during the interview. You probably don't want to hire people that have to Google everything beforehand, and it's important to understand how a candidate thinks through a solution. For example, if you ask them to design an algorithm to solve a problem, you may want to observe certain patterns: do they understand algorithm complexity? Memory usage? Are they checking the code for errors properly, with good test cases? Are they considering edge cases? Do they actually know the basic syntax of the language they are working with? Do they stop at the first working solution they find or do they try to find a better one?
Regarding your concern that it's nervousness or cultural differences that is causing this, I don't think this is the case. Nervousness can certainly cause candidates to forget certain details, but they shouldn't go from competent to completely incapable of writing basic code. You can easily test whether they just "forgot" or if they really have no idea what they're doing by bringing up the issues they missed in conversation. For example, if a candidate doesn't consider a particular special case for a solution, you can mention it and closely pay attention to how the candidate handles it. If the candidate has something to write or talk about based on your suggestion, that's a good sign. If the candidate reacts with confusion, that should be a red flag. If being able to work under pressure is important in your organization though, you should look for candidates that can do so during an interview. As for cultural differences, that is even less likely. Candidates, no matter where they are from, go to interviews expecting to be grilled on what they know. If the job description clearly listed the requirements, they should be ready for questions on each one. There shouldn't be any surprises.
It's important to understand that a lot of people apply for software development jobs with no idea what they are doing (as responses to your other question explained). This is not your fault. It's perfectly fine to test them for some minimum skills and decline to hire them if they don't pass.
answered Nov 18 '14 at 12:20
CynicalProgrammer
95756
suggest improvements |Â
up vote
1
down vote
This is an opinion based question. Here's my take:
Open Source
Open source is good. Candidates who've made contributions to prominent open source projects like Apache, Mono, etc., must definitely write good code. Those organizations have a good code review process. Even if the projects aren't popular, you get a chance to do a code review on your own before you invite the person.
Ice breaker before Interview
I can tell you on my recent interview with Google I had a breakdown. Serious adrenaline rush, and it impaired my thought process. The interviewer started with a coding question, and I couldn't think straight. Phone interviews are bad, in general. Try to have a small warm up of some sort, just talk in general to get the candidate comfortable. Be nice.
Face-to-face Behavioral
Having at least one behavioral face-to-face interview is very important. You get to know the person's attitude towards things, and how they handle different situations, etc.
Technical Interview
Although people might disagree with this, I kind of like Google's academic approach to interviews. Give them a problem to solve, and see what kind of thought process they have, how they approach the problem. As a computer engineer, that is important. It's fine if they don't get the right solution.
In addition, you probably want to ask questions specific to the job. Like if the job involves SQL, you can ask things like database architecture, normalization, indexes, parallel queries, improving query based on query plan.
You want to make sure that they know their field. You wouldn't want to hire an incompetent architect to build your house, would you?
Good, clean code
I'd like to know that their code is clean and readable. They are able to recognize bad design and fix it. They know DRY and some of SOLID. A few design patterns, and basic OOP.
Basic Algorithms and Scalability
Recognize where solutions can and need to be improved for scalability. For instance, on Mobile development, I wouldn't want them to query a thousand items and bubble sort them.
answered Nov 18 '14 at 17:39
harsimranb
346310
suggest improvements |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
I think a technical test is fine if the role is a technical role. Let's face it if they can't do a simple test under interview conditions, how well are they going to cope in your organization if things get stressful?
The only thing to be mindful of is that your test is geared towards the right skill level for the role you're advertising. If it's a junior/entry-level position then don't make the test include advanced topics that they are unlikely to know about. Assuming you're a technical person then you should be able to use your own judgment and experience to know what sort of capabilities you need from a successful candidate, and gear the test accordingly.
I would say in your current situation that it sounds like the applicants so far are just unsuitable for the role and you shouldn't be afraid to turn them down if you don't think they're up to the task. I've recruited for technical positions many times before and only once have I made the mistake of giving someone a chance that I knew deep down was probably under-qualified.
answered Nov 18 '14 at 11:37
Will Appleby
48634
There are very different kinds of stress and you can't conclude that because somebody handles on kind of stress well/badly that it's the same for other kinds of stress.
– CodesInChaos
Nov 19 '14 at 10:01
suggest improvements |Â
up vote
2
down vote
I think a technical test is fine if the role is a technical role. Let's face it if they can't do a simple test under interview conditions, how well are they going to cope in your organization if things get stressful?
The only thing to be mindful of is that your test is geared towards the right skill level for the role you're advertising. If it's a junior/entry-level position then don't make the test include advanced topics that they are unlikely to know about. Assuming you're a technical person then you should be able to use your own judgment and experience to know what sort of capabilities you need from a successful candidate, and gear the test accordingly.
I would say in your current situation that it sounds like the applicants so far are just unsuitable for the role and you shouldn't be afraid to turn them down if you don't think they're up to the task. I've recruited for technical positions many times before and only once have I made the mistake of giving someone a chance that I knew deep down was probably under-qualified.
answered Nov 18 '14 at 11:37
Will Appleby
48634
There are very different kinds of stress and you can't conclude that because somebody handles on kind of stress well/badly that it's the same for other kinds of stress.
– CodesInChaos
Nov 19 '14 at 10:01
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
I think a technical test is fine if the role is a technical role. Let's face it if they can't do a simple test under interview conditions, how well are they going to cope in your organization if things get stressful?
The only thing to be mindful of is that your test is geared towards the right skill level for the role you're advertising. If it's a junior/entry-level position then don't make the test include advanced topics that they are unlikely to know about. Assuming you're a technical person then you should be able to use your own judgment and experience to know what sort of capabilities you need from a successful candidate, and gear the test accordingly.
I would say in your current situation that it sounds like the applicants so far are just unsuitable for the role and you shouldn't be afraid to turn them down if you don't think they're up to the task. I've recruited for technical positions many times before and only once have I made the mistake of giving someone a chance that I knew deep down was probably under-qualified.
answered Nov 18 '14 at 11:37
Will Appleby
48634
I think a technical test is fine if the role is a technical role. Let's face it if they can't do a simple test under interview conditions, how well are they going to cope in your organization if things get stressful?
The only thing to be mindful of is that your test is geared towards the right skill level for the role you're advertising. If it's a junior/entry-level position then don't make the test include advanced topics that they are unlikely to know about. Assuming you're a technical person then you should be able to use your own judgment and experience to know what sort of capabilities you need from a successful candidate, and gear the test accordingly.
I would say in your current situation that it sounds like the applicants so far are just unsuitable for the role and you shouldn't be afraid to turn them down if you don't think they're up to the task. I've recruited for technical positions many times before and only once have I made the mistake of giving someone a chance that I knew deep down was probably under-qualified.
answered Nov 18 '14 at 11:37
Will Appleby
48634
answered Nov 18 '14 at 11:37
Will Appleby
48634
answered Nov 18 '14 at 11:37
Will Appleby
48634
answered Nov 18 '14 at 11:37
Will Appleby
48634
48634
There are very different kinds of stress and you can't conclude that because somebody handles on kind of stress well/badly that it's the same for other kinds of stress.
– CodesInChaos
Nov 19 '14 at 10:01
suggest improvements |Â
There are very different kinds of stress and you can't conclude that because somebody handles on kind of stress well/badly that it's the same for other kinds of stress.
– CodesInChaos
Nov 19 '14 at 10:01
There are very different kinds of stress and you can't conclude that because somebody handles on kind of stress well/badly that it's the same for other kinds of stress.
– CodesInChaos
Nov 19 '14 at 10:01
There are very different kinds of stress and you can't conclude that because somebody handles on kind of stress well/badly that it's the same for other kinds of stress.
– CodesInChaos
Nov 19 '14 at 10:01
suggest improvements |Â
up vote
2
down vote
Some companies like to screen candidates before an interview by asking them to solve a few basic problems through a web-based platform with a time limit. The nice thing about this approach is that it more closely simulates the real world, where developers have access to other resources, including the Internet for help. It also means that, due to the time limit, you get a pretty good idea of how good they really are before having to interview them. To verify that they didn't cheat and had someone else write the code, you can quiz them about their responses during the in-person interview. If you're concerned about having to interview unqualified candidates, this is a way to screen them.
With that said though, you should still ask them some other basic questions during the interview. You probably don't want to hire people that have to Google everything beforehand, and it's important to understand how a candidate thinks through a solution. For example, if you ask them to design an algorithm to solve a problem, you may want to observe certain patterns: do they understand algorithm complexity? Memory usage? Are they checking the code for errors properly, with good test cases? Are they considering edge cases? Do they actually know the basic syntax of the language they are working with? Do they stop at the first working solution they find or do they try to find a better one?
Regarding your concern that it's nervousness or cultural differences that is causing this, I don't think this is the case. Nervousness can certainly cause candidates to forget certain details, but they shouldn't go from competent to completely incapable of writing basic code. You can easily test whether they just "forgot" or if they really have no idea what they're doing by bringing up the issues they missed in conversation. For example, if a candidate doesn't consider a particular special case for a solution, you can mention it and closely pay attention to how the candidate handles it. If the candidate has something to write or talk about based on your suggestion, that's a good sign. If the candidate reacts with confusion, that should be a red flag. If being able to work under pressure is important in your organization though, you should look for candidates that can do so during an interview. As for cultural differences, that is even less likely. Candidates, no matter where they are from, go to interviews expecting to be grilled on what they know. If the job description clearly listed the requirements, they should be ready for questions on each one. There shouldn't be any surprises.
It's important to understand that a lot of people apply for software development jobs with no idea what they are doing (as responses to your other question explained). This is not your fault. It's perfectly fine to test them for some minimum skills and decline to hire them if they don't pass.
answered Nov 18 '14 at 12:20
CynicalProgrammer
95756
suggest improvements |Â
up vote
2
down vote
Some companies like to screen candidates before an interview by asking them to solve a few basic problems through a web-based platform with a time limit. The nice thing about this approach is that it more closely simulates the real world, where developers have access to other resources, including the Internet for help. It also means that, due to the time limit, you get a pretty good idea of how good they really are before having to interview them. To verify that they didn't cheat and had someone else write the code, you can quiz them about their responses during the in-person interview. If you're concerned about having to interview unqualified candidates, this is a way to screen them.
With that said though, you should still ask them some other basic questions during the interview. You probably don't want to hire people that have to Google everything beforehand, and it's important to understand how a candidate thinks through a solution. For example, if you ask them to design an algorithm to solve a problem, you may want to observe certain patterns: do they understand algorithm complexity? Memory usage? Are they checking the code for errors properly, with good test cases? Are they considering edge cases? Do they actually know the basic syntax of the language they are working with? Do they stop at the first working solution they find or do they try to find a better one?
Regarding your concern that it's nervousness or cultural differences that is causing this, I don't think this is the case. Nervousness can certainly cause candidates to forget certain details, but they shouldn't go from competent to completely incapable of writing basic code. You can easily test whether they just "forgot" or if they really have no idea what they're doing by bringing up the issues they missed in conversation. For example, if a candidate doesn't consider a particular special case for a solution, you can mention it and closely pay attention to how the candidate handles it. If the candidate has something to write or talk about based on your suggestion, that's a good sign. If the candidate reacts with confusion, that should be a red flag. If being able to work under pressure is important in your organization though, you should look for candidates that can do so during an interview. As for cultural differences, that is even less likely. Candidates, no matter where they are from, go to interviews expecting to be grilled on what they know. If the job description clearly listed the requirements, they should be ready for questions on each one. There shouldn't be any surprises.
It's important to understand that a lot of people apply for software development jobs with no idea what they are doing (as responses to your other question explained). This is not your fault. It's perfectly fine to test them for some minimum skills and decline to hire them if they don't pass.
answered Nov 18 '14 at 12:20
CynicalProgrammer
95756
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
Some companies like to screen candidates before an interview by asking them to solve a few basic problems through a web-based platform with a time limit. The nice thing about this approach is that it more closely simulates the real world, where developers have access to other resources, including the Internet for help. It also means that, due to the time limit, you get a pretty good idea of how good they really are before having to interview them. To verify that they didn't cheat and had someone else write the code, you can quiz them about their responses during the in-person interview. If you're concerned about having to interview unqualified candidates, this is a way to screen them.
With that said though, you should still ask them some other basic questions during the interview. You probably don't want to hire people that have to Google everything beforehand, and it's important to understand how a candidate thinks through a solution. For example, if you ask them to design an algorithm to solve a problem, you may want to observe certain patterns: do they understand algorithm complexity? Memory usage? Are they checking the code for errors properly, with good test cases? Are they considering edge cases? Do they actually know the basic syntax of the language they are working with? Do they stop at the first working solution they find or do they try to find a better one?
Regarding your concern that it's nervousness or cultural differences that is causing this, I don't think this is the case. Nervousness can certainly cause candidates to forget certain details, but they shouldn't go from competent to completely incapable of writing basic code. You can easily test whether they just "forgot" or if they really have no idea what they're doing by bringing up the issues they missed in conversation. For example, if a candidate doesn't consider a particular special case for a solution, you can mention it and closely pay attention to how the candidate handles it. If the candidate has something to write or talk about based on your suggestion, that's a good sign. If the candidate reacts with confusion, that should be a red flag. If being able to work under pressure is important in your organization though, you should look for candidates that can do so during an interview. As for cultural differences, that is even less likely. Candidates, no matter where they are from, go to interviews expecting to be grilled on what they know. If the job description clearly listed the requirements, they should be ready for questions on each one. There shouldn't be any surprises.
It's important to understand that a lot of people apply for software development jobs with no idea what they are doing (as responses to your other question explained). This is not your fault. It's perfectly fine to test them for some minimum skills and decline to hire them if they don't pass.
answered Nov 18 '14 at 12:20
CynicalProgrammer
95756
Some companies like to screen candidates before an interview by asking them to solve a few basic problems through a web-based platform with a time limit. The nice thing about this approach is that it more closely simulates the real world, where developers have access to other resources, including the Internet for help. It also means that, due to the time limit, you get a pretty good idea of how good they really are before having to interview them. To verify that they didn't cheat and had someone else write the code, you can quiz them about their responses during the in-person interview. If you're concerned about having to interview unqualified candidates, this is a way to screen them.
With that said though, you should still ask them some other basic questions during the interview. You probably don't want to hire people that have to Google everything beforehand, and it's important to understand how a candidate thinks through a solution. For example, if you ask them to design an algorithm to solve a problem, you may want to observe certain patterns: do they understand algorithm complexity? Memory usage? Are they checking the code for errors properly, with good test cases? Are they considering edge cases? Do they actually know the basic syntax of the language they are working with? Do they stop at the first working solution they find or do they try to find a better one?
Regarding your concern that it's nervousness or cultural differences that is causing this, I don't think this is the case. Nervousness can certainly cause candidates to forget certain details, but they shouldn't go from competent to completely incapable of writing basic code. You can easily test whether they just "forgot" or if they really have no idea what they're doing by bringing up the issues they missed in conversation. For example, if a candidate doesn't consider a particular special case for a solution, you can mention it and closely pay attention to how the candidate handles it. If the candidate has something to write or talk about based on your suggestion, that's a good sign. If the candidate reacts with confusion, that should be a red flag. If being able to work under pressure is important in your organization though, you should look for candidates that can do so during an interview. As for cultural differences, that is even less likely. Candidates, no matter where they are from, go to interviews expecting to be grilled on what they know. If the job description clearly listed the requirements, they should be ready for questions on each one. There shouldn't be any surprises.
It's important to understand that a lot of people apply for software development jobs with no idea what they are doing (as responses to your other question explained). This is not your fault. It's perfectly fine to test them for some minimum skills and decline to hire them if they don't pass.
answered Nov 18 '14 at 12:20
CynicalProgrammer
95756
answered Nov 18 '14 at 12:20
CynicalProgrammer
95756
answered Nov 18 '14 at 12:20
CynicalProgrammer
95756
answered Nov 18 '14 at 12:20
CynicalProgrammer
95756
95756
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
This is an opinion based question. Here's my take:
Open Source
Open source is good. Candidates who've made contributions to prominent open source projects like Apache, Mono, etc., must definitely write good code. Those organizations have a good code review process. Even if the projects aren't popular, you get a chance to do a code review on your own before you invite the person.
Ice breaker before Interview
I can tell you on my recent interview with Google I had a breakdown. Serious adrenaline rush, and it impaired my thought process. The interviewer started with a coding question, and I couldn't think straight. Phone interviews are bad, in general. Try to have a small warm up of some sort, just talk in general to get the candidate comfortable. Be nice.
Face-to-face Behavioral
Having at least one behavioral face-to-face interview is very important. You get to know the person's attitude towards things, and how they handle different situations, etc.
Technical Interview
Although people might disagree with this, I kind of like Google's academic approach to interviews. Give them a problem to solve, and see what kind of thought process they have, how they approach the problem. As a computer engineer, that is important. It's fine if they don't get the right solution.
In addition, you probably want to ask questions specific to the job. Like if the job involves SQL, you can ask things like database architecture, normalization, indexes, parallel queries, improving query based on query plan.
You want to make sure that they know their field. You wouldn't want to hire an incompetent architect to build your house, would you?
Good, clean code
I'd like to know that their code is clean and readable. They are able to recognize bad design and fix it. They know DRY and some of SOLID. A few design patterns, and basic OOP.
Basic Algorithms and Scalability
Recognize where solutions can and need to be improved for scalability. For instance, on Mobile development, I wouldn't want them to query a thousand items and bubble sort them.
answered Nov 18 '14 at 17:39
harsimranb
346310
suggest improvements |Â
up vote
1
down vote
This is an opinion based question. Here's my take:
Open Source
Open source is good. Candidates who've made contributions to prominent open source projects like Apache, Mono, etc., must definitely write good code. Those organizations have a good code review process. Even if the projects aren't popular, you get a chance to do a code review on your own before you invite the person.
Ice breaker before Interview
I can tell you on my recent interview with Google I had a breakdown. Serious adrenaline rush, and it impaired my thought process. The interviewer started with a coding question, and I couldn't think straight. Phone interviews are bad, in general. Try to have a small warm up of some sort, just talk in general to get the candidate comfortable. Be nice.
Face-to-face Behavioral
Having at least one behavioral face-to-face interview is very important. You get to know the person's attitude towards things, and how they handle different situations, etc.
Technical Interview
Although people might disagree with this, I kind of like Google's academic approach to interviews. Give them a problem to solve, and see what kind of thought process they have, how they approach the problem. As a computer engineer, that is important. It's fine if they don't get the right solution.
In addition, you probably want to ask questions specific to the job. Like if the job involves SQL, you can ask things like database architecture, normalization, indexes, parallel queries, improving query based on query plan.
You want to make sure that they know their field. You wouldn't want to hire an incompetent architect to build your house, would you?
Good, clean code
I'd like to know that their code is clean and readable. They are able to recognize bad design and fix it. They know DRY and some of SOLID. A few design patterns, and basic OOP.
Basic Algorithms and Scalability
Recognize where solutions can and need to be improved for scalability. For instance, on Mobile development, I wouldn't want them to query a thousand items and bubble sort them.
answered Nov 18 '14 at 17:39
harsimranb
346310
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
This is an opinion based question. Here's my take:
Open Source
Open source is good. Candidates who've made contributions to prominent open source projects like Apache, Mono, etc., must definitely write good code. Those organizations have a good code review process. Even if the projects aren't popular, you get a chance to do a code review on your own before you invite the person.
Ice breaker before Interview
I can tell you on my recent interview with Google I had a breakdown. Serious adrenaline rush, and it impaired my thought process. The interviewer started with a coding question, and I couldn't think straight. Phone interviews are bad, in general. Try to have a small warm up of some sort, just talk in general to get the candidate comfortable. Be nice.
Face-to-face Behavioral
Having at least one behavioral face-to-face interview is very important. You get to know the person's attitude towards things, and how they handle different situations, etc.
Technical Interview
Although people might disagree with this, I kind of like Google's academic approach to interviews. Give them a problem to solve, and see what kind of thought process they have, how they approach the problem. As a computer engineer, that is important. It's fine if they don't get the right solution.
In addition, you probably want to ask questions specific to the job. Like if the job involves SQL, you can ask things like database architecture, normalization, indexes, parallel queries, improving query based on query plan.
You want to make sure that they know their field. You wouldn't want to hire an incompetent architect to build your house, would you?
Good, clean code
I'd like to know that their code is clean and readable. They are able to recognize bad design and fix it. They know DRY and some of SOLID. A few design patterns, and basic OOP.
Basic Algorithms and Scalability
Recognize where solutions can and need to be improved for scalability. For instance, on Mobile development, I wouldn't want them to query a thousand items and bubble sort them.
answered Nov 18 '14 at 17:39
harsimranb
346310
This is an opinion based question. Here's my take:
Open Source
Open source is good. Candidates who've made contributions to prominent open source projects like Apache, Mono, etc., must definitely write good code. Those organizations have a good code review process. Even if the projects aren't popular, you get a chance to do a code review on your own before you invite the person.
Ice breaker before Interview
I can tell you on my recent interview with Google I had a breakdown. Serious adrenaline rush, and it impaired my thought process. The interviewer started with a coding question, and I couldn't think straight. Phone interviews are bad, in general. Try to have a small warm up of some sort, just talk in general to get the candidate comfortable. Be nice.
Face-to-face Behavioral
Having at least one behavioral face-to-face interview is very important. You get to know the person's attitude towards things, and how they handle different situations, etc.
Technical Interview
Although people might disagree with this, I kind of like Google's academic approach to interviews. Give them a problem to solve, and see what kind of thought process they have, how they approach the problem. As a computer engineer, that is important. It's fine if they don't get the right solution.
In addition, you probably want to ask questions specific to the job. Like if the job involves SQL, you can ask things like database architecture, normalization, indexes, parallel queries, improving query based on query plan.
You want to make sure that they know their field. You wouldn't want to hire an incompetent architect to build your house, would you?
Good, clean code
I'd like to know that their code is clean and readable. They are able to recognize bad design and fix it. They know DRY and some of SOLID. A few design patterns, and basic OOP.
Basic Algorithms and Scalability
Recognize where solutions can and need to be improved for scalability. For instance, on Mobile development, I wouldn't want them to query a thousand items and bubble sort them.
answered Nov 18 '14 at 17:39
harsimranb
346310
edited Nov 18 '14 at 18:54
answered Nov 18 '14 at 17:39
harsimranb
346310
answered Nov 18 '14 at 17:39
harsimranb
346310
answered Nov 18 '14 at 17:39
harsimranb
346310
346310
suggest improvements |Â
suggest improvements |Â
will you collaborate on real projects...why on interview problem theN?
– amar
Nov 18 '14 at 12:28
This is not a bad question, though it could be cleaned up to be more readable. Just because the question is difficult does not mean that the question is off topic.
– IDrinkandIKnowThings
Nov 18 '14 at 18:01
This and its links answers your question wonderfully blog.codinghorror.com/why-cant-programmers-program
– Dave Johnson
Nov 18 '14 at 18:26