Mixing
![How to move into a development career with no formal programming education, but lots of informal experience [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
How to conduct an interview for a subject I'm not really good at?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
12
down vote
favorite
I'm currently working for a small company as a website/software developer. I mainly write the server side code; the interfaces I create for the website are bland and don't really interact with the user.
I tried to learn JavaScript, J-Query and Ajax but it seemed too much because I rarely had time for anything else.
My company decided to hire a few client side developers who can write the client side code. We are going to conduct a face-to-face interview in about 3 days with the interviewees.
The problem is there is no one that is good at that so they asked me to test the technical skills of the interviewees.
The only thing I am good at is the basics of JavaScript. I don't think the interviewees will have any problem answering the questions that I put in front of them as it's all basic scripting.
How can I best interview people when I do not have the necessary skills to determine whether they will be able to perform the job?
interviewing software-industry hiring-process recruitment careers
edited Jul 8 '13 at 10:40
TooTone
1,69011130
asked Jul 7 '13 at 13:26
Mohit Mittal
847
add a comment |Â
up vote
12
down vote
favorite
I'm currently working for a small company as a website/software developer. I mainly write the server side code; the interfaces I create for the website are bland and don't really interact with the user.
I tried to learn JavaScript, J-Query and Ajax but it seemed too much because I rarely had time for anything else.
My company decided to hire a few client side developers who can write the client side code. We are going to conduct a face-to-face interview in about 3 days with the interviewees.
The problem is there is no one that is good at that so they asked me to test the technical skills of the interviewees.
The only thing I am good at is the basics of JavaScript. I don't think the interviewees will have any problem answering the questions that I put in front of them as it's all basic scripting.
How can I best interview people when I do not have the necessary skills to determine whether they will be able to perform the job?
interviewing software-industry hiring-process recruitment careers
edited Jul 8 '13 at 10:40
TooTone
1,69011130
asked Jul 7 '13 at 13:26
Mohit Mittal
847
add a comment |Â
up vote
12
down vote
favorite
up vote
12
down vote
favorite
I'm currently working for a small company as a website/software developer. I mainly write the server side code; the interfaces I create for the website are bland and don't really interact with the user.
I tried to learn JavaScript, J-Query and Ajax but it seemed too much because I rarely had time for anything else.
My company decided to hire a few client side developers who can write the client side code. We are going to conduct a face-to-face interview in about 3 days with the interviewees.
The problem is there is no one that is good at that so they asked me to test the technical skills of the interviewees.
The only thing I am good at is the basics of JavaScript. I don't think the interviewees will have any problem answering the questions that I put in front of them as it's all basic scripting.
How can I best interview people when I do not have the necessary skills to determine whether they will be able to perform the job?
interviewing software-industry hiring-process recruitment careers
edited Jul 8 '13 at 10:40
TooTone
1,69011130
asked Jul 7 '13 at 13:26
Mohit Mittal
847
I'm currently working for a small company as a website/software developer. I mainly write the server side code; the interfaces I create for the website are bland and don't really interact with the user.
I tried to learn JavaScript, J-Query and Ajax but it seemed too much because I rarely had time for anything else.
My company decided to hire a few client side developers who can write the client side code. We are going to conduct a face-to-face interview in about 3 days with the interviewees.
The problem is there is no one that is good at that so they asked me to test the technical skills of the interviewees.
The only thing I am good at is the basics of JavaScript. I don't think the interviewees will have any problem answering the questions that I put in front of them as it's all basic scripting.
How can I best interview people when I do not have the necessary skills to determine whether they will be able to perform the job?
interviewing software-industry hiring-process recruitment careers
edited Jul 8 '13 at 10:40
TooTone
1,69011130
asked Jul 7 '13 at 13:26
Mohit Mittal
847
edited Jul 8 '13 at 10:40
TooTone
1,69011130
edited Jul 8 '13 at 10:40
TooTone
1,69011130
edited Jul 8 '13 at 10:40
TooTone
1,69011130
1,69011130
asked Jul 7 '13 at 13:26
Mohit Mittal
847
asked Jul 7 '13 at 13:26
Mohit Mittal
847
asked Jul 7 '13 at 13:26
Mohit Mittal
847
847
add a comment |Â
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
20
down vote
accepted
I have sometimes been pulled into interviews for positions where I'm not particularly skilled, and as a specialist I've often been interviewed by people who don't know my area very well. Here are things I've seen work:
Before interviewing anybody, try to learn the "101" stuff in the relevant area. For Javascript, there are assorted resources online. Note: this isn't so you'll be able to ask good questions; you probably won't. The purpose of this is so you'll be able to spot BS.
Ask behavioral questions that get them talking about the technical issues. "What was the hardest bug you've had to solve?" is a good one; you can ask them to explain what the problem was, what approaches they took, what they ultimately did, and so on. This may or may not tell you about the quality of their code directly, but it will tell you a lot about how they analyze, break down, and ultimately solve problems. And if they drop implementation details you can take notes and maybe do a sanity-check later.
Ask them to talk in some detail about a significant project -- architecture, design, UX considerations, testing, deployment, maintenance, etc. It almost doesn't matter what language the code is in for most of this; you're trying to answer the deeper question of "can this person write software we'll want to live with?".
Ask for a demo. Pick something interesting and ask for a walk-through of the code behind it. As the candidate is explaining what it does you should be looking for the usual code-hygeine things -- comments, clear organization, comprehensible names, and so on. If he struggles to explain it that's a source of concern. (A quick look at the code and "oh yeah, that's where I put that" is fine; I mean if he's stumped.)
Be sure to get technical references, not just managerial ones, and ask them about the candidate's technical strengths and weaknesses.
answered Jul 7 '13 at 17:22
Monica Cellio♦
43.7k17114191
3
I do pretty much the same - another one I consider almost a must is to ask them to explain something I don't know - "just cover the basics of what X technology is and when it is most useful" - if they can't do this in a short span of time and a comprehensible way, this isn't a good fit. Particularly where your team doesn't have an expert already - any "expert" you hire had better be able to explain to non-expert some simple concepts so you can interact successfully.
– bethlakshmi
Jul 8 '13 at 19:12
@bethlakshmi, that's an excellent point; whoever is hired into this position is going to need to be able to explain his design/implementation decisions in ways everyone else can understand, well enough that they can ask relevant questions and get answers.
– Monica Cellio♦
Jul 8 '13 at 19:16
yep. Worse mistake I ever made was hiring a guy who seemed to make sense to other experts, but who made no sense to me, the non-expert. Turned out, the guy was smart, but very bad at communicating - so he made complicated things that were of no use but worked perfectly within their own flawed assumptions
– bethlakshmi
Jul 8 '13 at 20:14
Now I'm still trying to remember which was the worst bug I've encountered... those caused by the infamous PHP #29992 might win, but I'm not sure.
– o0'.
Apr 2 '14 at 13:14
add a comment |Â
up vote
3
down vote
I'd recommend you incorporate fundamentals of software development in your interviewing strategy. As a discipline, regardless of language, there are several concerns that cut across software development/engineering:
Design Patterns: A decent project will use some kind of design pattern. A decent developer should be able to identify a specific pattern and must have implemented it at some recent point in the past. I'm no javascript ninja myself but I can hazard a guess that with frameworks like Node.js, an experienced javascript developer would have a grasp of basic software design principles
Performance: No matter the language/platform, there's usually an efficient way to do stuff and a wasteful way to do something. In java, there's the
BufferedXXXfamily of classes intended for better I/O programming and any java developer with 6 months of experience will know this. Look for such fundamental performance principles in JavaScript that a seasoned developer should know. Have a look at this article for guidanceFrameworks: As a corollary to the first point, you could look up one or two javascript frameworks and skim thru the introduction (particularly what these frameworks can achieve). Now design one or two interview questions around those. The objective here is simple: either the interviewee has used these frameworks before and can demonstrate a level of comfort that surpasses your own OR, hasn't used the framework in question BUT the person should be able to provide alternatives to the frameworks and what they can achieve
Working Problem: Thoroughly research a specific problem in javascript (you can start by looking thru one of the top voted javascript questions on SO), understand the solution and present this problem to the interviewee. It could be a bare-bones,how-to-code question or a more conceptual one, regarding best practices. The bottom line is you should know the answer and why it's the answer (in the event the interviewee is wrong or provides an alternate approach)
Ultimately, what you want in a developer is flexibility and intelligence, by-products of a firm grasp of fundamentals of software development
answered Jul 8 '13 at 0:24
kolossus
4,2211440
add a comment |Â
up vote
1
down vote
It's probably a good idea to ask them some of the 101 stuff and see how they do with it anyway - you'd expect them to answer it pretty confidently but I'm sure a few won't.
I'd also try and think of a real scenario they may work on at your company and ask them what approach they would take to solving the problem - then either research the problem yourself or maybe ask that same question on stack or another message board and see if their answer has it's merits.
Always remember to have staff on a probationary period too whereby you can get rid of them if it isn't just a good fit. Sometimes it's not about having the absolute best coder but someone that is willing to learn more and works well in a team.
answered Jul 7 '13 at 22:19
user319940
51426
I think most interviewees will be nervous and think that there is a hidden catch in the 101 questions. Then they will start thinking about it too much and falter :)
– Juha Untinen
Mar 26 '15 at 10:02
add a comment |Â
up vote
1
down vote
I ask developers to code in front of me. Ideally I know the language, but I'll accept something where I don't. If I know in advance I don't know the language, I look at the relevant details/APIs in advance to know what to expect. I'll also try to ask questions about the aspects of the technology that I do know. If I don't know in advance what the language will be (an intern knows a few languages and they don't overlap mine), that's fine. I can still check for logic in watching code and look at it in more detail later if I want.
For JavaScript, you could have the candidate code on a computer in front of you. You'll see what libraries the person uses, how he/she thinks, does research, asks about requirements, etc.
As you said, you care that the candidate can do the job. So why not give them something similar to the job. Not the actual job because that would be like getting free labor. But a made up example that uses similar skills.
answered Jul 8 '13 at 2:48
Jeanne Boyarsky
4,7741934
add a comment |Â
up vote
0
down vote
Some may think this doesn't answer your question, but I think it offers some strategies to solve the problem of hiring a qualified client-side developer. Is there a law that says you have to do this yourself?
- Work on the details for this job. Writing client-side code and UX are not the same. You may want some of both, but decide the ratio. This is the first step in getting the right person for the job. There are many devs that learn javascript, CSS & html, but couldn't design a command prompt.
- Get examples of their work.
- Hire a contractor on a part-time basis. If you make a hiring mistake, you can correct it easily by getting rid of the person for a lot less than a full-timer.
- As an option to #3, use a hiring agency. You can create a temp-to-hire situation if you want to gain a little freedom. Many people may question some of these agency's abiliy to identify technical talent. Some of better than others.
- Reach out to people in your tech. community and try to get some recommendations. Why just wait and see who applies.
As part of the interview process, focus some of the questions on the problem areas you've had. Either put them on the board to mock up some diagrams and code, but ideally get them infront of a keyboad and see what they've got. Can they write code? See what tools they use. Do they bring up browser compatibility issues? Have they seen similar problems. I was dabbling with a webfront end and met someone at a coffee shop who was able to dazzle me in less than 15 minutes. I would hire this person on the spot.
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
20
down vote
accepted
I have sometimes been pulled into interviews for positions where I'm not particularly skilled, and as a specialist I've often been interviewed by people who don't know my area very well. Here are things I've seen work:
Before interviewing anybody, try to learn the "101" stuff in the relevant area. For Javascript, there are assorted resources online. Note: this isn't so you'll be able to ask good questions; you probably won't. The purpose of this is so you'll be able to spot BS.
Ask behavioral questions that get them talking about the technical issues. "What was the hardest bug you've had to solve?" is a good one; you can ask them to explain what the problem was, what approaches they took, what they ultimately did, and so on. This may or may not tell you about the quality of their code directly, but it will tell you a lot about how they analyze, break down, and ultimately solve problems. And if they drop implementation details you can take notes and maybe do a sanity-check later.
Ask them to talk in some detail about a significant project -- architecture, design, UX considerations, testing, deployment, maintenance, etc. It almost doesn't matter what language the code is in for most of this; you're trying to answer the deeper question of "can this person write software we'll want to live with?".
Ask for a demo. Pick something interesting and ask for a walk-through of the code behind it. As the candidate is explaining what it does you should be looking for the usual code-hygeine things -- comments, clear organization, comprehensible names, and so on. If he struggles to explain it that's a source of concern. (A quick look at the code and "oh yeah, that's where I put that" is fine; I mean if he's stumped.)
Be sure to get technical references, not just managerial ones, and ask them about the candidate's technical strengths and weaknesses.
answered Jul 7 '13 at 17:22
Monica Cellio♦
43.7k17114191
3
I do pretty much the same - another one I consider almost a must is to ask them to explain something I don't know - "just cover the basics of what X technology is and when it is most useful" - if they can't do this in a short span of time and a comprehensible way, this isn't a good fit. Particularly where your team doesn't have an expert already - any "expert" you hire had better be able to explain to non-expert some simple concepts so you can interact successfully.
– bethlakshmi
Jul 8 '13 at 19:12
@bethlakshmi, that's an excellent point; whoever is hired into this position is going to need to be able to explain his design/implementation decisions in ways everyone else can understand, well enough that they can ask relevant questions and get answers.
– Monica Cellio♦
Jul 8 '13 at 19:16
yep. Worse mistake I ever made was hiring a guy who seemed to make sense to other experts, but who made no sense to me, the non-expert. Turned out, the guy was smart, but very bad at communicating - so he made complicated things that were of no use but worked perfectly within their own flawed assumptions
– bethlakshmi
Jul 8 '13 at 20:14
Now I'm still trying to remember which was the worst bug I've encountered... those caused by the infamous PHP #29992 might win, but I'm not sure.
– o0'.
Apr 2 '14 at 13:14
add a comment |Â
up vote
20
down vote
accepted
I have sometimes been pulled into interviews for positions where I'm not particularly skilled, and as a specialist I've often been interviewed by people who don't know my area very well. Here are things I've seen work:
Before interviewing anybody, try to learn the "101" stuff in the relevant area. For Javascript, there are assorted resources online. Note: this isn't so you'll be able to ask good questions; you probably won't. The purpose of this is so you'll be able to spot BS.
Ask behavioral questions that get them talking about the technical issues. "What was the hardest bug you've had to solve?" is a good one; you can ask them to explain what the problem was, what approaches they took, what they ultimately did, and so on. This may or may not tell you about the quality of their code directly, but it will tell you a lot about how they analyze, break down, and ultimately solve problems. And if they drop implementation details you can take notes and maybe do a sanity-check later.
Ask them to talk in some detail about a significant project -- architecture, design, UX considerations, testing, deployment, maintenance, etc. It almost doesn't matter what language the code is in for most of this; you're trying to answer the deeper question of "can this person write software we'll want to live with?".
Ask for a demo. Pick something interesting and ask for a walk-through of the code behind it. As the candidate is explaining what it does you should be looking for the usual code-hygeine things -- comments, clear organization, comprehensible names, and so on. If he struggles to explain it that's a source of concern. (A quick look at the code and "oh yeah, that's where I put that" is fine; I mean if he's stumped.)
Be sure to get technical references, not just managerial ones, and ask them about the candidate's technical strengths and weaknesses.
answered Jul 7 '13 at 17:22
Monica Cellio♦
43.7k17114191
3
I do pretty much the same - another one I consider almost a must is to ask them to explain something I don't know - "just cover the basics of what X technology is and when it is most useful" - if they can't do this in a short span of time and a comprehensible way, this isn't a good fit. Particularly where your team doesn't have an expert already - any "expert" you hire had better be able to explain to non-expert some simple concepts so you can interact successfully.
– bethlakshmi
Jul 8 '13 at 19:12
@bethlakshmi, that's an excellent point; whoever is hired into this position is going to need to be able to explain his design/implementation decisions in ways everyone else can understand, well enough that they can ask relevant questions and get answers.
– Monica Cellio♦
Jul 8 '13 at 19:16
yep. Worse mistake I ever made was hiring a guy who seemed to make sense to other experts, but who made no sense to me, the non-expert. Turned out, the guy was smart, but very bad at communicating - so he made complicated things that were of no use but worked perfectly within their own flawed assumptions
– bethlakshmi
Jul 8 '13 at 20:14
Now I'm still trying to remember which was the worst bug I've encountered... those caused by the infamous PHP #29992 might win, but I'm not sure.
– o0'.
Apr 2 '14 at 13:14
add a comment |Â
up vote
20
down vote
accepted
up vote
20
down vote
accepted
I have sometimes been pulled into interviews for positions where I'm not particularly skilled, and as a specialist I've often been interviewed by people who don't know my area very well. Here are things I've seen work:
Before interviewing anybody, try to learn the "101" stuff in the relevant area. For Javascript, there are assorted resources online. Note: this isn't so you'll be able to ask good questions; you probably won't. The purpose of this is so you'll be able to spot BS.
Ask behavioral questions that get them talking about the technical issues. "What was the hardest bug you've had to solve?" is a good one; you can ask them to explain what the problem was, what approaches they took, what they ultimately did, and so on. This may or may not tell you about the quality of their code directly, but it will tell you a lot about how they analyze, break down, and ultimately solve problems. And if they drop implementation details you can take notes and maybe do a sanity-check later.
Ask them to talk in some detail about a significant project -- architecture, design, UX considerations, testing, deployment, maintenance, etc. It almost doesn't matter what language the code is in for most of this; you're trying to answer the deeper question of "can this person write software we'll want to live with?".
Ask for a demo. Pick something interesting and ask for a walk-through of the code behind it. As the candidate is explaining what it does you should be looking for the usual code-hygeine things -- comments, clear organization, comprehensible names, and so on. If he struggles to explain it that's a source of concern. (A quick look at the code and "oh yeah, that's where I put that" is fine; I mean if he's stumped.)
Be sure to get technical references, not just managerial ones, and ask them about the candidate's technical strengths and weaknesses.
answered Jul 7 '13 at 17:22
Monica Cellio♦
43.7k17114191
I have sometimes been pulled into interviews for positions where I'm not particularly skilled, and as a specialist I've often been interviewed by people who don't know my area very well. Here are things I've seen work:
Before interviewing anybody, try to learn the "101" stuff in the relevant area. For Javascript, there are assorted resources online. Note: this isn't so you'll be able to ask good questions; you probably won't. The purpose of this is so you'll be able to spot BS.
Ask behavioral questions that get them talking about the technical issues. "What was the hardest bug you've had to solve?" is a good one; you can ask them to explain what the problem was, what approaches they took, what they ultimately did, and so on. This may or may not tell you about the quality of their code directly, but it will tell you a lot about how they analyze, break down, and ultimately solve problems. And if they drop implementation details you can take notes and maybe do a sanity-check later.
Ask them to talk in some detail about a significant project -- architecture, design, UX considerations, testing, deployment, maintenance, etc. It almost doesn't matter what language the code is in for most of this; you're trying to answer the deeper question of "can this person write software we'll want to live with?".
Ask for a demo. Pick something interesting and ask for a walk-through of the code behind it. As the candidate is explaining what it does you should be looking for the usual code-hygeine things -- comments, clear organization, comprehensible names, and so on. If he struggles to explain it that's a source of concern. (A quick look at the code and "oh yeah, that's where I put that" is fine; I mean if he's stumped.)
Be sure to get technical references, not just managerial ones, and ask them about the candidate's technical strengths and weaknesses.
answered Jul 7 '13 at 17:22
Monica Cellio♦
43.7k17114191
answered Jul 7 '13 at 17:22
Monica Cellio♦
43.7k17114191
answered Jul 7 '13 at 17:22
Monica Cellio♦
43.7k17114191
answered Jul 7 '13 at 17:22
Monica Cellio♦
43.7k17114191
43.7k17114191
3
I do pretty much the same - another one I consider almost a must is to ask them to explain something I don't know - "just cover the basics of what X technology is and when it is most useful" - if they can't do this in a short span of time and a comprehensible way, this isn't a good fit. Particularly where your team doesn't have an expert already - any "expert" you hire had better be able to explain to non-expert some simple concepts so you can interact successfully.
– bethlakshmi
Jul 8 '13 at 19:12
@bethlakshmi, that's an excellent point; whoever is hired into this position is going to need to be able to explain his design/implementation decisions in ways everyone else can understand, well enough that they can ask relevant questions and get answers.
– Monica Cellio♦
Jul 8 '13 at 19:16
yep. Worse mistake I ever made was hiring a guy who seemed to make sense to other experts, but who made no sense to me, the non-expert. Turned out, the guy was smart, but very bad at communicating - so he made complicated things that were of no use but worked perfectly within their own flawed assumptions
– bethlakshmi
Jul 8 '13 at 20:14
Now I'm still trying to remember which was the worst bug I've encountered... those caused by the infamous PHP #29992 might win, but I'm not sure.
– o0'.
Apr 2 '14 at 13:14
add a comment |Â
3
I do pretty much the same - another one I consider almost a must is to ask them to explain something I don't know - "just cover the basics of what X technology is and when it is most useful" - if they can't do this in a short span of time and a comprehensible way, this isn't a good fit. Particularly where your team doesn't have an expert already - any "expert" you hire had better be able to explain to non-expert some simple concepts so you can interact successfully.
– bethlakshmi
Jul 8 '13 at 19:12
@bethlakshmi, that's an excellent point; whoever is hired into this position is going to need to be able to explain his design/implementation decisions in ways everyone else can understand, well enough that they can ask relevant questions and get answers.
– Monica Cellio♦
Jul 8 '13 at 19:16
yep. Worse mistake I ever made was hiring a guy who seemed to make sense to other experts, but who made no sense to me, the non-expert. Turned out, the guy was smart, but very bad at communicating - so he made complicated things that were of no use but worked perfectly within their own flawed assumptions
– bethlakshmi
Jul 8 '13 at 20:14
Now I'm still trying to remember which was the worst bug I've encountered... those caused by the infamous PHP #29992 might win, but I'm not sure.
– o0'.
Apr 2 '14 at 13:14
3
3
I do pretty much the same - another one I consider almost a must is to ask them to explain something I don't know - "just cover the basics of what X technology is and when it is most useful" - if they can't do this in a short span of time and a comprehensible way, this isn't a good fit. Particularly where your team doesn't have an expert already - any "expert" you hire had better be able to explain to non-expert some simple concepts so you can interact successfully.
– bethlakshmi
Jul 8 '13 at 19:12
I do pretty much the same - another one I consider almost a must is to ask them to explain something I don't know - "just cover the basics of what X technology is and when it is most useful" - if they can't do this in a short span of time and a comprehensible way, this isn't a good fit. Particularly where your team doesn't have an expert already - any "expert" you hire had better be able to explain to non-expert some simple concepts so you can interact successfully.
– bethlakshmi
Jul 8 '13 at 19:12
@bethlakshmi, that's an excellent point; whoever is hired into this position is going to need to be able to explain his design/implementation decisions in ways everyone else can understand, well enough that they can ask relevant questions and get answers.
– Monica Cellio♦
Jul 8 '13 at 19:16
@bethlakshmi, that's an excellent point; whoever is hired into this position is going to need to be able to explain his design/implementation decisions in ways everyone else can understand, well enough that they can ask relevant questions and get answers.
– Monica Cellio♦
Jul 8 '13 at 19:16
yep. Worse mistake I ever made was hiring a guy who seemed to make sense to other experts, but who made no sense to me, the non-expert. Turned out, the guy was smart, but very bad at communicating - so he made complicated things that were of no use but worked perfectly within their own flawed assumptions
– bethlakshmi
Jul 8 '13 at 20:14
yep. Worse mistake I ever made was hiring a guy who seemed to make sense to other experts, but who made no sense to me, the non-expert. Turned out, the guy was smart, but very bad at communicating - so he made complicated things that were of no use but worked perfectly within their own flawed assumptions
– bethlakshmi
Jul 8 '13 at 20:14
Now I'm still trying to remember which was the worst bug I've encountered... those caused by the infamous PHP #29992 might win, but I'm not sure.
– o0'.
Apr 2 '14 at 13:14
Now I'm still trying to remember which was the worst bug I've encountered... those caused by the infamous PHP #29992 might win, but I'm not sure.
– o0'.
Apr 2 '14 at 13:14
add a comment |Â
up vote
3
down vote
I'd recommend you incorporate fundamentals of software development in your interviewing strategy. As a discipline, regardless of language, there are several concerns that cut across software development/engineering:
Design Patterns: A decent project will use some kind of design pattern. A decent developer should be able to identify a specific pattern and must have implemented it at some recent point in the past. I'm no javascript ninja myself but I can hazard a guess that with frameworks like Node.js, an experienced javascript developer would have a grasp of basic software design principles
Performance: No matter the language/platform, there's usually an efficient way to do stuff and a wasteful way to do something. In java, there's the
BufferedXXXfamily of classes intended for better I/O programming and any java developer with 6 months of experience will know this. Look for such fundamental performance principles in JavaScript that a seasoned developer should know. Have a look at this article for guidanceFrameworks: As a corollary to the first point, you could look up one or two javascript frameworks and skim thru the introduction (particularly what these frameworks can achieve). Now design one or two interview questions around those. The objective here is simple: either the interviewee has used these frameworks before and can demonstrate a level of comfort that surpasses your own OR, hasn't used the framework in question BUT the person should be able to provide alternatives to the frameworks and what they can achieve
Working Problem: Thoroughly research a specific problem in javascript (you can start by looking thru one of the top voted javascript questions on SO), understand the solution and present this problem to the interviewee. It could be a bare-bones,how-to-code question or a more conceptual one, regarding best practices. The bottom line is you should know the answer and why it's the answer (in the event the interviewee is wrong or provides an alternate approach)
Ultimately, what you want in a developer is flexibility and intelligence, by-products of a firm grasp of fundamentals of software development
answered Jul 8 '13 at 0:24
kolossus
4,2211440
add a comment |Â
up vote
3
down vote
I'd recommend you incorporate fundamentals of software development in your interviewing strategy. As a discipline, regardless of language, there are several concerns that cut across software development/engineering:
Design Patterns: A decent project will use some kind of design pattern. A decent developer should be able to identify a specific pattern and must have implemented it at some recent point in the past. I'm no javascript ninja myself but I can hazard a guess that with frameworks like Node.js, an experienced javascript developer would have a grasp of basic software design principles
Performance: No matter the language/platform, there's usually an efficient way to do stuff and a wasteful way to do something. In java, there's the
BufferedXXXfamily of classes intended for better I/O programming and any java developer with 6 months of experience will know this. Look for such fundamental performance principles in JavaScript that a seasoned developer should know. Have a look at this article for guidanceFrameworks: As a corollary to the first point, you could look up one or two javascript frameworks and skim thru the introduction (particularly what these frameworks can achieve). Now design one or two interview questions around those. The objective here is simple: either the interviewee has used these frameworks before and can demonstrate a level of comfort that surpasses your own OR, hasn't used the framework in question BUT the person should be able to provide alternatives to the frameworks and what they can achieve
Working Problem: Thoroughly research a specific problem in javascript (you can start by looking thru one of the top voted javascript questions on SO), understand the solution and present this problem to the interviewee. It could be a bare-bones,how-to-code question or a more conceptual one, regarding best practices. The bottom line is you should know the answer and why it's the answer (in the event the interviewee is wrong or provides an alternate approach)
Ultimately, what you want in a developer is flexibility and intelligence, by-products of a firm grasp of fundamentals of software development
answered Jul 8 '13 at 0:24
kolossus
4,2211440
add a comment |Â
up vote
3
down vote
up vote
3
down vote
I'd recommend you incorporate fundamentals of software development in your interviewing strategy. As a discipline, regardless of language, there are several concerns that cut across software development/engineering:
Design Patterns: A decent project will use some kind of design pattern. A decent developer should be able to identify a specific pattern and must have implemented it at some recent point in the past. I'm no javascript ninja myself but I can hazard a guess that with frameworks like Node.js, an experienced javascript developer would have a grasp of basic software design principles
Performance: No matter the language/platform, there's usually an efficient way to do stuff and a wasteful way to do something. In java, there's the
BufferedXXXfamily of classes intended for better I/O programming and any java developer with 6 months of experience will know this. Look for such fundamental performance principles in JavaScript that a seasoned developer should know. Have a look at this article for guidanceFrameworks: As a corollary to the first point, you could look up one or two javascript frameworks and skim thru the introduction (particularly what these frameworks can achieve). Now design one or two interview questions around those. The objective here is simple: either the interviewee has used these frameworks before and can demonstrate a level of comfort that surpasses your own OR, hasn't used the framework in question BUT the person should be able to provide alternatives to the frameworks and what they can achieve
Working Problem: Thoroughly research a specific problem in javascript (you can start by looking thru one of the top voted javascript questions on SO), understand the solution and present this problem to the interviewee. It could be a bare-bones,how-to-code question or a more conceptual one, regarding best practices. The bottom line is you should know the answer and why it's the answer (in the event the interviewee is wrong or provides an alternate approach)
Ultimately, what you want in a developer is flexibility and intelligence, by-products of a firm grasp of fundamentals of software development
answered Jul 8 '13 at 0:24
kolossus
4,2211440
I'd recommend you incorporate fundamentals of software development in your interviewing strategy. As a discipline, regardless of language, there are several concerns that cut across software development/engineering:
Design Patterns: A decent project will use some kind of design pattern. A decent developer should be able to identify a specific pattern and must have implemented it at some recent point in the past. I'm no javascript ninja myself but I can hazard a guess that with frameworks like Node.js, an experienced javascript developer would have a grasp of basic software design principles
Performance: No matter the language/platform, there's usually an efficient way to do stuff and a wasteful way to do something. In java, there's the
BufferedXXXfamily of classes intended for better I/O programming and any java developer with 6 months of experience will know this. Look for such fundamental performance principles in JavaScript that a seasoned developer should know. Have a look at this article for guidanceFrameworks: As a corollary to the first point, you could look up one or two javascript frameworks and skim thru the introduction (particularly what these frameworks can achieve). Now design one or two interview questions around those. The objective here is simple: either the interviewee has used these frameworks before and can demonstrate a level of comfort that surpasses your own OR, hasn't used the framework in question BUT the person should be able to provide alternatives to the frameworks and what they can achieve
Working Problem: Thoroughly research a specific problem in javascript (you can start by looking thru one of the top voted javascript questions on SO), understand the solution and present this problem to the interviewee. It could be a bare-bones,how-to-code question or a more conceptual one, regarding best practices. The bottom line is you should know the answer and why it's the answer (in the event the interviewee is wrong or provides an alternate approach)
Ultimately, what you want in a developer is flexibility and intelligence, by-products of a firm grasp of fundamentals of software development
answered Jul 8 '13 at 0:24
kolossus
4,2211440
edited Jul 8 '13 at 0:34
answered Jul 8 '13 at 0:24
kolossus
4,2211440
answered Jul 8 '13 at 0:24
kolossus
4,2211440
answered Jul 8 '13 at 0:24
kolossus
4,2211440
4,2211440
add a comment |Â
add a comment |Â
up vote
1
down vote
It's probably a good idea to ask them some of the 101 stuff and see how they do with it anyway - you'd expect them to answer it pretty confidently but I'm sure a few won't.
I'd also try and think of a real scenario they may work on at your company and ask them what approach they would take to solving the problem - then either research the problem yourself or maybe ask that same question on stack or another message board and see if their answer has it's merits.
Always remember to have staff on a probationary period too whereby you can get rid of them if it isn't just a good fit. Sometimes it's not about having the absolute best coder but someone that is willing to learn more and works well in a team.
answered Jul 7 '13 at 22:19
user319940
51426
I think most interviewees will be nervous and think that there is a hidden catch in the 101 questions. Then they will start thinking about it too much and falter :)
– Juha Untinen
Mar 26 '15 at 10:02
add a comment |Â
up vote
1
down vote
It's probably a good idea to ask them some of the 101 stuff and see how they do with it anyway - you'd expect them to answer it pretty confidently but I'm sure a few won't.
I'd also try and think of a real scenario they may work on at your company and ask them what approach they would take to solving the problem - then either research the problem yourself or maybe ask that same question on stack or another message board and see if their answer has it's merits.
Always remember to have staff on a probationary period too whereby you can get rid of them if it isn't just a good fit. Sometimes it's not about having the absolute best coder but someone that is willing to learn more and works well in a team.
answered Jul 7 '13 at 22:19
user319940
51426
I think most interviewees will be nervous and think that there is a hidden catch in the 101 questions. Then they will start thinking about it too much and falter :)
– Juha Untinen
Mar 26 '15 at 10:02
add a comment |Â
up vote
1
down vote
up vote
1
down vote
It's probably a good idea to ask them some of the 101 stuff and see how they do with it anyway - you'd expect them to answer it pretty confidently but I'm sure a few won't.
I'd also try and think of a real scenario they may work on at your company and ask them what approach they would take to solving the problem - then either research the problem yourself or maybe ask that same question on stack or another message board and see if their answer has it's merits.
Always remember to have staff on a probationary period too whereby you can get rid of them if it isn't just a good fit. Sometimes it's not about having the absolute best coder but someone that is willing to learn more and works well in a team.
answered Jul 7 '13 at 22:19
user319940
51426
It's probably a good idea to ask them some of the 101 stuff and see how they do with it anyway - you'd expect them to answer it pretty confidently but I'm sure a few won't.
I'd also try and think of a real scenario they may work on at your company and ask them what approach they would take to solving the problem - then either research the problem yourself or maybe ask that same question on stack or another message board and see if their answer has it's merits.
Always remember to have staff on a probationary period too whereby you can get rid of them if it isn't just a good fit. Sometimes it's not about having the absolute best coder but someone that is willing to learn more and works well in a team.
answered Jul 7 '13 at 22:19
user319940
51426
answered Jul 7 '13 at 22:19
user319940
51426
answered Jul 7 '13 at 22:19
user319940
51426
answered Jul 7 '13 at 22:19
user319940
51426
51426
I think most interviewees will be nervous and think that there is a hidden catch in the 101 questions. Then they will start thinking about it too much and falter :)
– Juha Untinen
Mar 26 '15 at 10:02
add a comment |Â
I think most interviewees will be nervous and think that there is a hidden catch in the 101 questions. Then they will start thinking about it too much and falter :)
– Juha Untinen
Mar 26 '15 at 10:02
I think most interviewees will be nervous and think that there is a hidden catch in the 101 questions. Then they will start thinking about it too much and falter :)
– Juha Untinen
Mar 26 '15 at 10:02
I think most interviewees will be nervous and think that there is a hidden catch in the 101 questions. Then they will start thinking about it too much and falter :)
– Juha Untinen
Mar 26 '15 at 10:02
add a comment |Â
up vote
1
down vote
I ask developers to code in front of me. Ideally I know the language, but I'll accept something where I don't. If I know in advance I don't know the language, I look at the relevant details/APIs in advance to know what to expect. I'll also try to ask questions about the aspects of the technology that I do know. If I don't know in advance what the language will be (an intern knows a few languages and they don't overlap mine), that's fine. I can still check for logic in watching code and look at it in more detail later if I want.
For JavaScript, you could have the candidate code on a computer in front of you. You'll see what libraries the person uses, how he/she thinks, does research, asks about requirements, etc.
As you said, you care that the candidate can do the job. So why not give them something similar to the job. Not the actual job because that would be like getting free labor. But a made up example that uses similar skills.
answered Jul 8 '13 at 2:48
Jeanne Boyarsky
4,7741934
add a comment |Â
up vote
1
down vote
I ask developers to code in front of me. Ideally I know the language, but I'll accept something where I don't. If I know in advance I don't know the language, I look at the relevant details/APIs in advance to know what to expect. I'll also try to ask questions about the aspects of the technology that I do know. If I don't know in advance what the language will be (an intern knows a few languages and they don't overlap mine), that's fine. I can still check for logic in watching code and look at it in more detail later if I want.
For JavaScript, you could have the candidate code on a computer in front of you. You'll see what libraries the person uses, how he/she thinks, does research, asks about requirements, etc.
As you said, you care that the candidate can do the job. So why not give them something similar to the job. Not the actual job because that would be like getting free labor. But a made up example that uses similar skills.
answered Jul 8 '13 at 2:48
Jeanne Boyarsky
4,7741934
add a comment |Â
up vote
1
down vote
up vote
1
down vote
I ask developers to code in front of me. Ideally I know the language, but I'll accept something where I don't. If I know in advance I don't know the language, I look at the relevant details/APIs in advance to know what to expect. I'll also try to ask questions about the aspects of the technology that I do know. If I don't know in advance what the language will be (an intern knows a few languages and they don't overlap mine), that's fine. I can still check for logic in watching code and look at it in more detail later if I want.
For JavaScript, you could have the candidate code on a computer in front of you. You'll see what libraries the person uses, how he/she thinks, does research, asks about requirements, etc.
As you said, you care that the candidate can do the job. So why not give them something similar to the job. Not the actual job because that would be like getting free labor. But a made up example that uses similar skills.
answered Jul 8 '13 at 2:48
Jeanne Boyarsky
4,7741934
I ask developers to code in front of me. Ideally I know the language, but I'll accept something where I don't. If I know in advance I don't know the language, I look at the relevant details/APIs in advance to know what to expect. I'll also try to ask questions about the aspects of the technology that I do know. If I don't know in advance what the language will be (an intern knows a few languages and they don't overlap mine), that's fine. I can still check for logic in watching code and look at it in more detail later if I want.
For JavaScript, you could have the candidate code on a computer in front of you. You'll see what libraries the person uses, how he/she thinks, does research, asks about requirements, etc.
As you said, you care that the candidate can do the job. So why not give them something similar to the job. Not the actual job because that would be like getting free labor. But a made up example that uses similar skills.
answered Jul 8 '13 at 2:48
Jeanne Boyarsky
4,7741934
answered Jul 8 '13 at 2:48
Jeanne Boyarsky
4,7741934
answered Jul 8 '13 at 2:48
Jeanne Boyarsky
4,7741934
answered Jul 8 '13 at 2:48
Jeanne Boyarsky
4,7741934
4,7741934
add a comment |Â
add a comment |Â
up vote
0
down vote
Some may think this doesn't answer your question, but I think it offers some strategies to solve the problem of hiring a qualified client-side developer. Is there a law that says you have to do this yourself?
- Work on the details for this job. Writing client-side code and UX are not the same. You may want some of both, but decide the ratio. This is the first step in getting the right person for the job. There are many devs that learn javascript, CSS & html, but couldn't design a command prompt.
- Get examples of their work.
- Hire a contractor on a part-time basis. If you make a hiring mistake, you can correct it easily by getting rid of the person for a lot less than a full-timer.
- As an option to #3, use a hiring agency. You can create a temp-to-hire situation if you want to gain a little freedom. Many people may question some of these agency's abiliy to identify technical talent. Some of better than others.
- Reach out to people in your tech. community and try to get some recommendations. Why just wait and see who applies.
As part of the interview process, focus some of the questions on the problem areas you've had. Either put them on the board to mock up some diagrams and code, but ideally get them infront of a keyboad and see what they've got. Can they write code? See what tools they use. Do they bring up browser compatibility issues? Have they seen similar problems. I was dabbling with a webfront end and met someone at a coffee shop who was able to dazzle me in less than 15 minutes. I would hire this person on the spot.
add a comment |Â
up vote
0
down vote
Some may think this doesn't answer your question, but I think it offers some strategies to solve the problem of hiring a qualified client-side developer. Is there a law that says you have to do this yourself?
- Work on the details for this job. Writing client-side code and UX are not the same. You may want some of both, but decide the ratio. This is the first step in getting the right person for the job. There are many devs that learn javascript, CSS & html, but couldn't design a command prompt.
- Get examples of their work.
- Hire a contractor on a part-time basis. If you make a hiring mistake, you can correct it easily by getting rid of the person for a lot less than a full-timer.
- As an option to #3, use a hiring agency. You can create a temp-to-hire situation if you want to gain a little freedom. Many people may question some of these agency's abiliy to identify technical talent. Some of better than others.
- Reach out to people in your tech. community and try to get some recommendations. Why just wait and see who applies.
As part of the interview process, focus some of the questions on the problem areas you've had. Either put them on the board to mock up some diagrams and code, but ideally get them infront of a keyboad and see what they've got. Can they write code? See what tools they use. Do they bring up browser compatibility issues? Have they seen similar problems. I was dabbling with a webfront end and met someone at a coffee shop who was able to dazzle me in less than 15 minutes. I would hire this person on the spot.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Some may think this doesn't answer your question, but I think it offers some strategies to solve the problem of hiring a qualified client-side developer. Is there a law that says you have to do this yourself?
- Work on the details for this job. Writing client-side code and UX are not the same. You may want some of both, but decide the ratio. This is the first step in getting the right person for the job. There are many devs that learn javascript, CSS & html, but couldn't design a command prompt.
- Get examples of their work.
- Hire a contractor on a part-time basis. If you make a hiring mistake, you can correct it easily by getting rid of the person for a lot less than a full-timer.
- As an option to #3, use a hiring agency. You can create a temp-to-hire situation if you want to gain a little freedom. Many people may question some of these agency's abiliy to identify technical talent. Some of better than others.
- Reach out to people in your tech. community and try to get some recommendations. Why just wait and see who applies.
As part of the interview process, focus some of the questions on the problem areas you've had. Either put them on the board to mock up some diagrams and code, but ideally get them infront of a keyboad and see what they've got. Can they write code? See what tools they use. Do they bring up browser compatibility issues? Have they seen similar problems. I was dabbling with a webfront end and met someone at a coffee shop who was able to dazzle me in less than 15 minutes. I would hire this person on the spot.
Some may think this doesn't answer your question, but I think it offers some strategies to solve the problem of hiring a qualified client-side developer. Is there a law that says you have to do this yourself?
- Work on the details for this job. Writing client-side code and UX are not the same. You may want some of both, but decide the ratio. This is the first step in getting the right person for the job. There are many devs that learn javascript, CSS & html, but couldn't design a command prompt.
- Get examples of their work.
- Hire a contractor on a part-time basis. If you make a hiring mistake, you can correct it easily by getting rid of the person for a lot less than a full-timer.
- As an option to #3, use a hiring agency. You can create a temp-to-hire situation if you want to gain a little freedom. Many people may question some of these agency's abiliy to identify technical talent. Some of better than others.
- Reach out to people in your tech. community and try to get some recommendations. Why just wait and see who applies.
As part of the interview process, focus some of the questions on the problem areas you've had. Either put them on the board to mock up some diagrams and code, but ideally get them infront of a keyboad and see what they've got. Can they write code? See what tools they use. Do they bring up browser compatibility issues? Have they seen similar problems. I was dabbling with a webfront end and met someone at a coffee shop who was able to dazzle me in less than 15 minutes. I would hire this person on the spot.
answered Jul 8 '13 at 14:57
user8365
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f12901%2fhow-to-conduct-an-interview-for-a-subject-im-not-really-good-at%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
