Ask Slashdot: What Portion of Developers Are Bad At What They Do?

ramoneThePoolGuy writes: We are looking to fill a senior developer/architect position in our firm. I am disappointed with the applicants thus far, and quite frankly it has me worried about the quality of developers/engineers available to us. For instance, today I asked an engineer with 20+ years of experience to describe to me the basic process of public/private key encryption. This engineer had no clue. I asked another applicant a similar question: "Suppose you wanted to send me a file with very sensitive information, how would you encrypt it in such a way that I would decrypt it?" The person started off by asking me if it was an excel file, a PDF, etc. In general, I'm finding that an overwhelming number of developers I've interviewed have poor understanding of key concepts, especially when it comes to securing data. Are other firms experiencing this same dilemma in finding qualified applicants? (Quite frankly it scares me that some of these developers are building sites that need to be secure)"

Comments

It's a vast field....

[jawtheshark]

It's a vast field, and expertise of people is usually just a subset. I'm not even sure what the answer you you expected was, but I'd say: I'd use your public key to encrypt the file to you and then send it to you. Personally, I wouldn't know which commands to invoke to do this, but I know that's the theory.

So, should any developer know this? That is debatable. I've had very competent developers who had next to no clue about how DNS works. They could do their job just fine with that. Me? Personally, I'm not up to snuff with the finer points of SQL queries and all the joins that exists and when it makes sense to create an index, etc. Could I find out? Most likely, but I haven't had the need to recently.

The problem is, that you are mapping your knowlegde to "what people must know". I used to do that too, and I probably still do often enough. The DNS example above didn't come from nowhere: I had the case, and I was really thinking "how could such a competent person not know this", but then this person could probably enlighten me about dozens of things I don't know well enough.

It all comes down to what you define as "general knowgledge" for a developer should be and that is highly subjective.

TL;DR Hiring people is hard. Especially, technical people.

Re:It's a vast field....

[jawtheshark]

There are also a plethora of "technically correct" answers. You could say: "I scp the file to your server", where you presume the server is secure, and ssh is secure, so the documents confidentiality is guaranteed. (Upload the file using https works as an answer too). Hey, just connect to the companies VPN and copy the file to a Samba share. Valid too!
The question of what kind of file it was, isn't even that dumb. I'm not familiar with PDF, but I could -for example- imagine there is a standard for encryption within PDF. Someone from with a document management background would most likely think of such solutions.

Re:It's a vast field....

[pugugly]

No, you (Alice) encrypt with your private key, then encrypt with 'Bobs' public key, then Bob decrypts with his private key and again with Alice's public key.

Thus Both Alice and Bob are authenticated, and no one besides Alice and Bob can intercept.

Pug

Re:It's a vast field....

[hawguy]

if the guy is in your building, then just walk the files over on a thumb drive. that way it never goes through the network at all. or, just print it out and give it to him? seems like a number of options are more secure than email.

Printing is probably the worst option for confidential data unless you have a private printer or it supports secure printing. The HR director at a former company had to get his own printer after he printed salary information several times before he realizing that the printer was out of paper. After he went to lunch someone replaced the paper and the salary docs ended up spread out on the printer table for everyone to view. Oops. He could have used the secure-print option, but apparently didn't know about it.

Plus there's the fact that the print server is likely not very secure so the document could be intercepted there, many office copier/printers these days have on-board storage and might hold a copy of the document for who knows how long, and, printers are rarely patched in most offices and are often riddled with vulnerabilities. Plus, cloud-print from mobile devices goes through unknown servers so you may as well just email it in plain text than cloud print it.

Re:Yes...

[Grax]

I keep hearing how hard it is to find good people but then the recruiters tell me that the potential employer can't meet my price point and that is the end of the discussion.

Avoid Q&A style interviews

[HappyDrgn]

I've had a lot more success hiring great people when I stopped interviewing in a Q&A format and instead spend the time learning how the candidate solves problems. I typically spend 5-10 minutes asking some specific questions about technologies on their resume. Then I define a fictitious project and spend the remaining time ( typically an hour ) learning about how they might solve it, dive deep into a few areas, do some white boarding, a little bit of impromptu code examples and discuss the potential long term problems and solutions. You get a better feel for the breadth of someone's knowledge and their ability to think soundly on their feet. It lets you know that they have the knowledge and ability to apply it to a problem.

