Thanks for your response. This position is for a windows-focused developer. However, one candidate that did have some UNIX experience also couldn't answer the questions...they also stumbled on a basic question about awk which they had on their resume. Some of the windows folks are great, while others just see security as an afterthought it seems. I want someone who at least has a basic understanding of what I thought were simple concepts such as PKI.
Thank you for your thoughtful reply. I'm torn between a young up-and-comer vs. a tried and true "expert." We have hired a few younger folks that have demonstrated a willingness to learn...in fact the last developer we hired had never developed in our core language but interviewed so well (and had exposure to numerous languages) that we hired them. What I'm looking for is someone that has been in the trenches and done a lot of different things. Not some prima-dona that is focuses on the architecture and refuses to get their hands dirty, or who, in the face of adversity says to me "I don't know and that's not my job....that's a 'security' issue."
We don't sponser H1-b's for a number of reasons. The candidates I've been interviewing for this position are native citizens, although some of our developers are green card holders.
Thank you for the insight and recommendations. I re-read my original post, and it came off much harsher than intended. I suppose it was the result of long hours and frustration over not having enough people to do the work. Our interviews are rather loosely-structured, we try to ask a number of open-ended questions to give the candidates an opportunity to describe their experience, as well as a few specifics on syntax.
It is a difficult task to say the least, especially with senior-level developers. You have candidates that just want to do design work and don't really want to code (even though they tell you differently), and then you have candidates that have been so deep in specific areas of code that they never look up to see the world around them and have no idea how the entire system works.
So this particular question was maybe not the best, but I really wanted to see if the candidate had an understanding of how encryption works. In the next interview with a different candidate I worded the question differently, and they perfectly described PKI in about two sentences. I also want to know of my candidates if they understand various ways to make things secure, so we have questions like "can you describe some ways that a web service can be secured." If they can't at least list one way to secure a web service, how can I trust them to protect my customer's data?
I certainly am not trying to "stump" the candidate. I just want to know, in general terms, are they smart, and if they do not know specifics are they going to be willing to learn what they need to in order to perform their duties. It is difficult to do.
And quite a few of them migrated into positions in charge of hiring others.
ha, now that's pretty funny - I'm technically in charge of hiring but I still write a little code, and I involve the entire development team in the interview process. General consensus from this crowd is the question was not good for interviews, and I agree to a point. Most of our questions are more general, and the point of the question was to see what their level of *understanding* of encryption was. The gist of it is that I want to see what they have worked on and how they went about solving various problem. We also have a broad range of questions to find out what the candidate is like from a personality standpoint as that can be more important than their specific technical expertise.
Thank you for your insight. When I talk to candidates I feel like I need to sell them on the company, our story, team, work environment, etc., as much as they need to sell themselves to us. The question I mentioned in the OP was probably not the best. We offer up a lot more general questions such as "describe two ways that you can secure a web service." IF they understand security they can usually offer up a discussion on that. But you'd be surprised how many can't answer something that simple. We don't ask people to write code on the wall...it is time consuming and not terribly useful IMO. My last hire had zero experience with our core language but we hired him anyway - he was smart and eager to learn and has worked out great.
I disagree that knowing the basics of how encryption works isn't important for software developers. This question was not a deal-breaker for a new hire, and I certainly am not looking to stump candidates. In fact, I'd love for every candidate to get every question correct. And I don't think I'm smarter than others - I actually want to hire people that are much, much smarter than I am! Perhaps a better question might be "Can you explain what encryption is and how it works on a conceptual level?" Would that be "fair"?
Bear in mind that was just one question of many that we asked. We do offer up a lot of general questions such as "describe some ways that web services can be secured". We get good answers from some candidates, while others answer with responses like "it's handled in the configuration" and they obviously have no real understanding of how it all works. In general our questions are wide ranging from general programming concepts down to some specific, often-used syntax in our core languages.
OP here. We try to attract good talent and pay them well for it. I have developers that have been here for 14 years and make well above what they could probably get elsewhere. Their experience and deep knowledge of our systems and business processes is invaluable. We haven't had a developer leave in almost a decade - the new hire is a result of growth.
All that being said, my intention for my post was not to come off as arrogant as it seems it may have. We're very fair in our hiring and screening. The last developer I hired had basically no real-world development experience, but he exhibited a great willingness to learn and is an extremely bright guy. In fact he hadn't written a line of code in our core language but I hired him anyway and he has worked out great.
I guess what I am seeing is you have a few classes of developers. On one hand you have folks that have been at it awhile and it's just a paycheck to them - they don't go out of their way to understand the big picture and I feel like that really limits them. So one reason for the interview question is to not necessarily preclude them from getting the job, but rather to gain an understanding of how well they know various systems and how they work. To me the question could have opened up a discussion on how to safely transmit data - something that I feel a senior developer should know about.
On the other hand you have developers that want to know as much as they can about the various systems they work on, how they're architected, what the infrastructure in production looks like, etc. THESE are the developers I want - people that have a broader understanding of what they're working on and don't have tunnel vision on their specific tasks.
And believe me, I'm sure that if I had been on the other side of the table the candidate could have found plenty of holes in my skillset - I certainly don't know everything nor do I pretend to.
Perhaps the question as worded was a bit too specific. And I do give points for being able to talk through various solutions to a given problem, provided the solutions make sense - I've been in this business long enough to know there is more than one valid approach to solving any given problem. To me the concept of public/private key encryption is important to at least have a basic understanding of for developers working on securing applications - the specific implementation is irrelevant, bu the concept is important. I certainly wouldn't disqualify an applicant based on this question alone.
Wrong - we don't do sponsorship of H-1Bs. We pay top dollar for really good candidates and this wasn't the only answer in the interview that the candidate had trouble with. To me a senior developer should at least know some basic concepts of encryption (not necessarily specific implementations)...I certainly wouldn't disqualify a good candidate based on this alone, however.
I agree with this in general. The last developer I hired hadn't ever written any code in our core language, but he demonstrated in the interview an eagerness to learn and had developed in other languages. He is a really smart guy so we hired him.
Sometimes you need some folks though that have a lot experience in doing what you're trying to do with new initiatives...obviously they need to be able to learn as well, but the experience is critical for some positions.
Slashdot Mirror
Thanks for your response. This position is for a windows-focused developer. However, one candidate that did have some UNIX experience also couldn't answer the questions...they also stumbled on a basic question about awk which they had on their resume. Some of the windows folks are great, while others just see security as an afterthought it seems. I want someone who at least has a basic understanding of what I thought were simple concepts such as PKI.
Thank you for your thoughtful reply. I'm torn between a young up-and-comer vs. a tried and true "expert." We have hired a few younger folks that have demonstrated a willingness to learn...in fact the last developer we hired had never developed in our core language but interviewed so well (and had exposure to numerous languages) that we hired them. What I'm looking for is someone that has been in the trenches and done a lot of different things. Not some prima-dona that is focuses on the architecture and refuses to get their hands dirty, or who, in the face of adversity says to me "I don't know and that's not my job....that's a 'security' issue."
We don't sponser H1-b's for a number of reasons. The candidates I've been interviewing for this position are native citizens, although some of our developers are green card holders.
No, we are actually compensate our technical staff quite well.
Thank you for the insight and recommendations. I re-read my original post, and it came off much harsher than intended. I suppose it was the result of long hours and frustration over not having enough people to do the work. Our interviews are rather loosely-structured, we try to ask a number of open-ended questions to give the candidates an opportunity to describe their experience, as well as a few specifics on syntax. It is a difficult task to say the least, especially with senior-level developers. You have candidates that just want to do design work and don't really want to code (even though they tell you differently), and then you have candidates that have been so deep in specific areas of code that they never look up to see the world around them and have no idea how the entire system works. So this particular question was maybe not the best, but I really wanted to see if the candidate had an understanding of how encryption works. In the next interview with a different candidate I worded the question differently, and they perfectly described PKI in about two sentences. I also want to know of my candidates if they understand various ways to make things secure, so we have questions like "can you describe some ways that a web service can be secured." If they can't at least list one way to secure a web service, how can I trust them to protect my customer's data? I certainly am not trying to "stump" the candidate. I just want to know, in general terms, are they smart, and if they do not know specifics are they going to be willing to learn what they need to in order to perform their duties. It is difficult to do.
And quite a few of them migrated into positions in charge of hiring others.
ha, now that's pretty funny - I'm technically in charge of hiring but I still write a little code, and I involve the entire development team in the interview process. General consensus from this crowd is the question was not good for interviews, and I agree to a point. Most of our questions are more general, and the point of the question was to see what their level of *understanding* of encryption was. The gist of it is that I want to see what they have worked on and how they went about solving various problem. We also have a broad range of questions to find out what the candidate is like from a personality standpoint as that can be more important than their specific technical expertise.
Thank you for your insight. When I talk to candidates I feel like I need to sell them on the company, our story, team, work environment, etc., as much as they need to sell themselves to us. The question I mentioned in the OP was probably not the best. We offer up a lot more general questions such as "describe two ways that you can secure a web service." IF they understand security they can usually offer up a discussion on that. But you'd be surprised how many can't answer something that simple. We don't ask people to write code on the wall...it is time consuming and not terribly useful IMO. My last hire had zero experience with our core language but we hired him anyway - he was smart and eager to learn and has worked out great.
I disagree that knowing the basics of how encryption works isn't important for software developers. This question was not a deal-breaker for a new hire, and I certainly am not looking to stump candidates. In fact, I'd love for every candidate to get every question correct. And I don't think I'm smarter than others - I actually want to hire people that are much, much smarter than I am! Perhaps a better question might be "Can you explain what encryption is and how it works on a conceptual level?" Would that be "fair"?
Bear in mind that was just one question of many that we asked. We do offer up a lot of general questions such as "describe some ways that web services can be secured". We get good answers from some candidates, while others answer with responses like "it's handled in the configuration" and they obviously have no real understanding of how it all works. In general our questions are wide ranging from general programming concepts down to some specific, often-used syntax in our core languages.
OP here. We try to attract good talent and pay them well for it. I have developers that have been here for 14 years and make well above what they could probably get elsewhere. Their experience and deep knowledge of our systems and business processes is invaluable. We haven't had a developer leave in almost a decade - the new hire is a result of growth. All that being said, my intention for my post was not to come off as arrogant as it seems it may have. We're very fair in our hiring and screening. The last developer I hired had basically no real-world development experience, but he exhibited a great willingness to learn and is an extremely bright guy. In fact he hadn't written a line of code in our core language but I hired him anyway and he has worked out great. I guess what I am seeing is you have a few classes of developers. On one hand you have folks that have been at it awhile and it's just a paycheck to them - they don't go out of their way to understand the big picture and I feel like that really limits them. So one reason for the interview question is to not necessarily preclude them from getting the job, but rather to gain an understanding of how well they know various systems and how they work. To me the question could have opened up a discussion on how to safely transmit data - something that I feel a senior developer should know about. On the other hand you have developers that want to know as much as they can about the various systems they work on, how they're architected, what the infrastructure in production looks like, etc. THESE are the developers I want - people that have a broader understanding of what they're working on and don't have tunnel vision on their specific tasks. And believe me, I'm sure that if I had been on the other side of the table the candidate could have found plenty of holes in my skillset - I certainly don't know everything nor do I pretend to.
Perhaps the question as worded was a bit too specific. And I do give points for being able to talk through various solutions to a given problem, provided the solutions make sense - I've been in this business long enough to know there is more than one valid approach to solving any given problem. To me the concept of public/private key encryption is important to at least have a basic understanding of for developers working on securing applications - the specific implementation is irrelevant, bu the concept is important. I certainly wouldn't disqualify an applicant based on this question alone.
Wrong - we don't do sponsorship of H-1Bs. We pay top dollar for really good candidates and this wasn't the only answer in the interview that the candidate had trouble with. To me a senior developer should at least know some basic concepts of encryption (not necessarily specific implementations)...I certainly wouldn't disqualify a good candidate based on this alone, however.
I agree with this in general. The last developer I hired hadn't ever written any code in our core language, but he demonstrated in the interview an eagerness to learn and had developed in other languages. He is a really smart guy so we hired him. Sometimes you need some folks though that have a lot experience in doing what you're trying to do with new initiatives...obviously they need to be able to learn as well, but the experience is critical for some positions.