Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I recently saw a comment here, that the signs of a bad hire is when he says "I worked with this and that", but then doesn't elaborate when asked.

And the question is why?

Hypothetical scenario: Say you work for company X that develops rockets for space trips, then you walk to an interview for position Z in company Y. Interviewer sees your CV, asks a question - What technologies have you used? You respond, oh, I have used boost library to control the rocket navigation systems. Employer decides that you are a bad hire and doesn't offer you a job. Next he walks home, cross references your previous company X, finds documented bug in boost library and brings the rocket down. BOOM!

From one point of view, you didn't said anything of interest, from another point of view, libraries, patterns, and algorithms can come a very long way towards letting malicious people reverse the heck out of the competitors product. Do you have right to talk about previous products, even in abstract way. And does the interviewer has rights to ask you anything about things you've coded for some commercial entity at all?

share|improve this question
1  
Reminds me of an interview I had. I would wind up working on "the product" for "the customer". They did bend secrecy enough to mention that "the product" had hardware and software components. Didn't get the job, but the first thing to do would have been to apply for Top Secret clearance. –  David Thornley Jun 7 '11 at 14:10

5 Answers 5

up vote 14 down vote accepted

An interviewer doesn't necessarily know the nature of the work that you have done. All of my work has been in the defense and intelligence industries, where most of what I've touched has been some combination of proprietary and covered by an non-disclosure agreement, ITAR controlled, or restricted or classified in some way. Because of this, I can't get into specifics - I don't have any code, can't show them code, and can't get into any details that I have. However, I'm very comfortable talking about the tools, technologies, and types of problems that I've solved, outlining how they were presented to me and what I did to reach a solution.

Mentioning specific tools and technologies is a very good thing. This helps your potential employer know about what kinds of experiences you've had. Maybe they use some of the same tools and platforms, and would like to hire someone with your experience in using them. Neglecting your experiences and knowledge is simply shooting yourself in the foot in an interview.

You can't not answer questions about things that you have done, as your potential future employer needs to have some way to evaluate your ability to work and solve problems based on your past experiences. However, you do need to be aware of material that is in some way sensitive and not violate any agreements that you have made.

A specific example from my past: I worked on software used to test an airborne ISR sensor system. During the course of my work, I typically used Java, Eclipse, ClearCase, ClearQuest, Apache XMLBeans, SOAP, and how I interfaced with a CORBA package. I don't get into specifics of what the SOAP messages were, with the IDL files looked like, what the format of the XML I was parsing is, or any algorithms that I saw or created. But I do talk about my workflow and processes with Eclipse, ClearCase, and ClearQuest, the fact that I had to learn about XMLBeans, SOAP, and CORBA since I had no prior experience, and so on. I also talked about my team experiences during that time frame, and my interactions with other engineers working on the same project.

Also, as a side note, the scenario that you describe is extremely unlikely. Any software used in a mission critical system should be well-vetted by tests to ensure that something like that can happen. If simply knowing what tools and technologies exist in a system gives an attacker the ability to compromise the system something is a little wrong there.

share|improve this answer
5  
repeated for emphasis "If simply knowing what tools and technologies exist in a system gives an attacker the ability to compromise the system something is a little wrong there." Except I would modify that to a LOT wrong. –  jhocking Jun 7 '11 at 14:15
    
As a side note, some of the very strict defense systems will require that the project/program not be associated with the technology. The solution for engineers I've seen is that no one talks about the program they worked on. Everyone does talk about what technology they have experience with. –  bethlakshmi Jun 7 '11 at 19:33

You shouldn't disclose anything that can affect the company's position in the competition space. Like problems in their products, their weaknesses, their plans for the future products etc. Limit your details to the amount of information found in public but no more.

At one interview they asked me to describe the UI of the company's products, if I had any screenshots. I've offered to google together looking for screenshots in public press releases. So we did and luckily we spotted an image somewhere on the web. Then I commented on the technological background according to that picture and in the limits of the information this picture was disclosing. Everyone was satisfied.

Believe me, nobody at a genuine interview (not set up by competitors) would be interested in the details of the company's portfolio. At best they would check if you were to disclose too much. But short of that, they're more interested in the technologies you personally used, the roles you played, they problems you faced and how you reacted to them, how you approached solving them, internal conflicts when you were a part of them, how you did with them etc. That's all they want, that is to learn your personality.

share|improve this answer

If you are in a technical interview, you can assume that the person you are talking with speaks tech. ("What if they can't" is a different question entirely).

Given this, I go by the rule: Talk as much about your work experience as you can without talking about your previous company.

It's a thin line at times, but you what you want to do is show (prove) that you did what you said you did. Sometimes people put stuff on their resume/CV that rather embellishes what they actually did.

Case in point, I interviewed someone yesterday that put on their resume that they preformed requirements gathering and application design. Turns out they shadowed someone who did all that. Oddly enough, they didn't mention the word 'Shadowed' on their resume....

So, going to your example:

Interviewer sees your CV, asks a question - What technologies have you used? You respond, oh, I have used boost library to control the rocket navigation systems.

That is a good lead-in. But if you don't embellish, the interviewer may think that you didn't actually do too much. Perhaps you only worked on a few minor bugs, perhaps you shadowed someone, perhaps you read that line off of Wikipedia? If you aren't willing to talk code, then it's considered a negative for you.

Perhaps something along the lines of:

Oh, I've used boost library to control the rocket navigation systems. My primary role was to write the module that recalculates the trajectory biased on various factors. I got to know the API for this particular library very well as I used it on a daily basis. One really interesting ticket I work on involved actually interfacing with this hardware.

See the difference? Go into detail. Prove you know what you've put on your resume.

Hope that helps. :)

share|improve this answer

As for the specific scenerio with the flight controler I would either say it was a proprietary or commercial software package rather than identify the specific controller. If they are looking for experience in a specific controller you can mention you have worked with it on a project and not be specific about which. Generally mentioning some of the methods exposed and how they are used. This can serve to prove you know about the system while not really providing any information that can be leveraged against your current employer. Any interviewer that probes for competitive information is probably not interested in actually offering you a job anyway. After all would you want someone who works for you that is going to tell all of your companies secrets to get a new job?

share|improve this answer

This question applies in this forum, but, there is a recruting forum, also, that applies.

Is your interviewer a Human Resources / Psychology person, or a Technical I.T. person ?

I have been in several interviews, where the H.R. recruiter discards or accepts people for technical decisions, like the one you mention.

Others, a self called I.T. person rejects candidates for non valid technical reasons like: "You worked with projects in both VB.NET and Java, I work with VB.NET and think that Java sucks, and since you have worked with Java, you sucks, therefore you are discarded."

And applies to previous experience. I have been in interviews where the recruiter wanted to know some info from the company that I consider confidential, such as sales ammounts.

These is the one who is more related to this forum. The general rule is that you may mention a global generic stuff like: I work in a E.R.P. application, or I work with a mobile application, or doing web apps. "I use C#, PHP, C++".

share|improve this answer
    
No offence, but many C++ shops will refuse people with Java experience. They tend to Javatize the C++ code, and usually, only mess comes out of it. If you're applying for C++, and you have C++ line of thinking, don't mention Java. I fully agree with those people. Stick with one direction, either Java and others, or C++ and others. –  Coder Apr 24 '12 at 8:36
    
@Coder I understand. I know there is also a culture in each programming language. I work with some PHP, but, program as I was on C#, and people when they see PHP, think: "Bad spaghetti code developer" –  umlcat Apr 25 '12 at 4:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.