PDF encryption

[oneiros27]

I asked another applicant a similar question: "Suppose you wanted to send me a file with very sensitive information, how would you encrypt it in such a way that I would decrypt it?" The person started off by asking me if it was an excel file, a PDF, etc.

You should've answered the person, because then they might've told you that there's an encyption standard for PDF. I use it with my tax-preparer, so that we don't need to deal with other programs that would decrypt the file (and then potentially leave an unencrypted copy lying about).

Excel offers password protection to restrict modifications, it wouldn't surprise me if they offered encryption, too.

So in this case, it might not be that the person sucks at his job ... it might be that you are, because you had a pre-conceived notion of what the answer should be, rather than finding out how that person would handle the problem. It's entirely possible that they could come up with a better solution than yours.

And as for the the question of what proportion are bad ... you have to remember that you're hiring people. The people who really know what they're doing are likely either going to be paid well, or have an established network that they can tap when they need a job. (Rather than answer some random job posting where they don't know if it'll be worse than their past job, and/or have to jump through hoops answering poorly thought up interview questions).

If you mention to your current developers that you're hiring, and they can't manage to find people to refer, that's possibly a sign that none of them would be willing to subject their friends to come work for you. And if that's the case, you might have problems when one of their friends' companies are hiring.

Re:Excel file

[DickBreath]

Your question demonstrates that you don't understand the problem. How do I securely send you a file? If I use Excel's encryption, then we have a new problem: how do I send you the password to open it?

Furthermore, it is a legitimate question to consider whether you should trust Excel's security. (And I'm not picking on Microsoft. At least not this time.) You don't have access to Excel's source code. You can't know it is secure. You could sleep a lot better if you simply assume the Excel is just like any file, and like any other file, you encrypt it and sign it with PKI so that the person on the other end can decrypt it and verify it is from you. (Actually encrypt and sign a small key to a more efficient symmetric algorithm.)

Asking the wrong questions, using the wrong metric

[merick]

I'm a web developer and I also haven an interest in understand public-private key crypto, PGP, steganography, physical security etc. The thing is, You don't need *any* of that to build good, secure websites. You should be asking about things from the OWASP Top 10 List if you want to gauge their ability to write secure code.

https://www.owasp.org/index.ph...

Otherwise you're judging them for not having the same "other" unrelated-to-your-job security interests as you.

They should understand that they aren't trained enough to build their own authentication encryption systems correctly. They should use generally accepted procedures like BCrypting passwords with a unique per-user SALT that also uses a site-specific key. And that other sensitive fields should be blocked from being recorded in logs, data should be encrypted at rest, etc. But if they have poor OWASP skills, the sensitive data is still readable because it is accessed through the application which is decrypting it for an attacker.

You're asking the wrong things and judging on unrelated skills.

Web Developer/Public-Private Key?

[Jason Levine]

I'm not sure if this was a web developer position you were interviewing for, but your statement of "these developers are building sites that need to be secure" makes me think it is. Let me speak as a web developer who's been at this for over twenty years.

I've never once in my position needed to know public/private key encryption to secure files for my job. If you asked me right now how to do this, I'd have no clue. If my manager were to walk over to me now and tell me to do this, I'd need some time to familiarize myself with the process. This would mean using Google to find articles on the subject. Possibly with an addition of purchasing books on the topic or going for training, but mostly Google. I pride myself on my Google-Fu. It can be an invaluable skill to a developer.

How do I secure my websites without knowledge of public/private key encryption then? I know how to set up SSL certificates and send traffic via HTTPS. (Yes, this is a form of public/private key encryption, but I don't know the intricacies of it. I just know how to set it up.) I also know to sanitize my inputs so a user entering "LastName=Jones' 1=1; Delete From Users" in the URL won't delete all of our records. I know not to take user input and just spit it out on my webpage. I know to look for the edge cases where security could fail and protect against them. When I'm building websites/apps, I think "how would I break this if I were malicious" and then I protect against these attacks. Is my security 100% effective? I'm sure not. Nobody's is, but I take pride in securing my sites as much as I possibly can.

All without being able to recite Public/Private Key Encryption details on command. Unless the job directly requires this knowledge, I'd inquire as to why this was such a deal-breaking question and why you've come to the conclusion that so many developers are bad at what they do because they can't immediately recite the details of every technology you toss their way.