Re: Questions when interviewing new people

On Thu, Apr 15, 2004 at 02:30:30PM -0300, Mads Rasmussen wrote:
> Eric Murray wrote:
> 
> > I've been using a similar question for the last 5 or 6 years.
> > 
> > I treat it as two parts-- a general security design part where the
> > candidate tells me about the threats to the system, and a specific design
> > part where they tell me specifically how they'd solve it (alice sends
> > bob xyz encrypted in algorithm pdq, etc).
> 
> Could you mail me (or the list) some examples of the things you ask?

There's a reason I didn't post it originally.  If lots of people know
it, it will lose its effectiveness and I'll have to come up with another.
The security world is only so big.
 
> You assume that the candidate knows a little cryptography, but the idea 
> is good.

Most of my direct hires have been for positions that require some 
crypto knowledge.

> I would change the questions in relation to what profile I was looking for.
> 
> My problem is that I can easily find software arquitects but it is VERY 
> hard to find software architects or programmers that know just a little 
> bit of security, not to talk about cryptography, most of the people I 
> have interviewed doesn't know the difference between symmetric and 
> asymmetic cryptography. So its my job to train them if they prove to be 
> skilled enough to start working :o)

I interview for other positions as well, ones that do not require
knowledge of crypto but where some awareness of security would be a
bonus.  I sometimes use the same security question for
those as well, and just don't have them go as far in depth on the
implementation part.  It depends what they have on their resume.

I agree that crypto can be taught.  I taught most of my current company.
But I haven't yet figured out how to teach the "security mindset".  You
either design & code like a paranoid, or you don't. So I
look more for that in my interviewing.

> I would like them to tune in on the right track at the job interview to 
> better evaluate their skills.

The best interview questions are ones that are not that difficult to
solve, but where people who are advanced in knowledge and experience
will see a better or more detailed solution than the obvious one.
Or corner cases that a careful programmer knows he/she needs to take care of.
 
> I like your approach where the candidate has to do a threat analysis and 
> then a specific solution to a problem. I just don't know if I would be 
> able to find people who could pass the second test.

Its not a test so much as exploring how much they know.
 
> I would ask them to do a code review or something after the threat 
> analysis.

That's a good suggestion.
Don't use real code though.  One time I showed up to an interview
and the interviewer sat me down at his terminal and popped up a shell
cd'ed into a directory full of source, with the tail of a failed make, and
said "fix it".  It took me only a short time because I'd fixed the
same problem in the same package six months earlier.  Yes, I told him.

Eric