Mixing
Is getting into the minutiae of a technology/language appropriate in an interview?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
10
down vote
favorite
So I have seen both sides of this question and actually been on both sides as well. In the programming world there seems to be a fine line between great interviewing for the sake of weeding out candidates properly, and that of showing off how much the developers on the hiring side of the table know.
For example, it makes sense to ask someone to pseudo-code or even legitimately code some logic applicable to the job at hand, but I question the usefulness of the interviewer asking a theoretical question like "explain covariance and contravariance" or some other question about a languaute which only the creating product team is probably well versed in (i.e. the .NET Framework team at Microsoft).
I know the initial reaction to this question might be, "Sure, it shows how a candidate does answering a tough question they probably will not know, yada, yada, yada", or "If it is applicable, then 'Yes'..." However, more and more it appears that these types of questions are about the interviewing team showing the candidate how much they know. (I have been on that side of the table when my collegues have done this, and my initial thought was about how irrelevant the question was.)
How can these types of detailed technological questions be useful in an interviewing situation?
professionalism interviewing software-industry
edited Sep 14 '13 at 12:51
Rhys
5,73623558
asked May 15 '12 at 14:56
atconway
2,03621630
add a comment |Â
up vote
10
down vote
favorite
So I have seen both sides of this question and actually been on both sides as well. In the programming world there seems to be a fine line between great interviewing for the sake of weeding out candidates properly, and that of showing off how much the developers on the hiring side of the table know.
For example, it makes sense to ask someone to pseudo-code or even legitimately code some logic applicable to the job at hand, but I question the usefulness of the interviewer asking a theoretical question like "explain covariance and contravariance" or some other question about a languaute which only the creating product team is probably well versed in (i.e. the .NET Framework team at Microsoft).
I know the initial reaction to this question might be, "Sure, it shows how a candidate does answering a tough question they probably will not know, yada, yada, yada", or "If it is applicable, then 'Yes'..." However, more and more it appears that these types of questions are about the interviewing team showing the candidate how much they know. (I have been on that side of the table when my collegues have done this, and my initial thought was about how irrelevant the question was.)
How can these types of detailed technological questions be useful in an interviewing situation?
professionalism interviewing software-industry
edited Sep 14 '13 at 12:51
Rhys
5,73623558
asked May 15 '12 at 14:56
atconway
2,03621630
I edited this to tighten up the question, but kept the software-industry implications. However, the question about the usefulness of minutiae in an interview is just as applicable when hiring for other positions (for example, some ultra-specific management principle, or color theory, etc).
– jcmeloni
May 15 '12 at 16:11
add a comment |Â
up vote
10
down vote
favorite
up vote
10
down vote
favorite
So I have seen both sides of this question and actually been on both sides as well. In the programming world there seems to be a fine line between great interviewing for the sake of weeding out candidates properly, and that of showing off how much the developers on the hiring side of the table know.
For example, it makes sense to ask someone to pseudo-code or even legitimately code some logic applicable to the job at hand, but I question the usefulness of the interviewer asking a theoretical question like "explain covariance and contravariance" or some other question about a languaute which only the creating product team is probably well versed in (i.e. the .NET Framework team at Microsoft).
I know the initial reaction to this question might be, "Sure, it shows how a candidate does answering a tough question they probably will not know, yada, yada, yada", or "If it is applicable, then 'Yes'..." However, more and more it appears that these types of questions are about the interviewing team showing the candidate how much they know. (I have been on that side of the table when my collegues have done this, and my initial thought was about how irrelevant the question was.)
How can these types of detailed technological questions be useful in an interviewing situation?
professionalism interviewing software-industry
edited Sep 14 '13 at 12:51
Rhys
5,73623558
asked May 15 '12 at 14:56
atconway
2,03621630
So I have seen both sides of this question and actually been on both sides as well. In the programming world there seems to be a fine line between great interviewing for the sake of weeding out candidates properly, and that of showing off how much the developers on the hiring side of the table know.
For example, it makes sense to ask someone to pseudo-code or even legitimately code some logic applicable to the job at hand, but I question the usefulness of the interviewer asking a theoretical question like "explain covariance and contravariance" or some other question about a languaute which only the creating product team is probably well versed in (i.e. the .NET Framework team at Microsoft).
I know the initial reaction to this question might be, "Sure, it shows how a candidate does answering a tough question they probably will not know, yada, yada, yada", or "If it is applicable, then 'Yes'..." However, more and more it appears that these types of questions are about the interviewing team showing the candidate how much they know. (I have been on that side of the table when my collegues have done this, and my initial thought was about how irrelevant the question was.)
How can these types of detailed technological questions be useful in an interviewing situation?
professionalism interviewing software-industry
edited Sep 14 '13 at 12:51
Rhys
5,73623558
asked May 15 '12 at 14:56
atconway
2,03621630
edited Sep 14 '13 at 12:51
Rhys
5,73623558
edited Sep 14 '13 at 12:51
Rhys
5,73623558
edited Sep 14 '13 at 12:51
Rhys
5,73623558
5,73623558
asked May 15 '12 at 14:56
atconway
2,03621630
asked May 15 '12 at 14:56
atconway
2,03621630
asked May 15 '12 at 14:56
atconway
2,03621630
2,03621630
I edited this to tighten up the question, but kept the software-industry implications. However, the question about the usefulness of minutiae in an interview is just as applicable when hiring for other positions (for example, some ultra-specific management principle, or color theory, etc).
– jcmeloni
May 15 '12 at 16:11
add a comment |Â
I edited this to tighten up the question, but kept the software-industry implications. However, the question about the usefulness of minutiae in an interview is just as applicable when hiring for other positions (for example, some ultra-specific management principle, or color theory, etc).
– jcmeloni
May 15 '12 at 16:11
I edited this to tighten up the question, but kept the software-industry implications. However, the question about the usefulness of minutiae in an interview is just as applicable when hiring for other positions (for example, some ultra-specific management principle, or color theory, etc).
– jcmeloni
May 15 '12 at 16:11
I edited this to tighten up the question, but kept the software-industry implications. However, the question about the usefulness of minutiae in an interview is just as applicable when hiring for other positions (for example, some ultra-specific management principle, or color theory, etc).
– jcmeloni
May 15 '12 at 16:11
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
8
down vote
accepted
It's not necessarily about ego.
I tend to try to dig and find one thing the other person doesn't know, just to see if they try to bluff or if they honestly just say "no, I've not come across that before ... what is it?" (that last bit for bonus points). I don't go hard at it though and I never humiliate a candidate. I don't even want them humbled for the rest of the interview. I just want to know how they react to something they don't know.
However, I have seen a couple of developers interviewing who were clearly just showing off. Those cases were obvious because they were asking questions off a list and then bleating the answer loudly when the candidate got it wrong.
Interesting thing though: neither of them were particularly good developers. I wonder if they were overcompensating. Or perhaps dragging out the trivia portions, where the answers were right in front of them, to avoid getting caught out on more fluid technical conversation (which is where I like to take an interview).
answered May 15 '12 at 15:10
pdr
19.2k46081
4
When a candidate doesn't know something and admits it, I explain it to him and then later ask something about it to see what he learned from that exchange. If he grokked the explanation and then applies that knowledge, that's golden. (I don't go hunting for these moments, but that's how I handle them if it happens.)
– Monica Cellio♦
May 15 '12 at 15:19
add a comment |Â
up vote
7
down vote
While I'm sure there are developers out there that want to show off in an interview, in the vast majority of cases where I've seen people ask "impossible" questions in an interview, the intent hasn't been malicious. Instead, the problem has been that people in general, and developers in particular, are very bad at knowing in advance how easy a question is likely to be and how likely a competent developer is going to be able to provide a credible answer. Generally, it takes quite a few candidates coming through the door that seem competent but are totally stumped by a particular question for the interviewer to realize that the problem is the question, not the candidates.
When developers spend quite a bit of time in a very particular niche, interacting with other folks that are also concentrating on that particular niche, it becomes very easy to forget the sorts of things that one takes for granted in those conversations that would be challenging for a competent developer in a different niche. When I interviewed with a communications company, for example, one of the engineers had an entire series of questions dealing with Huffman coding. There was one problem on one assignment in one class in my undergraduate career where Huffman coding happened to come up in passing and I hadn't spent any time contemplating the algorithm or why it was structured a particular way so I was way outside my depth trying to answer those questions. To the interviewer, though, who spent a great deal of time dealing with compression algorithms in general, Huffman coding seemed like such a basic thing that any competent undergraduate ought to have internalized it in order to begin to deal with the sorts of problems he was dealing with. I doubt that he was intentionally trying to make himself look smart in front of a bunch of new graduates, it just didn't occur to him that signal compression algorithms aren't a niche that most developers have a lot of experience with unless they happen to be working for major communications companies. I would wager that once a couple dozen folks completely bombed his portion of the interview while doing reasonably well elsewhere, he realized the problem and adjusted his questions.
answered May 15 '12 at 15:47
Justin Cave
34.9k9112136
4
In a typical environment, the developer high enough to be brought in to do an interview is probably about the busiest person in the building. And interviewing is < 5% of his job. So there are any number of non-malicious reasons they might not be good at it. Hopefully, they will learn from experience of taking 6 months to find someone who happen to study Huffman coding, hiring him, and watching him burn out because he wasn't as generally sharp as the 10 candidates they passed on who drew a blank.
– JohnMcG
May 15 '12 at 15:53
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
accepted
It's not necessarily about ego.
I tend to try to dig and find one thing the other person doesn't know, just to see if they try to bluff or if they honestly just say "no, I've not come across that before ... what is it?" (that last bit for bonus points). I don't go hard at it though and I never humiliate a candidate. I don't even want them humbled for the rest of the interview. I just want to know how they react to something they don't know.
However, I have seen a couple of developers interviewing who were clearly just showing off. Those cases were obvious because they were asking questions off a list and then bleating the answer loudly when the candidate got it wrong.
Interesting thing though: neither of them were particularly good developers. I wonder if they were overcompensating. Or perhaps dragging out the trivia portions, where the answers were right in front of them, to avoid getting caught out on more fluid technical conversation (which is where I like to take an interview).
answered May 15 '12 at 15:10
pdr
19.2k46081
4
When a candidate doesn't know something and admits it, I explain it to him and then later ask something about it to see what he learned from that exchange. If he grokked the explanation and then applies that knowledge, that's golden. (I don't go hunting for these moments, but that's how I handle them if it happens.)
– Monica Cellio♦
May 15 '12 at 15:19
add a comment |Â
up vote
8
down vote
accepted
It's not necessarily about ego.
I tend to try to dig and find one thing the other person doesn't know, just to see if they try to bluff or if they honestly just say "no, I've not come across that before ... what is it?" (that last bit for bonus points). I don't go hard at it though and I never humiliate a candidate. I don't even want them humbled for the rest of the interview. I just want to know how they react to something they don't know.
However, I have seen a couple of developers interviewing who were clearly just showing off. Those cases were obvious because they were asking questions off a list and then bleating the answer loudly when the candidate got it wrong.
Interesting thing though: neither of them were particularly good developers. I wonder if they were overcompensating. Or perhaps dragging out the trivia portions, where the answers were right in front of them, to avoid getting caught out on more fluid technical conversation (which is where I like to take an interview).
answered May 15 '12 at 15:10
pdr
19.2k46081
4
When a candidate doesn't know something and admits it, I explain it to him and then later ask something about it to see what he learned from that exchange. If he grokked the explanation and then applies that knowledge, that's golden. (I don't go hunting for these moments, but that's how I handle them if it happens.)
– Monica Cellio♦
May 15 '12 at 15:19
add a comment |Â
up vote
8
down vote
accepted
up vote
8
down vote
accepted
It's not necessarily about ego.
I tend to try to dig and find one thing the other person doesn't know, just to see if they try to bluff or if they honestly just say "no, I've not come across that before ... what is it?" (that last bit for bonus points). I don't go hard at it though and I never humiliate a candidate. I don't even want them humbled for the rest of the interview. I just want to know how they react to something they don't know.
However, I have seen a couple of developers interviewing who were clearly just showing off. Those cases were obvious because they were asking questions off a list and then bleating the answer loudly when the candidate got it wrong.
Interesting thing though: neither of them were particularly good developers. I wonder if they were overcompensating. Or perhaps dragging out the trivia portions, where the answers were right in front of them, to avoid getting caught out on more fluid technical conversation (which is where I like to take an interview).
answered May 15 '12 at 15:10
pdr
19.2k46081
It's not necessarily about ego.
I tend to try to dig and find one thing the other person doesn't know, just to see if they try to bluff or if they honestly just say "no, I've not come across that before ... what is it?" (that last bit for bonus points). I don't go hard at it though and I never humiliate a candidate. I don't even want them humbled for the rest of the interview. I just want to know how they react to something they don't know.
However, I have seen a couple of developers interviewing who were clearly just showing off. Those cases were obvious because they were asking questions off a list and then bleating the answer loudly when the candidate got it wrong.
Interesting thing though: neither of them were particularly good developers. I wonder if they were overcompensating. Or perhaps dragging out the trivia portions, where the answers were right in front of them, to avoid getting caught out on more fluid technical conversation (which is where I like to take an interview).
answered May 15 '12 at 15:10
pdr
19.2k46081
answered May 15 '12 at 15:10
pdr
19.2k46081
answered May 15 '12 at 15:10
pdr
19.2k46081
answered May 15 '12 at 15:10
pdr
19.2k46081
19.2k46081
4
When a candidate doesn't know something and admits it, I explain it to him and then later ask something about it to see what he learned from that exchange. If he grokked the explanation and then applies that knowledge, that's golden. (I don't go hunting for these moments, but that's how I handle them if it happens.)
– Monica Cellio♦
May 15 '12 at 15:19
add a comment |Â
4
When a candidate doesn't know something and admits it, I explain it to him and then later ask something about it to see what he learned from that exchange. If he grokked the explanation and then applies that knowledge, that's golden. (I don't go hunting for these moments, but that's how I handle them if it happens.)
– Monica Cellio♦
May 15 '12 at 15:19
4
4
When a candidate doesn't know something and admits it, I explain it to him and then later ask something about it to see what he learned from that exchange. If he grokked the explanation and then applies that knowledge, that's golden. (I don't go hunting for these moments, but that's how I handle them if it happens.)
– Monica Cellio♦
May 15 '12 at 15:19
When a candidate doesn't know something and admits it, I explain it to him and then later ask something about it to see what he learned from that exchange. If he grokked the explanation and then applies that knowledge, that's golden. (I don't go hunting for these moments, but that's how I handle them if it happens.)
– Monica Cellio♦
May 15 '12 at 15:19
add a comment |Â
up vote
7
down vote
While I'm sure there are developers out there that want to show off in an interview, in the vast majority of cases where I've seen people ask "impossible" questions in an interview, the intent hasn't been malicious. Instead, the problem has been that people in general, and developers in particular, are very bad at knowing in advance how easy a question is likely to be and how likely a competent developer is going to be able to provide a credible answer. Generally, it takes quite a few candidates coming through the door that seem competent but are totally stumped by a particular question for the interviewer to realize that the problem is the question, not the candidates.
When developers spend quite a bit of time in a very particular niche, interacting with other folks that are also concentrating on that particular niche, it becomes very easy to forget the sorts of things that one takes for granted in those conversations that would be challenging for a competent developer in a different niche. When I interviewed with a communications company, for example, one of the engineers had an entire series of questions dealing with Huffman coding. There was one problem on one assignment in one class in my undergraduate career where Huffman coding happened to come up in passing and I hadn't spent any time contemplating the algorithm or why it was structured a particular way so I was way outside my depth trying to answer those questions. To the interviewer, though, who spent a great deal of time dealing with compression algorithms in general, Huffman coding seemed like such a basic thing that any competent undergraduate ought to have internalized it in order to begin to deal with the sorts of problems he was dealing with. I doubt that he was intentionally trying to make himself look smart in front of a bunch of new graduates, it just didn't occur to him that signal compression algorithms aren't a niche that most developers have a lot of experience with unless they happen to be working for major communications companies. I would wager that once a couple dozen folks completely bombed his portion of the interview while doing reasonably well elsewhere, he realized the problem and adjusted his questions.
answered May 15 '12 at 15:47
Justin Cave
34.9k9112136
4
In a typical environment, the developer high enough to be brought in to do an interview is probably about the busiest person in the building. And interviewing is < 5% of his job. So there are any number of non-malicious reasons they might not be good at it. Hopefully, they will learn from experience of taking 6 months to find someone who happen to study Huffman coding, hiring him, and watching him burn out because he wasn't as generally sharp as the 10 candidates they passed on who drew a blank.
– JohnMcG
May 15 '12 at 15:53
add a comment |Â
up vote
7
down vote
While I'm sure there are developers out there that want to show off in an interview, in the vast majority of cases where I've seen people ask "impossible" questions in an interview, the intent hasn't been malicious. Instead, the problem has been that people in general, and developers in particular, are very bad at knowing in advance how easy a question is likely to be and how likely a competent developer is going to be able to provide a credible answer. Generally, it takes quite a few candidates coming through the door that seem competent but are totally stumped by a particular question for the interviewer to realize that the problem is the question, not the candidates.
When developers spend quite a bit of time in a very particular niche, interacting with other folks that are also concentrating on that particular niche, it becomes very easy to forget the sorts of things that one takes for granted in those conversations that would be challenging for a competent developer in a different niche. When I interviewed with a communications company, for example, one of the engineers had an entire series of questions dealing with Huffman coding. There was one problem on one assignment in one class in my undergraduate career where Huffman coding happened to come up in passing and I hadn't spent any time contemplating the algorithm or why it was structured a particular way so I was way outside my depth trying to answer those questions. To the interviewer, though, who spent a great deal of time dealing with compression algorithms in general, Huffman coding seemed like such a basic thing that any competent undergraduate ought to have internalized it in order to begin to deal with the sorts of problems he was dealing with. I doubt that he was intentionally trying to make himself look smart in front of a bunch of new graduates, it just didn't occur to him that signal compression algorithms aren't a niche that most developers have a lot of experience with unless they happen to be working for major communications companies. I would wager that once a couple dozen folks completely bombed his portion of the interview while doing reasonably well elsewhere, he realized the problem and adjusted his questions.
answered May 15 '12 at 15:47
Justin Cave
34.9k9112136
4
In a typical environment, the developer high enough to be brought in to do an interview is probably about the busiest person in the building. And interviewing is < 5% of his job. So there are any number of non-malicious reasons they might not be good at it. Hopefully, they will learn from experience of taking 6 months to find someone who happen to study Huffman coding, hiring him, and watching him burn out because he wasn't as generally sharp as the 10 candidates they passed on who drew a blank.
– JohnMcG
May 15 '12 at 15:53
add a comment |Â
up vote
7
down vote
up vote
7
down vote
While I'm sure there are developers out there that want to show off in an interview, in the vast majority of cases where I've seen people ask "impossible" questions in an interview, the intent hasn't been malicious. Instead, the problem has been that people in general, and developers in particular, are very bad at knowing in advance how easy a question is likely to be and how likely a competent developer is going to be able to provide a credible answer. Generally, it takes quite a few candidates coming through the door that seem competent but are totally stumped by a particular question for the interviewer to realize that the problem is the question, not the candidates.
When developers spend quite a bit of time in a very particular niche, interacting with other folks that are also concentrating on that particular niche, it becomes very easy to forget the sorts of things that one takes for granted in those conversations that would be challenging for a competent developer in a different niche. When I interviewed with a communications company, for example, one of the engineers had an entire series of questions dealing with Huffman coding. There was one problem on one assignment in one class in my undergraduate career where Huffman coding happened to come up in passing and I hadn't spent any time contemplating the algorithm or why it was structured a particular way so I was way outside my depth trying to answer those questions. To the interviewer, though, who spent a great deal of time dealing with compression algorithms in general, Huffman coding seemed like such a basic thing that any competent undergraduate ought to have internalized it in order to begin to deal with the sorts of problems he was dealing with. I doubt that he was intentionally trying to make himself look smart in front of a bunch of new graduates, it just didn't occur to him that signal compression algorithms aren't a niche that most developers have a lot of experience with unless they happen to be working for major communications companies. I would wager that once a couple dozen folks completely bombed his portion of the interview while doing reasonably well elsewhere, he realized the problem and adjusted his questions.
answered May 15 '12 at 15:47
Justin Cave
34.9k9112136
While I'm sure there are developers out there that want to show off in an interview, in the vast majority of cases where I've seen people ask "impossible" questions in an interview, the intent hasn't been malicious. Instead, the problem has been that people in general, and developers in particular, are very bad at knowing in advance how easy a question is likely to be and how likely a competent developer is going to be able to provide a credible answer. Generally, it takes quite a few candidates coming through the door that seem competent but are totally stumped by a particular question for the interviewer to realize that the problem is the question, not the candidates.
When developers spend quite a bit of time in a very particular niche, interacting with other folks that are also concentrating on that particular niche, it becomes very easy to forget the sorts of things that one takes for granted in those conversations that would be challenging for a competent developer in a different niche. When I interviewed with a communications company, for example, one of the engineers had an entire series of questions dealing with Huffman coding. There was one problem on one assignment in one class in my undergraduate career where Huffman coding happened to come up in passing and I hadn't spent any time contemplating the algorithm or why it was structured a particular way so I was way outside my depth trying to answer those questions. To the interviewer, though, who spent a great deal of time dealing with compression algorithms in general, Huffman coding seemed like such a basic thing that any competent undergraduate ought to have internalized it in order to begin to deal with the sorts of problems he was dealing with. I doubt that he was intentionally trying to make himself look smart in front of a bunch of new graduates, it just didn't occur to him that signal compression algorithms aren't a niche that most developers have a lot of experience with unless they happen to be working for major communications companies. I would wager that once a couple dozen folks completely bombed his portion of the interview while doing reasonably well elsewhere, he realized the problem and adjusted his questions.
answered May 15 '12 at 15:47
Justin Cave
34.9k9112136
answered May 15 '12 at 15:47
Justin Cave
34.9k9112136
answered May 15 '12 at 15:47
Justin Cave
34.9k9112136
answered May 15 '12 at 15:47
Justin Cave
34.9k9112136
34.9k9112136
4
In a typical environment, the developer high enough to be brought in to do an interview is probably about the busiest person in the building. And interviewing is < 5% of his job. So there are any number of non-malicious reasons they might not be good at it. Hopefully, they will learn from experience of taking 6 months to find someone who happen to study Huffman coding, hiring him, and watching him burn out because he wasn't as generally sharp as the 10 candidates they passed on who drew a blank.
– JohnMcG
May 15 '12 at 15:53
add a comment |Â
4
In a typical environment, the developer high enough to be brought in to do an interview is probably about the busiest person in the building. And interviewing is < 5% of his job. So there are any number of non-malicious reasons they might not be good at it. Hopefully, they will learn from experience of taking 6 months to find someone who happen to study Huffman coding, hiring him, and watching him burn out because he wasn't as generally sharp as the 10 candidates they passed on who drew a blank.
– JohnMcG
May 15 '12 at 15:53
4
4
In a typical environment, the developer high enough to be brought in to do an interview is probably about the busiest person in the building. And interviewing is < 5% of his job. So there are any number of non-malicious reasons they might not be good at it. Hopefully, they will learn from experience of taking 6 months to find someone who happen to study Huffman coding, hiring him, and watching him burn out because he wasn't as generally sharp as the 10 candidates they passed on who drew a blank.
– JohnMcG
May 15 '12 at 15:53
In a typical environment, the developer high enough to be brought in to do an interview is probably about the busiest person in the building. And interviewing is < 5% of his job. So there are any number of non-malicious reasons they might not be good at it. Hopefully, they will learn from experience of taking 6 months to find someone who happen to study Huffman coding, hiring him, and watching him burn out because he wasn't as generally sharp as the 10 candidates they passed on who drew a blank.
– JohnMcG
May 15 '12 at 15:53
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%2f1320%2fis-getting-into-the-minutiae-of-a-technology-language-appropriate-in-an-intervie%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
I edited this to tighten up the question, but kept the software-industry implications. However, the question about the usefulness of minutiae in an interview is just as applicable when hiring for other positions (for example, some ultra-specific management principle, or color theory, etc).
– jcmeloni
May 15 '12 at 16:11