Slashdot Mirror
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)"
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.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Because PKI is more of a specialization, not a fundamental.
I am very small, utmostly microscopic.
Having been interviewing people recently, it's almost impossible to find people who are half decent. Slashdot likes to make out like there's a huge glut of good engineers without jobs in the US. If it's true, then I haven't found them. What there is is a huge number of people who don't understand how anything at all works.
Are you going through a staffing agency? Expecting them to find you a "senior" developer who will work for 50k a year? Do you only look for resumes with decades of experience, which usually amounts to sitting in an office chair jacking off?
Why would you expect every developer to be an expert in cryptography?
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.
Yeah, and? Not everyone is going to know the ins-and-outs of every single field of software.
I am disappointed with the applicants thus far, and quite frankly it has me worried about the quality of developers/engineers available to us.
Unless you claim that you know everything about everything, I'm sure I could find areas that you had no clue about as in these engineers you refer to in the previous sentence. Does that make you a bad developer?
There is far more that can be known than a single person can know, so you should never, ever assume that a developer is skilled (or even knowledgeable) in a particular specialty based only on the number of years experience they have. I think you're doing a disservice in your process for finding qualified applicants: if you want them to know about PKI, for example, then you need to specify that in the job listing.
You don't need to hire experts right off the bat. What you want to hire is someone who recognizes that they don't know the answer, and tells you that, and then immediately says they'd go research it to find out. "Can I Google that?" is a perfectly valid answer sometimes. If you hire a person who knows how to learn whatever it is you need them to become an expert in, you'll have a new employee who is not only going to be a valuable asset for where you're hiring them, but also has the flexibility to expand to other areas when necessary.
TL;DR: Stop looking for purple unicorns, and start looking for fast learners.
Occasionally living proof of the Ballmer peak.
"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?"
I'd use a cross-cut shredder, then send it to you in a paper bag along with some Scotch tape. (You didn't specify how easy it needs to be to decrypt, especially if I include some random shredded pages in the mix.)
Works for most types of files: Excel, PDF, etc...
It must have been something you assimilated. . . .
This is a common problem... interviewers asking questions that have no relevance to any of my work experience or interests.
We all should know basic maths, but should developers be expected to know PKI? 10 or even 5 years ago, no. But today, Google and the like are pushing for the entire Interwebs to be secured; primarily with PKI and X.509 types certificates. Pay a bit more, expect a but more. As demand grows, the 'general knowledge' will too.
I'm a recent CS grad, but I've had a number of years of IT experience as well, and explicit security education/training hasn't come up in either case. OOP? Troubleshooting? Database design? Parallel programming? On it. Computer Security 101? Not so much.
.
Prisencolinensinainciusol. Ol Rait!
And about half are above average.
Wow... Posted from mobile. Thumbs are poor typing instruments.
Broad experience is great and I wholly support companies which are looking to add resources who possess such knowledge; however, broad experience can come with the price of not having enough targeted knowledge to bring deep-dive specifics to the mix.
The real question you should be asking is whether they can figure it out on their own if tasked with finding a solution to the problem. I guarantee you that most of those you have cast aside due to their lack of public-key cryptography knowledge would be able to do so while bringing you the specific knowledge you need straight out of their heads.
Honestly, if you interviewed me and I didn't know the answer to some mostly irrelevant question and told me that's why I didn't get the job, I would thank you for not hiring me to work with someone who doesn't know enough about being a hiring manager to do his job effectively.
This is a problem I see in the entire STEM field. You work on technology X for a while, you learn it inside and out, and you expect everyone else who is "qualified" knows what you know. You want to hire someone with no ramp, who is going to drop in on day 1 and start doing great stuff, just as soon as he sets a password to his laptop.
In practice the fields are so huge, that it's fairly unlikely anyone has the domain knowledge you've acquired in your niche, unless you hire direct from a competitor (in which case you better pay well, or be offering something huge). A more reasonable approach is to weed people out based on their general skillset (i.e. what they should have learned in school), based on resume lies, and general attitude and disposition: excessive use of the passive voice, reluctance to commit to anything, points in their discussion where they failed to pursue issues to the next level, excessive number of employers, etc. Then expect it's 6 months before they start producing something that doesn't require you to hit them for. If you're afraid they will leave in 6 months, you're not paying enough or else you hired an incompetent and he's doing you a favor.
There is a huge pool of EMPLOYED engineers. Even when they switch jobs they don't generally go through the typical application process circus. The problem is that the people who have been unemployed for months are the most likely to get an interview strictly because of motivation and availability.
It IS very hard to find good people, because they all already have jobs and aren't willing to switch to come work for you.
One good way is to chase shop layoffs (the kind where they close the whole shop, not just trim a few people), and headhunt there. Laid off people tend to be much better than fired people or people who can't get hired by anyone.
Are you a hot magnet company? (well known pre-IPO) Are you paying above market value?
My guess is that the best devs have already been scooped up, and the ones interviewing are comfortable enough where they are
I would like to echo what the above poster said. The field of security is soooo large, to find someone that knows everything off the top of their head is asking quite alot. Granted there are those out there that can give you the exact rundown of how everything from PKI to Cryptokey works...
But, they're rare and you're going to have to search for a long time to find them and then once you do you'll probably need to pay a premium for them. On top of that you'll need to make sure you give them enough of a challenge every day so they can maintain that level of knowledge. As we all know, if you don't use it, you forget it. I happen to work in the field you're describing and I know I've forgotten enough to fill the Grand Canyon a couple times over.
That being said, encrypting an email is pretty general information, any architect in IS should probably know that.
You learn it on your own time at your own expense. Duh. You aren't one of those "freeloaders" that expect their employer to invest any of their time or money in the growth and career development of their employees do you?
I agree with all of the above. No one person is going to be an expert on everything programming/IT. Case in point, I spent the first 18 years of my career as a developer...in many languages. I recently made a career shift and became a Network Administrator for a company. I made it clear to them that while I had exposure to that side of things, I was by no means a Net Admin. I didn't know shite about Exchange administration when I started 6 months ago. I know WAY more now, but only enough to know that I still don't know shite about it. In my interview, I was asked a very interesting question by my potential boss...I thought it was a good one, and applies across technological and for that matter, any fields. He asked, "How's your Google-Fu?" At first I didn't know what he meant, so I asked, and he explained that he was asking about my Google usage abilities. I responded that I basically look everything up (generally using Google.) I asked, "Why should I figure it out and make mistakes along the way when no doubt someone else has figured it out already?" He hired me the next day, and gave me a large raise just this week. The questions I would be asking are not about what potential employees already know about a specific subject, but more about how quickly they can learn. There are of course exceptions to every rule...I would not hire a Neural Surgeon unless they had extensive training in the field :)
The correct answer is 42.
We have had to get away from getting into looking for too specific skill-sets and instead look for overall qualities, such as how they learn over the course over an interview loop, as well as team fit, if we can find someone that shows up, demonstrates the ability to learn, and gets along well with others, if they demonstrate some level of intelligence then they should be able to pickup the specific skills in a short amount of time, that's what those 20+ years of experience should have taught those people. Don't get me wrong we do dig into the technical understanding but it's usually around design patterns, and overall good coding qualities.
I did have to interview quite a few people in a year, when we were re-building our team.
We interviewed about 40 people before getting 2 of them who actually knew the stuff they advertised on their CVs.
One extreme case, was a candidate who put on his CV that he wrote a compiler for C++.
I expected him to know quite a bit about the language itself, but the discussion did not get past the point where I asked about the number of operations needed to find an element in a sorted array of length N.
As for the people that were already working in the place, one could spot who was trying to maximize the pain for the ones left behind, in case he was let go.
A relevant example is a developer who made sure that his code made calls to a library for which he was the only one with a valid license. Had he been let go, the whole system would stop working.
I am not an expert on cryptography. But I know which algorithms I would use. I know how PKI works. I understand how to use PKI either to encrypt, or to authenticate. I understand what a certificate and certificate chain are. I understand the basic principles.
I would not write home grown code. I would definitely select mature, well tested libraries. But I understand what to use and how to use it.
I've been working since the days of the Apple II. It seems pretty basic to understand the basics of cryptography. Asking whether the document is PDF or Excel demonstrates a lack of understanding. The document type is irrelevant. It is a file of bytes. You want to send those bytes securely. (And you may want the receiver to be able to verify that it actually came from you.)
I'll see your senator, and I'll raise you two judges.
I'm teaching a 200-level required course required for all CS and Mathematics majors right now... and they have to use mods to decrypt a 20ish character string a la RSA. Perhaps you're combing through a group without a fairly good formal education. Most any decent CS program will have taught their students the basics of public-private key encryption.
Genuine answer is "most of them", but only because virtually everyone is terrible at software development. Note that even terrible developers will get there eventually and if you're developing simple software they may still be your best bet. You only need excellent software developers (which implies strong analytical and creative skills) if you're working on something interesting. If you're grinding out simple business logic you are probably better off with mediocre developers because they won't get bored. A scalpel is sharper than a bread knife, but it's not very useful for slicing bread.
In my career, out of the ~50 I've worked directly with, I've worked with maybe three developers that I'd class as excellent. A few that were "good" for various definitions of that word. The rest were marginal at best, but they still got things done after a fashion.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
Title asks "Ask Slashdot: What Portion of Developers Are Bad At What They Do?"
Title actually means "Ask Slashdot: What Portion of Developers Are Bad At What I Do?"
If a functional understanding of a fairly specialized technological area is what you have in mind, don't assume it's widespread.
That's like getting bent out of shape if the local mechanic (fully trained and certified, even) doesn't know the detailed intricacies of ECM programming.
If you want a broadly expert Renaissance Engineer, I hope you're prepared to pay more than the usual one-trick-monkey pay. You're not talking about an engineer, there. Something more like Chief Engineer or Chief Scientist.
Welcome to the Panopticon. Used to be a prison, now it's your home.
"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?"
Sounds like something you should be dictating to them not asking them for thier opinion. Unless the developer has actually needed to use use things like PGP etc, he probably has never thought of it.
I think a better question is, We will be transmitting confidential/sensitive information, which means you will use PGP(whatever) are you ok with that? etc.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
I keep running into folks who are locked into a very reactive mindset and require explicit direction because management refuses to let them work / think independently. Sometimes it just ends up being easier to be told what to do than it is to stick your neck out on the line to try and do something innovative. It goes back to the silo mantra. Stay out of my (Network / Security / Database / Workstation) Sandbox!
Unless you have a genuine interest outside your actual scope of work you can be very proficient in a narrow way like how to write SQL or write a GUI app or a back-end web service without having a clue about much of anything else. These are the people who just want to collect a paycheck and go home, nothing wrong with that really until they need to find new employment and it turns out it's pretty hard to find another position where the glove fits.
All that really matters is if you're capable of the job you're hired for, if you can be a great Oracle DBA that's better than 95%+ of the other applicants. If you know anything outside that scope it's just bonus. There are a few multi-talents around that know next to everything, but they're rare and usually doing something important or what nobody else can. Just be aware of where their knowledge end and use them well at what they're good at and have someone else review their code for what they're not.
Live today, because you never know what tomorrow brings
Let's define "bad" as below average at the job. One might then reasonably assume that the distribution of programming skill might approximate a normal distribution. So pretty much half. Just think what the average dev is like, then consider that half of them are even worse than that :)
It's not you: I'm just this horrifically socially awkward with everybody.
Plus no one does software development purely off of what they have memorized. Everyone has reference manuals, web sites, stackoverflow, etc. easily accesible while working. Now, if you don't even know the basics that is one thing, but there is no way any software developer knows everything about everything.
You should put in the sarcasm tag because many here will believe you are serious and agree with you.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
I'll be frank and post anon to avoid harming my image.
I was smart enough to see that College was a huge waste of time. I dropped out of high school senior year to go move and live on my own. Wasn't about to sign up for a whole new school just to finish part of a year so I never even got a high school diploma.
However I self taught myself programming before I turned 10 years old and have been coding on a unix machine of some sorts with C/C++ for nearly 18 years now. I'm only 27.
I go to the conferences and attend every single event that I can find because I have *passion* for programming and technology. Through meeting people at conferences I was given a rather high paying developer job despite my lack of credentials. (I earn over $100K in a place where rent for a decent sized house and garage is less than $1000/month).
I decided to move awhile back and I can't seem to find anyone in a Red state that will even give me the time of day. I have 8 years of professional senior-architect level experience and tax documents proving I earned the big bucks with no degree. I had to go back to a Blue state where suddenly I got called back for interviews immediately and was visiting 2-3 in person interviews a week. 2 weeks later I was employed again.
Turns out your HR drones are likely keeping guys like me from even getting a second look. Stop taking the guys who can't see a shortcut and wasted a lot of time and money on college. Those people are the fools. I skipped doing all their hard work, skipped their debt, yet I have better skills due to my passion and I absolutely embarrass them when you get us side-by-side. I grew up coding and literally was an expert before the other guy even tried getting into college.
I now work in a Venture Capital capacity with lots of big clients who almost wouldn't believe me if I told them I had no credentials. They think I'm an MBA because I act geeky and seem to know something about almost every computer science topic.
So my advice to you is stop filtering. I only work for places that will give me the time of day when I hand in a resume with not one educational resource. That proves to me that what I can do is what matters, not how rich my parents were or what I *did*.
So focus on what people can do. Not what they did. Seriously. You'll find some crazy smart guys who this whole time weren't even being called back.
I beg to differ! Plenty of developers are exceedingly competent at finding code on the intarwebs and pasting it in to the project.
I'll see your senator, and I'll raise you two judges.
Really? You should at least know the basics of public key encryption if you want to work in computers. It's as much a cornerstone of modern information tech as the OSI stack or the filesystem.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
That's a reasonable question. Without knowing the level of security required, the encryption facilities that are standard for these file types could be sufficient. The applicant wanted requirements, which is a smart thing to ask.
And why the fuck should everyone know the details of PKI? You didn't say it was a security position. Hell, a little knowledge of encryption can be worse than no knowledge, because then they might try to roll their own.
Something tells me the submitter is inflating his/her own expertise.
Nah, it's much more fun to catch those people and then mock them for being morons.
Problem is there is too much to know for any one person to learn it all. I've never been asked to encrypt a file in my life (programmer for 15 years), because no single company that I have worked for has cared that much about securing files being sent out. (the ones that did, just sent password protected zip files). Typically the things that need to be secure are behind firewalls, or the encryption is handled for you by other systems you are using.
Now, how do you find a good developer? Those are hard to define intangibles.
Being a quick study is one. I don't know how to do that today, but give me a day and I'll tell you all about it. I have enough of the background to learn the detail quickly and retain them. So, if the developer in question doesn't know the particular information you consider critical, ask them where they will go to figure it out.
Now, I have litmus tests as well, typically they involve a developer's knowledge of the languages (e.g. C#, Java, SQL, JavaScript, etc), because no developer is going to be writing encryption code all the time, where they are going to be writing in languages all the time.
Writing good code. That is really hard, but basically they can write code that they can easily understand and modify over time with minimal errors. That is the heart of the craft.
Bad User. No biscuit!
If you are only looking at developers who have worked with encryption, ask them to describe recent relevant projects. If you are getting in developers who don't have encryption on their resume, and expect them to answer what is essentially a pop quiz on a specialization - prepare for more disappointment. Also prepare to miss out on potentially brilliant problem solvers who won't be able to answer questions like that off the cuff, but who could probably *implement* a custom encryption solution for you if directed. If they DO have encryption on their resume, see how they talk about it. Perhaps using encryption in the day to day doesn't NEED to involve thinking about how it works, and so most developers don't waste time on it.
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.
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.
Build it, and they will come^Hplain.
He didn't even say anything about "build an app which sends a file using PKI". He just said "how would I send a file?" All the applicant had to do was answer "well I'd give you my public key and then use PGP to encrypt the email." Is the general concepts of public key infrastructure not basic required reading these days? It's no more unreasonable than asking "I want to send a stream of bytes to another computer on the internet, how would I do that?" and expecting an answer describing TCP sockets.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
That is to say, did you call for applications from *deeply* experienced people that know esoteric systems X, Y, and Z and that have previously worked with New Hot Language Q and Languages Of The Week I and J?
Or did you ask for unusual gurus that understand and have a *broad* range of experience with a wide variety of fundamental computing concepts and theory and can apply them correctly while rapidly getting up to speed on new environments and/or languages?
Because you're complaining about not getting the second group, while most of the job listings posted in industry are the first group.
There is often little overlap between the two, and HR departments and managers seem to default to looking for the first even when they actually need the second.
At a more prosaic level, if you specifically need someone that is going to understand general purpose encryption tools, you can also put that in the description.
A lot of the frustration with "not being able to get talent" in tech comes down to not asking for (or being willing to hire based on) what is actually needed. Instead, everyone is in CYA mode and making job listings and hires that are buzzword-rich and, thus, easily quantifiable ("he hit the right series of checkboxes, it's not my fault that he sucks, I did my part...")
STOP . AMERICA . NOW
It depends on what you mean by 'know how it works'. If they are using it in the project, then I expect them to 'know how it works'. I don't expect them to be able to write their own from scratch. Just a basic understanding. Not an explanation that you sprinkle magic encryption sauce on the data.
Generate a pair of keys. Make one public. Ask the guy at the other end to do the same. Now we can read each other's public keys (and so can anyone else). I encrypt the PDF with your public key and then with my private key. The guy at the other end can verify that it came from me, and he is the only one who can decrypt it. I don't need to know all the detailed math. I don't have to write my own BigInteger code. Just a basic understanding.
Why is this more to ask than that someone knows the language that a shop uses. Knows how to use the framework we use. Etc?
I'll see your senator, and I'll raise you two judges.
This is actually also prevalent in academia. You get profs. who write Ph.D. qualifying exam questions that narrowly focuses on whatever sub-area they specialize in and just expect that everyone should be fluent in it, but in fact most of the other profs in the department couldn't answer them correctly.
In debates about Christianity, there are two groups: those looking for answers, and those looking to just ask questions.
Sortof, I find that the situation is:
You work on technology X for a while, you learn it inside and out, and you expect everyone else who is "qualified" knows what you know. but they moved on from that technology a couple of years ago and now only want to develop in Java/Erlang/Ruby/Node/Scala (* delete as applicable as depending on which year this decade you were hiring).
even more mature technologies like .NET are stuffed full of so much churn that no-one really has time to become a master of any of it. Like my mate who was brought into a ASP.NET shop, he learned their tech stack, then one day noticed the trunk had changed a lot, so went to ask the architects who said "oh yes, we decided to move forward with our DB tech, so we're using a repository pattern now". So he goes and learns all about that, does some work on a branch, then goes to merge and... its all changed again. So goes to see the architects who say "ooh no, we decided repository pattern wasn't good enough so we've changed to using entity framework". Now that shop was just stupid, but to a lesser extent this is what is happening all over the industry.
For example, this guy is getting burnt by it.
Whilst I agree that change is necessary to keep things progressing, we're almost in a throwaway culture in ITT where everything we ever did is not good enough and has to be replaced. While there are forces pushing against this (for example, all the people who want to do the big rewrite now know its a bad idea) we still have change via refactoring and flavour-of-the-month tech patterns and frameworks pushed at us.
Only when the industry gets the idea that stable is a good thing and making products is what we should be focussed on doing (ie not changing tech all the time) will this industry be as good career as the other engineering professions.
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.)
I'll see your senator, and I'll raise you two judges.
I'm employed as a senior developer. I've been working in the field for about 25 years. The problem is that the job of software developer is that of an inventor with a massive assortment of parts to build from and methods to build with. Add to that the fact that clients don't really understand the problem they're asking the developer to solve and that the problem is usually outside of the developer's core knowledge areas. Ask a dozen experienced developers how they would solve a problem and you're likely to get a dozen different answers, and if you tried to implement each of them you'd find reasons that they're all bad in one way or another.
Instead of looking for a dev who isn't bad at what they do, look for one who is passionate about building software and not *very* bad at building it.
(*) Except maybe Donald Knuth. That dude knows his shit. But even he choses some bazaar tools to solve problems making it difficult to work with other devs.
Average != Median
In my area of work, you would not get hired as a developer. If you were not able to answer the OPs question regarding encryption, I would give you a pass and look at other parts of the interview.
Fear, Uncertainty and Doubt = [citation required]
Yeah, like the guy who asked me in an interview "What is the purpose of phase 1 IKE?" The only acceptable answer was "to protect against MITM attacks". It wasn't that I didn't know how encryption works but that I didn't read the same Cisco book (likely one 10+ years old), to get the same textbook answer.
Just because you understand how to use PKI doesn't mean you should always use PKI. Why not SCP? Why not file-encryption? Why was the question so specific and targeted for a single answer that most people wouldn't get to, regardless of competence, rather than an open ended one? "When would you use SCP vs PKI vs file level encryption?"
Learn to love Alaska
Just to add: if you did what I described, you would quickly discover that the actual secret you should send using PKI is the key to some other more efficient symmetric algorithm.
I'll see your senator, and I'll raise you two judges.
Why is this more to ask than that someone knows the language that a shop uses. Knows how to use the framework we use. Etc?
Sure, if being able to generate public/private keys and knowing about PKI was relevant to the position it would be a useful question. We don't know that these questions DID have any relevance to the job qualifications.
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.
Almost everybody is extremely bad at their jobs. Especially in IT, but in general too. I would say a solid 85% of people working in IT today should not be in the field.
I work in Security and so my job is basically to know, at a high level, how other people should do their jobs. Of course there are compromises that have to be made for functionality and cost, but in reality most IT systems are developed and architected in a way that no one should architect anything for any reason. The amount of money that's wasted because of poor infrastructure is astonishing. Companies could have an architecture that's twice as secure and probably half the cost to maintain if they were willing to make a one time investment in doing it properly.
Developers are a weird animal too. I know I'm playing with fire saying this on Slashdot. :) In my experience developers have a deep understanding of how systems work and are designed (obviously), but their understanding is *extremely* narrow. This is by no means true of all developers, but it's true of a lot. They can write brilliant code, but they can't tell you how to go about FTP-ing a file, how to encrypt an email, or how a domain works. It's a specialized skill set.
At a previous company I had to call support because my computer didn't grok with the domain and wasn't getting group policy. The tech, with her domain admin access, comes over and is obviously floundering trying to fix the problem. I suggest running a DOS command I know...she googles it and pulls it up...she gets to the command prompt and starts typing, "command\optionfoobar-x7", etc. How can you possibly be in that field and not know the *most basic structure* of a DOS command? I don't care if you know the command and options, everyone googles that crap, but you don't know how to type it in properly? A backslash and no spaces? Really? Even when you're looking at a webpage which has it verbatim?
Its no wonder things are in the state they're in.
That is my point. A basic understanding should be expected. Now a detailed expertise. I agree completely with what you are saying, and I say similar things elsewhere here.
I'll see your senator, and I'll raise you two judges.
Demand computer science then train
Train people? What sort of communist nonsense is that? Train yourself on your own time at your own cost you freeloader!
If you trust the document's own encryption mechanism, then you are still left with a problem. How do you communicate the password? PKI is a good answer.
I'll see your senator, and I'll raise you two judges.
Why the nonsense. WHY?
The general mechanics are easy to explain: the server gives a public key, the client encrypts the message with this given key, and then the resulting message can be decrypted only by using the private key which is kept secret by the server.
I think the guy hiring would already be much happier with that answer, rather than the candidate mumbling something about Excel and PDF documents.
I've sat through an upsetting number of tech interviews. Getting someone at the high end is a really horrible experience. People come in with very impressive resume's only to show no real skillset.
I don't think having some lack of understanding of encryption is a non-starter.
But I do want to see that someone has a good breadth of experience, and can talk about a good number of things at some base understanding:
How a file system works,
how a network works,
how memory works,
how a repository works,
how a software build works,
how to use editor functions far beyond what can be done by microsoft notepad,
how to use a regex,
how to make a presentation from data,
how to make a lamp webpage,
how to merge tables from multiple databases,
how to do statistical tests on data,
how to set up proper controls for experiments,
how to write. The other part is that bad applicants pervade the pool. Good hires get hired, and held onto -- Bad hires don't get hired, or get released back in the pool. If you want a good hire, there is a bunch of crap applicants to wade through, or you pay the cash to lure talent away from a lucrative job.
Oh the subject.. Eventually gave up on hiring a senior, and posted for a junior position, and got far better applicants than we ever saw for the senior position.
You post two examples of questions you asked your applicants.
Exactly zero of them applied directly to the actual work they would be doing.
I am fucking sick and tired of being asked moronic questions during interviews - and horrified when people I work with ask them. Why do you feel the need to show people how much they don't know, and pretend you are smarter than them?
If you want to pretend to want to find out how smart your applicant is, by all means continue. Otherwise just administer an IQ test and have them write some code related to the product they will be working on. Then, for gods sake, ask them about themselves.
The interview is not about you -- it's about the applicant. When you find a decent one you do want *them* to actually want to work with *you* right?
"Oh, you hate your job? There's a support group for that, it's called everyone, they meet at the bar."
In that case yep, I'm totally with you. No matter their specialization, a software developer should be familiar with basic concepts in encryption, networking, algorithms, hardware architecture etc. Nothing in-depth maybe, but they should have some idea what's going on. It's like the way a doctor might specialize in oncology but should still be able to identify a ventricle or an Achilles tendon.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
If you are asking for specific knowledge you will have to go thru vast amount of developer, and when you find those, they will lack other knowledge. But what differentiate a good developer to a bad is : what question to ask to get the requirement, and how to proceed to research for lack of information. So not knowing about a specific encryption is not bad, if the developer ask the correct requirement question and demonstrate a willingness to search for correct source depending on such requirement. the specific question does not matter, it could as well be about a robotic software to remove feather from dead chicken in an assembly line. In your specific case i would ask why you chose this specific encryption, if you have a specific vendor or open source in mind, what would be the timing requirement (can it run slow) what would be the memory footprint requirement , how often it is used, what would be the liability for vulnerabilities, how are the key managed, are there legal requirement on the key management etc...etc...
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
Your company should provide secure coding practices training. It's something that is becoming more and more common, but hasn't quite hit full adoption yet. It's being driven by regs and customers. Pretty soon it's unlikely you'll be coding anything before you take the training. It's the way the industry is moving.
However, there is another piece here. I am about to give you the keys to becoming a superstar developer. No BS, this is going to sound obvious but if you follow these steps you'll become the go to guy in no time and your career will advance...
1.) Make sure there is a business requirements document *before the project begins*
2.) Circulate that document to stakeholders, *including the information security group*
That's it. That's the whole secret. It's the key to every development and infrastructure project. It will seem like security is a pain in the ass and is raising the cost of the project but in the medium to long term they are *greatly* reducing the cost. You will also be loved by the infosec group, which means that you will be loved by the customers and the business as well. They just won't know it until you go to actually sell the product but once you do...you will be the savior.
I'm not kidding about this. Do this and you will be successful.
I would like it flip it around and ask you why do you think your companies are actually worth working for? Are you going to employ us when we are 40, 50, 60+? Are you going to ask me a bunch of stupid questions even though I have 20 years of work in my portfolio? I just don't understand why its so acceptable for employers to be so arrogant in the IT world compared to other professions.
If companies really wanted good people they would:
I have found that software development might be a decent job, but a horrible career. I'm going to go raise goats and make cheese (sorry ranting)
I laugh at inappropriate times.
This is a problem I see in the entire STEM field. You work on technology X for a while, you learn it inside and out, and you expect everyone else who is "qualified" knows what you know. You want to hire someone with no ramp, who is going to drop in on day 1 and start doing great stuff, just as soon as he sets a password to his laptop.
That's great, until you ask a question about second-year college stuff. Like "show me how to reverse a linked list", which is basic Data Structures class material, not the hard stuff. And then suddenly they get the deer-in-the-headlights look. Back around '04 or so, the group I was in interviewed some people, with the same interview style that I got hired with. All the Java-addled recent CS grads were useless. Only the EE grads actually knew how to program.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
The OP was looking for people to describe the process in detail and the best answer would get the job offer. Welcome to Slashdot: The interview board.
Just because someone can't describe a fairly technical topic doesn't mean they're bad at what they do, it means that cryptography, data security or possibly data transmission work isn't what they do. Perhaps you need to revisit your recruiting materials to see if you're attracting the wrong people.
I like to consider myself more informed than a lot of folks out there (I have an unread copy of the second edition of Applied Cryptography! in a box in the garage! or maybe it's the first edition, still unread either way) and I'd be hard pressed to go beyond "I'm pretty sure it relates to the difficulties of factoring large primes or the products of multiplying large primes."
And the first question I'd ask for transmitting encrypted materials is quite frankly "who are the users at each end?" because for a surprising amount of things I'd probably say "install 7-zip and do a single-page detailed step-by-step set of instructions. Possibly laminated."
fencepost
just a little off
There are thousands of senior software developers who would know these concepts even when it is outside their main expertise. But majority of them are wells settled in good secure positions and are not in the market. Take me, for example. (no, you can't really take me, I am not applying). I work in computational geometry but I have done public/private key encryption and have written scripts to watermark the executable in a post-build operation with a public key. I have been a general purpose troubleshooter who can pitch in fixing stuff like re-architecting a matrix solver to reduce disk usage or fingerprinting executables and dynamic libraries with build configurations to detect incorrect packaging of installations. Yeah, I know such varied stuff, but I am happy with my pay, benefits, location, work atmosphere and colleagues and am not even looking for a job. You need to move heaven and earth find people like me.
Traditional posting a job opening and grepping and awking through the resumes will do you no good.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
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.
Why are you holding this up as an answer to be ridiculed? This is a perfectly fine way to approach the problem.
Many sensitive documents are in Excel format and Excel has an encryption function (same with the PDF standard). If I were to send a sensitive Excel file to someone, I would most likely just encrypt it within Excel, send it on its merry way, and then just deliver the password to you out of band (like via the telephone). That is secure enough for most corporate purposes. It's not like I'm sending you nuclear launch codes or anything.
Obviously that doesn't work in the general sense because not all document types have specs that support encryption, but what's wrong with taking the easy route? I can pointy-clicky encrypt an Excel file much more quickly than you can organize a key exchange, verify each other's keys' authenticity, etc. Your way would be more secure, true, but sometimes, you just need to email a fucking Excel file and get on with your life.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
One of the problems that I have in IT is that many companies expect that new candidates have experience with all the equipment they would be expected to handle. For example, if you're a systems integration person who works in an HP shop with IBM storage and Juniper networking, it's hard to jump to a Dell/NetApp/Cisco environment. Not technically hard, mind you -- every vendor has their quirks but the same stuff gets done on everything. The hard part is convincing the interviewer that you have enough generalist skills to pick up what's needed. I regularly work with different vendors' equipment, support procedures, ways of handling patching and firmware management, storage configuration and so on. Do I go to training classes and spend months learning? No, I use my knowledge of what needs to be done at a high level and research how that particular vendor implements it, picking up what I need as I go.
That said, there are some basics I agree with the submitter on:
- A person with 20 years' dev experience should have at least encountered PKI at some point!!
- A person who just graduated from CS should be able to code a simple example without too much trouble...nothing fancy, just basic code literacy stuff.
- A person with experience managing HP equipment should at least be able to articulate what may or may not be different managing IBM/Dell/whatever equipment.
I think two things need to happen.
1. Companies need to stop hunting for the exact right person and hire someone with the expectation that they'll learn on the job. You may not be 100% ready to "hit the ground running" (I hate that phrase) but if you have the skills and desire to learn you'll figure stuff out. The company I do work for has some very proprietary stuff that no one outside of the industry knows before coming on board. It's expected that new hires take a while to become fully productive.
2. The crop of employees does need some improvement. This is way easier said than done - smart people are scared of taking a job in IT or development because of the threat of outsourcing or automation. I personally think we're still working through some of the people who got into IT in the first dotcom boom, and now we have a second phone/social/mobile/big data bubble pumping more people into the field. In this sense, I feel for employers because their hires need to have the potential to pick up the skills they need if #1 is to be achieved.
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.
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
LOL. Well you have discovered that most developers know very little about application security. And here we are, wondering why things are so insecure - and heading head-long into the "Internet Of Things". What a train wreck that will be unless things change. Read my article about this: http://www.transition2agile.co...
We're all crap at it, with varying degrees of crapness in our specialized areas. I'm a terrible developer, the only upside to that is so are all my peers. I was just thinking today, I've got all these ideas on getting our internal test and deploy systems into a top notch state, but it took me all day to fix one problem with the search, I'll never get around to the other stuff, and when I do it'll be rubbish, hit a multitude of problems, take longer, be slower than expected, and then I'll have to maintain it.
I envy junior developers. They're twice as crap, but ignorant of that fact.
The OP suggests a weirdly specific Shibboleth, and half the comments are people saying he picked the wrong one - like "public key encryption isn't the right thing to test - you should be testing knowledge of computer architecture or regexes, or how to set up a web page with a specific stack" or whatever.
For developers, we usually test whether they're good at programming. We let them choose whatever language they want (because in the end they're all mostly the same, and a good programmer will be able to use any of them) and have them work through some simple but realistic programming exercises (eg. from this data structure, figure out whether person X manages person Y). Most fail in a way that demonstrates they won't be able to do the job, or will take too long to get going at it. It also usually identifies people who have weird religious attachments to certain tools, languages or methodologies (Many times I've heard crap like "Oh, I can't type this simple answer into a regular text editor, I need XYYXYXZZYX with autocomplete on" or whatever).
Anyway, back to the OP, yes I would expect that most developers should have some idea how they would encrypt a file, even if they haven't used the tools themselves personally (this isn't a core job in most development jobs I know of). But I wouldn't think they're dumb or unqualified if they don't. Why use a weak correlation like "a good developer probably knows how to encrypt stuff" when you could just test whether they can do development stuff directly?
And we do the same stuff for other jobs. When we were interviewing a graphic designer to work integrated with the programmers, we had them do some graphic design in the interview, fixing up pages we had purposefully borked in a real project. Again, most disqualified themselves pretty quickly when faced with realistic job tasks.
Let's not stir that bag of worms...
Some people just choke in interviews. Worse, other people sound *great* in interviews. What I find is the best guide is references, especially if you can *interview* the references. Just be aware that you have to scale the response you get. If the reference sounds very positive and enthusiastic, the candidate is just OK.
Anyhow, I wouldn't necessarily expect a senior developer to automatically have much experience with public key encryption. Most developers in "hot" fields like mobile apps will have some familiarity with it because of app signing, but you can easily spend twenty years as a developer in certain kinds of contexts without ever having to give much thought to it.
You interview developers with 20+ years of experience? Good for you! I found it so hard to land an interview with 25 years of experience as a lead developer that I decided to leave the field. People just assumed because I was over 50 I wasn't up to date with the latest technologies.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Asking whether the document is PDF or Excel demonstrates a lack of understanding. The document type is irrelevant. It is a file of bytes. You want to send those bytes securely. (And you may want the receiver to be able to verify that it actually came from you.)
It demonstrates either a lack of understanding or more than a passing familiarity with the applications. MS Office has used AES for the built-in encryption since Office 2007. That would seem like a reasonable choice for sending a file to a contact, provided you choose a strong password and communicate it out-of-band.
And my use of those "PKI and X.509 type certificates" is to call a library to deal with them, blithely ignorant as to what those libraries are doing with the keys. Just like I don't write my own code to implement HTTP, and then TCP, and then IP and then ethernet.
The other enormous stupidity in this question is PKI is only one solution, and may not be the best one. Encrypted zip may work just fine, with a password transmitted via another pathway. Or if the document is in a format that supports encryption, hence the question about PDF. Or scp/VPN/etc to a secured share. Or print it out and put a stamp on it.
Exactly. For example, most embedded microcontroller software doesn't use cryptography at all. Hopefully, all such interview questions would be tailored to the job being filled and to the applicant's resume.
One thing I can think of that seems to me like it should be common knowledge among software developers are CRCs. Even so, there are probably many qualified software developers who have no knowledge of those - and don't really need to.
It gets worse than that. I knew a guy who washed out of the Ph.D. program because, the second time he tried his written prelims, the question he tried to answer was mistaken and there was no answer.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I would argue that EE's, and more specifically CompEs are the only ones whose job might depend on manually implementing a linked list. We do it all the time, linked list traversals are key to many network card hardware implementations... Programmers and IT will use high level languages that basically do all that for them, they really just need to understand the tradeoffs between linked lists, growable arrays, hashes, etc.
But anyone should be able to understand what a linked list is, and roughly how to manipulate it. On an interview I wouldn't expect gorgeous implementations, but they should be able to work out the logic in 30 minutes. That falls in to "general knowledge".
1. Review Machiavelli's research on using Mercenaries.
2. Why are you uncomfortable about asking someone to go find out?
3. Have you tried finding out by using the Google search engine?
4. If you think people should know this, then way don't you?
Since Excel and other programs natively provide security, why not use that?
Because native security ain't?
An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media
So many people think this is easy and won't pay for the expertise to hire "the best" (Everyone wants the best, everyone also wants to pay industry average wages... Moneyball doesn't work in Tech). A good recruiter will be able to talk to you to find what you are looking for, find you a couple candidates - listen to you on why you didn't like them and change what they are sending to you, repeat until you find what you are looking for
Honestly it sounds like you have a specific set of filters you are looking for that you haven't applied (cryptographic systems, security maybe) and are bringing in generic candidates that weren't screened for these skills. I can trivially answer your questions - but then I have been in that area for 20 years, don't ask me how to write a database query or setup a JSON parser.
I have mod points and I am not afraid to use them
It's a common pattern and I have to watch out for it myself. Take something I know a lot about (e.g., thermodynamics). When I'm working with other people I instinctively feel that everybody in the world including uncontacted tribes in the Amazon should know at least 10% of what I know about the topic. Once somebody doesn't even show that crude level of knowledge then I figure they are either uselessly ignorant or intentionally obstructive. In reality, the average person will know virtually zero on the topic by my gut feel is that they should know more.
Expecting a software developer(a specialist) to necessarily possess knowledge of encryption technologies is naive. For example a Java developer specializing in UI's is never going to have the need to delve into the world of file encryption. A network specialist is never going to need to know the difference between an Array and a List.
Decide what the position requires, advertise the job referencing the requirements, and focus on the job requirements when you are interviewing the candidates. Everything else is extraneous, a distraction, and a waste of everybody's time. .
I've worked as a developer for the past 15 years. In that time, I'd break down the quality level as follows (roughly):
10%: Absolutely terrible; should be fired even if they were willing to work for free
40%: Not absolutely terrible, but also not someone I'd hire if I were building my own team (even if they came cheap)
40%: Someone who does decent work but isn't going to blow you away; I'd consider hiring someone in this group, but wouldn't pay a premium to bring them on board
10%: Exceptional. Not only would I hire someone in in this group, I'd be willing to pay "above market" to get them
The numbers are, obviously, rough (no to mention subject to personal bias and totally anecdotal).
One problem: plenty of people in the first two groups interview like they're in the third group. Also, some of the people in the 4th group interview like they're in the 3rd group. I submit that some of the most successful teams are successful not because they have great ideas (although that never hurts), but because they have an interview process that's able to sort people into the right "bin" more accurately than their competition can.
This is true, but at least in academia you know who's writing the exam questions. The question these sorts of exams seem to be asking is, "Can you read the papers I've published in this particular area and make sense of my results," or, "Assuming you've read my papers, how would I tackle this problem."
That's not to say that they're questions worth asking or not totally self-aggrandizing, but at least they're predictable. Honestly, the professors may actually think that they're good questions. Academia rarely (and only incidentally) selects for people who are good at teaching.
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
In a case like this, I like out-of-band methods. If I send an encrypted file over http (an unencrypted file over https would also work, provided I was sure I was getting the right certificate), and telephone in the password, only somebody who can intercept both can read it, and I don't normally worry about hiding things from the NSA.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
He didn't even say anything about "build an app which sends a file using PKI". He just said "how would I send a file?"
Right, which is an absolutely terrible question because it's too vague. Vague questions are always red flags in an interview -- there are too many possible ways of answering to be able to determine which is the "right" answer, and applicants will tend to start looking for where the trick is, since it sounds like a trick question.
The better approach is to be specific in the questions. Plus, asking specific questions will make the interview process for accurate.
It's no more unreasonable than asking "I want to send a stream of bytes to another computer on the internet, how would I do that?" and expecting an answer describing TCP sockets.
Correct, but that is also a terrible question to ask for the same reason. There are multiple ways of correctly answering it, but with no clear hint as to which is the answer the interviewer wants.
This whole post is a troll. WTF is he expecting from his potential candidates? I'm a sharepoint developer, but I have no idea how I would answer his question. It's stupid. Put a fucking folder on your company file share (or a library on your Sharepoint site), where only you and I have permissions, so I can upload and you can access. Who encrypts files to send internally? If I were applying for a job and I got asked this question, I'd ask who the head moron was that decided internal communications needed to be encrypted as opposed to password protected.
I interviewed at one place for a job that would involve doing some serious SQL. They asked me to write a simple SQL statement. I just wrote down the SELECT..FROM..WHERE statement on the whiteboard, and waited for them to ask for something a teeny bit difficult. They didn't, and were apparently satisfied by what I'd done.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
In the tech field, age discrimination trumps experience. This is either due to employer preference or health care cost (the latter can be easily bypassed with a loophole)
New Economic Perspectives
I think the file type actually does matter. Since Excel and other programs natively provide security, why not use that? I get that if you want a security person you need to ask specific questions, but perhaps you need to be more specific when looking for applicants. A killer JQuery person or data translation expert probably won't know PKI very well.
No - it has nothing to do with what the original poster asked:
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.
This is for a senior developer / software architect role. If I were in Ramone's position, I'd feel the same way. I learned the basics of PKI while an EE undergrad back in the early '80s - concentrating in telecommunications. It was in a required course. And I didn't really use that knowledge as a professional until the late '90s and I continue to use it to this day, even though I'm not a security professional (though I do design secure networks). Now, that being said, a developer today, to be a software architect, should at least be able to explain the basics of PKI at a cocktail-conversation level. They don't have to know what goes into the various SHA and RSA algorithms (I certainly don't know off the top of my head), but they should be able to talk about encrypting with someone's public key and the only way to decrypt is with that person's corresponding private key. Security 101 is probably part of every single CS curriculum, if not every IT-related one.
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
Now this response from the candidate I can understand. Remember this isn't the first interviewee who couldn't explain PKI. In this case, they may have been thinking "Excel and the PDF standard both support encryption - so I'd just answer that you password protect the file. If it's a plain-text file, you could use the password protection feature of any .zip archive utility, or better yet use PGP/GPG encryption if you know the recipient's public key". It may well be that Ramone was expecting something different when the candidate asked this, and on seeing the surprise on Ramone's face, lost his train of thought and got confused.
;-)
After all, the interview was apparently for a high level position writing code for Ramone's pool cleaning business.
"A little misunderstanding? Galileo and the Pope had a little misunderstanding."
"
If companies really wanted good people they would:
Treat their current employees better.
Pay them market rate instead of rewarding job hopping.
Learn how to manage.
Build a reputation that will attract good talent.
Learn how to be professional.
"
Have you wonder why the IT field ( tech field in general ) rejects MBAs? Especially MBA with tech experience? Because the MBAs will bring sanity and order into the house, things that those kiddie startup CEOs hate.
New Economic Perspectives
Vague questions are always red flags in an interview -- there are too many possible ways of answering to be able to determine which is the "right" answer, and applicants will tend to start looking for where the trick is, since it sounds like a trick question.
Not the right applicants. For most positions (except the ones where you're a very small cog in a very large wheel) you have to be able to deal with people too.There was one question in a recent interview that my wife conducted, to which the applicant replied "I can't answer that without knowing more about the requirements." Which was exactly the right answer. He got the job.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
I grok the snark, but in my experience people who take their own initiative on learning and personal development gain 10x more than people who get sent to some boot camp or seminar on their employers dime. If you are learning something useful it all comes back to you in a future paycheck anyway. "I haven't been trained on this" is generally an excuse I hear from people who wouldn't know their ass from a hole in the ground even if they did attend a 3 day ass-recognition boot camp.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
The two aren't even the same skillset. I've known plenty of security experts who could rattle off the math behind a prng or the algorithm for a secure cryptographic hashing function or how to correctly use java.security, but who couldn't write shippable code to save their life. I've also known plenty of developers who could build a great mobile game in a few hours or an efficient and realistic crowd simulator or a massively scalable data layer, but don't know the first thing about security. I know very, very few people who are both security experts AND badass devs, and they are mostly either superstar academics or principal engineers at the tech giants.
I disagree that not knowing both makes them bad devs, as security is just one specialization in many. As long as a dev can build quality software and either has a working knowledge of a lot of aspects of software engineering or is an expert in one or two areas, they are a good dev in my book. What IS worrying is that a lot of people who seem to think they are security experts clearly aren't. Papers like this one point to the need for more devs to specialize in security, which is a totally different issue than the one OP brings up: http://dl.acm.org/citation.cfm...
I normally hire two classes of people. Rank and file and Leads. My leads typically have to be experts in a given field as they will be making decisions and driving future direction in the project, but my rank and file I just want basic aptitude and interest. I find I get more out of learning about a candidate when ask where he falls on the EMACS vs VI war then anything else. The average candidate is so nervous at an interview they over analyses everything and just plain forget basic information they know. I've seen basic graphics guys forget what a corss-product was then perfectly explain how to calculate a normal map given an arbitrary height-map. These types of mistakes are typically owned up to nervousness.
Now for team leads you need to be very specific on your requirements and they better be able to present a portfolio of prior work. I let the candidate lead on descriptions of what they have done in the past and then ask detailed questions as they come up on more specific implementations. I need to know that the candidate is not only competent, but can relate his work and needs to people who will be under him. If he can communicate about specific solutions he has worked on in the past then he will be unable to clarify system requirements to subordinates. One in every three candidates will try not to talk about specifics due to trade secrets. I normally take this as an attempt to skirt a lack of experience so I then ask hypothetical about a similar system I can relate there work to. I'm satisfied if the response is relevant to my scenario or if the candidate can explain in detail why its different then his previous work, but if he doesn't answer the question then we know he has exaggerated on his resume.
Others, might have different methods, but I find you really don't learn about someones aptitude until they work for you. Its almost impossible to determine if people are professional, punctual, or motivated from an interview since almost every answer is rehearsed and a lye to try and get employment. So, I try to make reasonable evaluations on qualifications and pick people that will fit well with the team. If the guy did lie we will find out soon enough and he will be interviewing again soon after.
Momento Mori
Honestly, why would you need to reverse a linked list in a real application?
Hell, if you knew you were going to have to traverse it in reverse at some point, why didn't you just make it a doubly linked list in the first place?
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
... in their incompetence. Typically the groups with the slickest advertising tend to be the worst at their jobs. I've sat through some very sharp presentations only to find out that the brains behind the organization are themselves mostly just gifted salespeople with almost no technical brain trust.
At this point, I find such slick advertisers to be a turn off because I can't trust a fucking thing they're saying. The more inept marketers tend to be more honest, which means you can account for weaknesses before they become fatal flaws.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
That's because the only purpose of the question was to determine if you any semblance of programming skill. Such a simple test filters out 95% of candidates and leaves a lot of time to have real discussions with the other 5%.
I know the answer to your question! And, I'm one of the great developers, not like all those other dummies! All the other guys suck, except me and the people I work with! Let me give you some examples of how I'm not like all those other guys!
Man, I feel so good about myself right now!
-1 Uncomfortable Truth
The situation was unspecified. If I had a document with built-in security at home, and wanted to send it to work, I could just telephone in the password. BTW, do you have any actual knowledge about Excel security? It may well be just fine, at least for the level of security desired.
Also, to give an intelligent question I have to know what I'm trying to guard against. A casual interceptor is one thing, the NSA another. It usually doesn't make sense to make security decisions without an evaluation of the threat.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I've both helped hire people and have been a hiring manager, as well as the hot-shot programmer and now becoming the wise gray-beard everyone speaks reverently to and then ignores.
When I interview a candidate on the phone, my primary interest is to screen out the candidates who are either obviously lying on their resume, or who have inflated their resume or are otherwise uncommunicative. (You'd be amazed at how many are unable to hold a conversation about the stuff they've supposedly worked on for a couple of years. Almost as if they put it into their resume just to inflate it. And I feel free to go through any part in the resume; for example, I dinged a guy because he put in his resume he was a private pilot. Having a father who was a pilot and learning to be a pilot myself, I asked him questions related to his being a private pilot--which he utterly failed to answer. And if you're willing to lie about something that irrelevant, what else are you lying about?)
In person, however, I may ask a couple of questions about the specific work I'm doing. But for the most part I stick to straight forward development questions: I ask the person to solve a problem which requires a loop, to walk a linked list, to search for primes. What I'm looking for, however, isn't if the person is a mathematician, but how he solves the problem: does he automatically close the curly brace when he writes the open curly brace at the top? Does he store intermediate results somewhere, and how does he chooses to store them? Does he use any naming conventions in his sketched out code? When he gets stumped, how does he talk to me about solving the problem? Does he come up with anything I hadn't thought of?
And that's because I'd rather hire someone who seems smart and communicative and who can sketch code on the fly than someone who may happen to know about public/private key systems.
My theory is that specific problems that revolve around the web site can be learned on the fly: someone who is smart can look up how OpenSSL works, for example, and start implementing code against OpenSSL. But someone who has OpenSSL experience but who is otherwise unable to communicate effectively or solve problems on the fly is going to be useless as soon as we move on to other problems.
And my theory is the same regardless if you're hiring a beginner out of college or an architect with 20 years of experience; the architect I'll just ask much harder questions, as well as probative questions about the sort of design work he's done and the types of design problems he's had to face.
In terms of quality, I've found that roughly a quarter of the people I interview I'd happily work with, but for architectural level stuff, it's hard to find someone who is really good. That's because software development seems to weed people out after 10 to 20 years--and many who survive that long do so out of inertia, not because they're really good at what they do. So if you want someone with 20 years of experience who can architect something complex and get it right the first time--you're going to be looking a long time.
(And if you happen to be hiring in Raleigh, North Carolina and are paying above competitive rates for a first rate architect and developer, send me a private message. :-D )
I should send you very sensitive information?
If I have it, and you don't, and it's very sensitive, then you'll have to supply me with a written and stamped document, signed by multiple Important People (tm), which states that it's okay to give you the data, and also specifies how I'm going to give you the data. I also need to be cleared from issues on your end. Maybe your network is hacked. The data is safe with me; how do I know it'll be safe with you? I need to be waived first.
Papers, please.
Are you just asking these candidates questions that are too specific?
My team asks candidates to solve some relatively simple problems. They don't have much to do with our software. It's just stuff like filtering strings for pairs of characters and some other stuff. It helps us to evaluate if someone can write code to solve a problem.
If they can, we will ask them more specific questions. Now, i'm a graphics programmer. I work with open gl and 3d stuff. I'll often ask, "Given a triangle with points A,B, and C, how would you find the normal?" I realize this community is going to contain lots of people who find that question laughably simplistic. it's not even a programming question (though neither is describing key pairs). I'm just looking for them to say "cross product". . nobody in 3 years has ever known.
the purpose of the question though isn't to shoot someone down. it's more like extra credit. I'm curious if they know anything about geometry, but we've hired plenty of guys who can't answer my questions. they have learned, and i was confident they could because they did well on the general questions.
Told me that they'd brought in well over a dozen candidates to interview. Now I'm not all of that but the fact I beat out a dozen other so called Senior Linux engineers astounds me to some degree.
Very, very local sample: out of 5 I work with currently, I have:
* 1 with a real interest in his work, eager to learn and improve
* 3 with a "happy with what I know, afraid of anything new"
* 1 with a toxic attitude, i.e. resists any attempt at being introduced to version control systems, code reviews, unit testing and the likes
For the past 15 years, I've come across maybe 4, 5 developers really engaged in their trade, with a positive attitude and a genuine eagerness to learn new things, find the proper tool for a given problem and learn from mistakes they and others have done.
A good 20 others could have been janitor for all they cared: it's just a 8-17 job for them.
Sample is quite small, and comes mainly from french consulting firms - CGI, Sogeti, Atos, Accenture, Sopra.
It's no more unreasonable than asking "I want to send a stream of bytes to another computer on the internet, how would I do that?" and expecting an answer describing TCP sockets.
Because both are pretty unreasonable. Why would you expect someone to answer such a vague question by describing TCP instead of describing Ethernet, IP, UDP, FTP, HTTP, scp, etc.?
This is a two-sided problem. I'm a software architect and I've been looking for a new gig recently. Most companies don't get you are interviewing them as well.
First up, if I've got tons of experience on my resume, ask me about it. A conversation about what I've done will reveal my depth of knowledge if you know how to question appropriately. If you aren't familiar with the work I've done, use it as a chance to see if I can teach you about it. If I can educate you on an unknown technology during an interview, I'm likely a candidate you are going to want.
Writing code on a board is useless. I have my laptop with me, I even state this, yet everyone seems to want to watch me write code on a wall without the benefit of the tools I use every day. It's like asking a carpenter to build a cabinet and then locking away her toolbox. If you really want verify my skills, send me a test. Or I can point you at my github.
If you insist on playing the puzzle-solving game during the interview, I'll counter back with a similar question at some point. So don't be surprised when the tables get turned on you. I'm trying to determine if I want to work with you just as much as if you want to work with me. Nothing sucks more than being a good engineer and landing in a group of far less skilled developers.
Find those people that want to learn. They will carry your company far if they also have open minds and enjoy collaborating with others.
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.
Ouch.
In debates about Christianity, there are two groups: those looking for answers, and those looking to just ask questions.
That's a tough call. A code copied off the web that works is often a better solution that one engineer's half-baked, bug riddled reinvention of the wheel. A better criteria: you copied it off the web and it works, do you have any idea why it works?
Waltz, nymph, for quick jigs vex Bud.
It seems pretty clear that your concept of competence is whether a developer has a question that can stump another. Therefore the test should be whether your interviewee has a question *you* don't have the answer to, not vice versa. As for encryption the test for expertise is whether a developer who is not a security specialist realizes that they don't know nearly enough to do it correctly and unless they've worked on that technology for years they're gonna do it wrong (and even the folks who've done it for years cannot escape making mistakes).
Honest real life application:
Producer-consumer with lock-free implementation.
Producer thread (or threads) queues to linked list atomically (insert at head using compare-and-exchange).
Consumer thread periodically empties the list by exchanging head pointer with NULL (compare-and-exchange). To make this list FIFO, consumer will now need to reverse the list.
Why not doubly linked list? Because we want a lock-free implementation for scalability.
Who find some obscure question the candidate can't answer, then use that to demonstrate their superiority over the candidate. Instead of having a brief, relaxed, open technology conversation. When the candidate relaxes and starts talking about their technical experience, it isn't hard to tell if they are a good fit or not. And there is no insulting or demeaning of anyone in the process.
FWIW, I have been conducting a lot of interviews lately and I always say I am looking for 49% technical skill and 51% interpersonal skills, because the hardest problems in software engineering are not technical.
I'm going to echo what others are saying and say that I think your examples are bad. I wouldn't necessarily expect a developer to understand public key encryption unless they had a background of working with public key encryption. You don't necessarily need to understand that sort of thing to make web applications or iOS apps, so it really depends on the kind of development you're doing.
Regarding file encryption, I find the question to be reasonable. If you want to send an encrypted Excel file to someone, it's probably smarter to just use the built-in password protection and encryption. If you can trust that someone has Excel enough to send them an Excel file, then you can assume they have Excel enough to open a password protected file. I would not, however, trust that someone has GPG installed.
Getting back to your question, I generally estimate that roughly 80% of people are bad at their jobs, whatever they do. This is based on a couple decades of anecdotal evidence in the professional world, but it's borne out with the new experience I continue to have, and other people seem to share the experience.
Close. If you want good people, you treat them like good people. This includes salaries over the market rate, although not necessarily anywhere near what they're worth. (If you can find somebody who can do twice the work for 10% more pay, great!)
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Everything today works with computers. You can't ask everyone to know even a bit of everything, because most jobs only require knowledge of specific parts, protocols, languages, APIs, etc.
I'm pretty sure you could ask everyone around you if they know what opcodes and registers are and you'd find extremely competent high-level programmers who have zero clue what those are.
Get free satoshi (Bitcoin) and Dogecoins
I disagree. If that's an acceptable answer then so is "Click the send encrypted email button in the email client." You do have server integrated encryption don't you? Why is the developer/user even concerned about this? If there's a business need for encrypted email then it should be handled by the infrastructure team and (ideally) not rely on the user to know or care about it.
If you're interviewing for a developer and you want to check into generic domain knowledge ask about Source Code Management and dealing with merge conflicts. And, don't use abbreviations. Just because you know what SCM means doesn't mean that the interviewee is going to pull up the correct reference under stress (and yes, interviewing is stressful).
--
JimFive
Please stop using the word theory when you mean hypothesis.
Did anyone ever use average to mean "mode"? I really truly doubt it.
Yes, usually when they're trying to sound smarter than everybody else (and then usually when they're not).
back to TFS's question: you know why Java is such a popular language? Because it's really helpful for helping the bottom 90% of programmers write stable code.
The 5% on the right side of the curve can go off in a corner and bicker about whether their Haskell monads or Python function decorators are more becoming of a "good" programmer, while industry gets back to work to churn out code that get potatoes from Boise to Omaha and helps grandma balance her checkbook.
Any reasonable economist doesn't want to see you using somebody who can implement Shamir's Secret Sharing from memory (on a napkin, just for completeness) writing the potato shipping-manifest code. The best thing you can do for a person is to place them in a position where they're being fully utilized and appreciated for the work they do.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
If you don't have a broad general knowledge in your field you are merely a hammer looking for nails.
careful, there!
what you will find - and think that you got a star - is someone who spent their life (up to this point) memorizing stuff. yes, I'm thinking of folks from india (sorry, but its actually true).
and when I get into an interview situation, they ask me to recite algorithms and write code quickly on the board. neither are important to me and neither have been key to my success in my jobs, over the years. coding is NOT a race! I take my time. so what??? is that a crime? I am careful and - honestly - as you get older, you work a bit slower. but more careful (from my experience with older and younger guys).
I can GET the answer. but I rarely carry it with me, upstairs. way too much info to keep up there. at this point, I actively flush OUT useless info that can be looked up quickly.
when I respond 'I'll search for the current best algorithm, read up on it, adapt it, port it and debug it on your system. I can do that, but I won't memorize it and I won't code 'live' in front of you since that's never ever a part of software engineering.'
the older and more experienced ones get that. the younger ones just have ego issues and anything they learned last year in college should be - forever - memorized. that's how they think. they can remember that sort alg from last year. how come you can't remember it from 30 yrs ago?
sheesh. the field is being ruined by young-uns. and they think they really do know it all.
--
"It is now safe to switch off your computer."
Telling your applicants to research PGP before scheduling an interview?
..I would say it is approaching 100% They just do all of the stupid things I tell them to, they should know better! ;)
I wish I had a lawn.
Seriously, check how HR or your agency is screening applicants. I've found too many of them that do keyword-based screening, and they're throwing out any applicant who doesn't have exactly the keywords on their resume that you put in the job description. That can filter out the good candidates with broad backgrounds in favor of job-hopping contract people with the canonical "1 year of experience repeated 10 times" who know how to put the right keywords in to pass the screening. Have HR give you all the resumes they received and have one of your guys sort them to remove the ones who clearly don't have any relevant experience, then compare what's left to what HR thought passed screening.
I've never needed to do any such thing, and it's been 20-mumble years since college, but I can damn well answer such a trivial question, as fast as I can write. If you can't, then IMO you can't solve very basic coding problems. I don't like or use this question, because it's one people memorize, but I'd be quite comfortable rejecting anyone who couldn't figure it out (making allowances if they don't remember C pointer syntax, but still got the approach right).
Socialism: a lie told by totalitarians and believed by fools.
What happened to all the /. posts about how there is an excess of qualified U.S. candidates and companies asking to raise the H1-B cap are just trying to pay people less?
Anyway, OP's problem is one I think is very common when you're actually looking for someone really good. Even if crypto or security is not the primary job, a senior architect/developer/designer will be able to do a much better job knowing about crypto and security for the same reasons such a person would do a much better job knowing about multi-threading or cache behaviors. Knowledge and skill in those areas will ensure the design and code starts out in a better state than otherwise. In today's increasingly security-conscious world even the most basic of applications and devices need team and project leads to consider security as a fundamental aspect of development.
A lot of answers to this post are basically stating security considerations are not important to the job or the questions are too specific. I disagree with that. (Although I do think it would be OK for people to make a few mistakes around details in an interview as long as they demonstrated proper understanding.)
Maybe a candidate does know how to set up a web site to use HTTPS instead of HTTP. Does that same candidate know why certain cipher suites should not be used? And that really only secures the public network communication. What ensures user passwords are not easily accessed while in use and not just while at rest? How do you protect sensitive keys, symmetric or private, like the one used to encrypt user data?
If you're putting together something super simple and turnkey like a personal blog then maybe you can get by just following examples you read online. But if you're actually developing a new application or device then your solutions will need to be customized to your needs and capabilities. And that's not something you can copy/paste out of a Google search.
Honestly, I keep hearing stories of companies doing interviews that are pretty much brain teasers and exercises in CS101 recall all the way through.
Say you're hiring a web developer. It's good to ask one question out of left field... "How many times do the hour, minute, and second hands of a clock perfectly align in 12 hours?"... to evaluate thought processes and see if the applicant dives in. But the reality is 90% of web development work at 90% of companies is pretty basic.
To the framework jockey who can turn out excellent, well tested code, even CS101 questions about recursion are pointless. Big-O notation is useful, but not often used. Blah blah blah.
When I interview, I'm looking for smart, socially well-adjusted people who have a track record of getting things done and not pissing their coworkers off. Questions are directly related to the position I'm hiring for, with one "fun" one - and I'm clear that the brain teaser isn't a right/wrong pass/fail scenario. If the people they'll be working with think they're a fit, they're hired.
And if they turn out to be all talk, we'd can them after the first month. Hasn't happened yet.
Now, for a senior role, I'd be choosier, sure. But to discard someone for not knowing an arbitrary piece of software or bit of theory? Baby/bathwater.
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.
What's wrong with asking that? Both Excel and Acrobat have built-in encryption capabilities. There's nothing ignorant about considering whether the built-in functionality is sufficient.
Awesome, busted out laughing!
I'm not going to write "THIS!!!" because I really hate this neologism, however that's exactly the sentiment I have: This is exactly correct.
Very, very few job listings these days show salary expectations, so it's easy to apply for some nice-sounding position only to find it pays peanuts. So it's easy to not bother unless it looks really interesting.
If companies started advertising what they were really willing to pay for a position, they'd likely have more people looking at these positions (since they can compare with their present paltry salaries and jump). As it is, they seem to think we should just be happy to have a job, any job, and that they're all the same.
I actually like asking those kinds of questions. I look at the resume for a skill they say they know, then ask the most basic question I can think of about that subject. For example "I see here you say that you have experience with Cisco Networking equipment, please describe how you'd login to a switch and elevate your permissions". If you can't answer that off the top of your head, you've never worked with Cisco equipment (or it's been so long that your experience is probably worthless). For database work then yeah a select statement is a good choice.
Why would any senior developer/architect need to know the specifics of encryption? That is a specific skill, not a general one. And, if they need to know the specifics, it's a Google search away. Yes .. I do. Because I've had to do it before. Many years ago when I didn't know what it was and had to learn it. Now I can use it. Did you know everything the first day you started working at your company, or did you have to learn some of the things you are doing now???
Stop looking for specific skills and start looking for smart people. Your questions might find someone very skilled in what you need now, but what about next year when something new and improved comes along??
Someone who is smart can learn what you want them to know in a couple of days, encryption just isn't that difficult. Especially if you already know it and can sit down and go over it in the 30 minutes it will take for them to get the basics. Instead of looking for short-term solutions, look for long-term employees, people that are self-motivated to learn new things, and capable of learning new things.
--- or ---
You need a better job description that specifies specific skills you want. And the balls to ask a few questions at the beginning of an interview, and then show them the door right away if they don't have what you specified in your request for applicants.
Either way .. it's your fault you aren't getting the people you need or want.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Coming from a position of diverse experience on the matter of communication in interviews along with concise communication between professionals who have either come up in education and experience (or both) in two different generations or whose experience is in differing, but compatible areas such as web programing versus old school (mid 1990s) CGI web programing , not to be confused with computer graphics, I am referring to the period terminology for web to credit card transaction mechanisms.) or C ++ application programing versus embedded application C implementations, in an interview conveying to YOU the interviewer, the breadth of my experience and having to guess your particular areas of expertise so that I can speak your particular dialect of terminology to answer your test questions and not make the interview questions needlessly long, is a daunting task of communications ninjutsu to put it mildly. It is hard for me in interviews due to the fact I am beginning my graduate level education, and have taken two different tracks in my education, Software application programming and Electronics and Electronics at the bachelor's level including embedded systems, microprocessors, satellite communications and different kinds of encryption including Public Key Cryptography, AES Encryption and I did quite a bit of elective work involving quantum encryption and I will tell you what I spent half of my time on Quantum encryption was showing how many ways the human element and security weaknesses in the hardware that is not guarded along it's entire length.. can be defeated by a "Man in the middle" Large pulse attack which, while not disrupting the entanglement Alice and Bob see, can still see what the differences are between the actual bits being sent by being able to determine the orthogonal configurations of Alice and Bob's optical hardware. (I had a series of long interesting discussions on the feasibility of this with my professor who had spent time in the Navy working on such things and he was able to agree that there are indeed vulnerabilities that the designers had not thought of.) I find that in an interview it is surprisingly difficult to convey what your abilities are, what your experience encompasses and get into enough technical detail that the interviewer is on the same page, without them jumping to conclusions such as me making things up, or just coming off as plain arrogant. (I am not judging you, it is just with generational differences and having worked in a lot of different knowledge domains, You would be surprised how many things have the same basic underlying principles, mathematical patterns and even sometimes are called by the same name but in two different domains have such a different industry jargon associated with the two separate fields that someone such as myself in electronics and software programming still occasionally feels like I need some sort of lexicon to make sure that both people having the discussion are on the same page. I say again I am not judging you, but everyone has different sets of experience and skill sets and in a particular job that is either a tremendous asset or a liability.) I really feel that this question of yours ramoneThePoolGuy, would be better if it were two way, because I wonder if this isn't something that would be served by reading Dilbert, particularly the "Step one: Identify the problem" series. Just that title is a great reminder to never take anything at face value and that brings me to this point. I don't believe that anyone should be judged as not intelligent or unskilled, especially in a technical field, just by asking questions. You commented that when you asked the interviewee the 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?" and the person started off by asking me if it was an excel file, a PDF etc.. which I can see why you judged as an inexperienced person trying to throw out jargon, but understanding his "angle" on the problem might have been tell
Do this and you will be successful.
What mythical company completes the business requirements before the project begins?
Given you're asking such simple questions in an interview I'm now under the impression that you're not very good at what you do either.
The entire industry is bloated with unskilled people. Some kid learns how to do a pivot in Excel and they suddenly think they're gods gift to computing. Below that are many times the amount of people that think knowing where the device manager can be found on a windows system makes them an expert.
Same goes for the older techs that think 20 years of experience is the same as actually knowing what you're doing. Just because you've been doing something for a long time doesn't mean you're any good at it.
In my estimation, less than 1% of people that work in the tech industry are competent and 99% of those are belligerent and nearly impossible to work with.
Ask the question : What do you do in your spare time?
If the answer is anything other than "I spend all my free time learning new tech" then don't bother because there are people that *do* and they have names like John Carmack.
A good tech is a computer scientist and I'd expect them to be as proficient in their field as a brain surgeon is in theirs and I pay them accordingly.
It used to be a mail merge that was the "I AM GOD" skill to have. A pivot? I would have thought it would be a linear regression or something, (A regression is actually really awesomely useful compared to a pivot or even a mail merge, but I guess it depends on who is asking too. Just so long as the kid doesn't refer to the pivot as "An Pivot". If he does that then he qualifies as "An hero".)
I see where you are coming from. You are right, you can't tell from just their resume if they are going to be a good fit. You also can't tell if they are a good fit just because they are good at coding on a white board. Anyone who has studied pedagogy (it is a lot more interesting than it seems) that there is no shortcut to finding a good candidate.
The questions that are asked should be specifically tailored to actual work that they will be doing. Companies should be courting college graduates in the hopes of growing their skill set and and growing their own senior programmers, rather than poaching from other companies. You can still verify peoples tenure and job by calling their HR office. You can have them answer some architecture questions (if its a senior position), but for god sake don't lower the profession by asking a professional to answer cs 101 crap; There is a good chance they have not had to use some of it in over 10 years.
The skills that make someone good at white boarding code problems are not the same skills that will make productive programmers (google even admits this). I wan't to know if a person can do x job, therefor I am going to see if they are good at y even though its not related to x...
A person that can't write a for loop, would not be able to carry a discussion on programming with a tenured programmer. Hell, I can't even get half the people I work for to understand what I am doing let alone a novice.
I laugh at inappropriate times.
((NumDevelopers - 1) / NumDevelopers) * 100
Car engines use thermodynamics, but asking a thermodynamics question in an interview for a truck driver would be similarly irrelevant.
Learn to love Alaska
So? I've been programming professionally for 18 years now and I couldn't answer that either. Why? Because I have never, ever had to deal with encryption code.
Was "knowledge of public/private key encryption" listed in the job requirements?
Jobs don't pay fixed amounts - the pay varies based on the candidate. Companies, OTOH, have discoverable reputations as to where they pay relative to the industry - though you have to be careful, as that can vary by pay grade. And for sure the first conversation I have with any recruiter includes telling them m current comp, so that we don't waste each others' time.
Socialism: a lie told by totalitarians and believed by fools.
I grok the snark, but in my experience people who take their own initiative on learning and personal development gain 10x more than people who get sent to some boot camp or seminar on their employers dime.
False dilemma. I take lots of initiative to learn new stuff and my employer reimburses me for the classes and books.
Gee, it's almost as if I was lampooning that very concept...
No, your post was not arrogant. The questions that you asked in your interview seemed very reasonable (as part of a larger battery of questions). My response was not directly pointed at you, but at the software industry, and its lack of overall professionalism.
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.
You are right, it does limit them. They would probably be a decent programmer, but maybe not the best lead programmer. Why is our industry so special that, "just being a paycheck" mentality is not an acceptable as it is in just about every other industry? The software industry is permeated with this mentality that we have to go home and work on our own github project and stay up to date with the framework of the month even though a lot of the code we write is really mundane. Is funny that a lot of interview questions are about algorithms and memory structures when those types of things have been abstracted away in many of the frameworks we have to use.
I love to program, however my skills have been eroding year after year. I don't study algorithms any more, I barely get to have fun with any good problem solving (that's why we use to love it?). I am just trying to beat this new framework into submission so I can hit some crazy deadline that the US and India team are loosing sleep over.
The IT field disgust me. Who cares about a field that does not have room for its older workers? We are telling our kids, and the kids we mentor not to go into IT/CS. CS is a awesome tool, but it's a bad career. One of my old shops was full of newly minted graduates in CS EE who were making freekign web pages, what a fantastic wast of human potential.
I am out of time, I really like how you run things. Maybe if everyone else did the same you would not be in a bind for new talent
I laugh at inappropriate times.
Most people can learn how to write a program that works. Few master design. Paul Graham wrote a great essay on design that captures what I mean: Taste for Makers. This is crucial because, as Brian Kernighan said, "Controlling complexity is the essence of computer programming."
I've worked with just a few web programmers and interviewed just a few more. But in talking with friends and coworkers, reading articles, and in general just living in America, I get the impression that a sense of design is not a prominent part of American culture. In general we think that bigger is better, newer is better, and expensive is better. In general these are really bad criteria.
Then again, maybe it's that people can't even program. Jeff Atwood tells about how many programmers struggle with even simple FizzBuzz Questions:
Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".
Book learning? Tons of it! Street smarts? No so much.
I object to power without constructive purpose. --Spock
Funnily enough, most C standard library address resolvers can handle IP addresses as actual 32 bit numbers without the octects, which is an occasionally fun party trick.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I've met a lot of "meh" ones, who can kind of get the job done but obviously don't care about or enjoy programming. It was just a high paying career that they could get into.
I've met very few people who do it because they really enjoy doing it and are constantly being driven to learn. They usually get bored at a company within two or three years and move on.
I've met a lot of bad interviewers too, who obviously have no idea how to conduct an interview or what they're looking for in a candidate. They tend to jump on the latest interviewing gimmick bandwagon, whatever that happens to be, without really understanding why that gimmick is supposed to get results that are better than random. Most of the interviews I've seen could have just as easily flipped a coin and had an equal chance of getting a good developer.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Yeah, last time I was in your position I ended up hiering people applying for senior developer as UI designers. they sucked at that too. good programmers gone extinct a long time ago.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
Do we ask engineers to play with toothpicks and tape to build a bridge to assess their worthiness?
Having recently been through an interview I can tell you they only stopped short of providing the toothpicks. I was given diagrams of the the plant I was to be working with, detailed technical specs and then asked to design some theoretical system (which they already had in place). They then asked some very VERY specific questions about some tiny parts of the plant. Best part about all of this is that it was a position for a generic instrument engineer but they asked all very specific questions about a tiny subset of the field which didn't immediately match the job description.
So yes, engineers are treated no differently at interviews than programmers.
I am a highly skilled engineer with over 30 years experience. I once had a headhunter call me and want me to interview for this "wonderful job" at a major company. At first I wasn't interested (I already had a great job) but I finally agreed to an interview out of curiosity. One day, while running errands in my car I got a call from the HR hiring "screener" at the company who wanted me to do an on-the-spot interview over the phone to see if I was "qualified" enough to merit a real in-person interview. I reluctantly agreed to answer a few questions. He proceeded to ask a bunch of questions about algorithms I haven't thought much about since college (i.e. bubble sorts, tree balancing, etc.). He wanted me to basically quote him coding syntax over the phone as if I were typing on a computer. I'm sure my answers didn't sound the greatest on the other end of the phone. What a joke! He ended the short conversation probably convinced that I don't know how to code even though I could probably write better C++ code in my sleep than he ever could. I never heard from them again and certainly have a bad taste in my mouth about that company (even though I'm sure there are lots of really smart engineers working there).
On the one hand, I kind of agree, but on the other hand if the problem is to transmit a file securely your first thought really shouldn't be what kind of file type it is. I might never have asked that question, but given such an answer answer I wouldn't hire the guy. I cannot know what the exact problem is, I don't know him after all, be is either missing some very important concepts or the ability to connect the dots.
It depends on what is behind the question. I would phrase it like this:
An attacker can packet sniff and certain file types have a statistical signature that can be fleshed out of a frequency analysis of the packets being sent and all things being equal will show a certain type of curve on a histogram. It can be hard to believe in an intuitive sense, that a histogram can reflect the actual informational pattern of a particular type of file sent over and over but it does, and over time, given enough captures this can defeat even carefully chosen cryptography algorithms. The interviewee is very smart if the reasoning behind his question is with a view to blurring the lines between different file types being able to be deduced over time by use of a rich data capture, frequency analysis and use of a histogram. He did also say that he was interviewing for a senior position, so I would expect him to be expecting that level of sophistication. One could make the argument that asking what type of file type is being sent is irrelevant because the assumption is that if you encrypt something that no matter what it is it is equally unreadable, but that is unfortunately not the case. Most people assume their windows password is secure, but you can download a program that gives you a boot cd that will give you all of the usernames and passwords on a system in less than a couple minutes. Breaking hashes is not nearly as hard as it once was and a senior level applicant that I would hire would be cognizant of that fact, or I wouldn't hire him. I would also pay such a potential employee higher than the average rate for the type of work he would be doing, depending on what their credit report says, what their previous work history says and what their references say about what kind of worker they are.
Such a worker could make a point by packet sniffing the network and then emailing the contents of an email the hiring manager sent out after the interview back to him from your personal email address, and it might be surprisingly easy to do, but that might be about as useful as stealing a bus to try to demonstrate your ability to be a bus driver.. might not end well.
this sounds more like a poor quality interviewer. incidentally the one asking the question about the file type was at least intelligent, if it was a pdf or excel file you just use the builtin encryption options as anyone that thinks they can create a better one themselves is either in the top fraction of a percentage of security developers or they are simply too dumb to know they don't know enough. If the developer was applying as a security dev then these questions might have been more relevant, I expect an architect/senior dev to take advise from experts in their field and be able to integrate that advise to create a solution, I don't expect them to know everything.
Oh no it's contagious! I know that it does happen in other industries, I just don't think it is as prominent. Part of the problem is that software is not as regulated as other traditional engineering fields. I am guessing that civil engineer managers don't have to wade threw so much chaff. Then again, I think its ridiculous that they want people with engineer level credentials to work on mundane operational business software. Anyone with a computer is a programmer in an abstract way.
I laugh at inappropriate times.
Besides the point that goats are kindred bearded spirits, I find their ability to scream like humans appealing. Is it bad when you get to a point in life where you start to seriously consider going back to farming? It just seems appealing to have a job where you can work hard and feel like you accomplished something. I could have been a master goat herder / cheese maker or something...
I laugh at inappropriate times.
I'd say a reasonable use of SSH and not handing your private key to people is a pretty important fundamental, for anyone touching a nix environment...
The problem with slashdot is that most of its users were bullied and stuffed into lockers as kids!
This "hiring" manager sounds more like he is looking for a reason for being able to hire an H1B. There is enough people here that have pointed out some very valid points as to the lack of the interviewers skill in interviewing for developers.I would say to this person - learn MORE about what you are interviewing for and what specific skills the developers need for the position and make darn sure that is what is in the job posting! I've interviewed for many developer jobs where the job posting and the interview questions were polar opposites! The asked for one set of skills in the job posting and then asked about a completely different set of skills in the interview. I chock that up to cranial rectumitus syndrome!
The Truth is a Virus!!!
I second you on that point. Too few devs are up to date, even amongst graduates from 2010+. But there is a good certifications (namely IEEE CSDP) that tells you that someone at least knows the best practices in software development and that this person is engaged in yearlong self education in the field. I passed the test and believe me, its a full 3 hours of brain f***!
- J.P. Universe laws are such that we perceive them because if they were different, we would not be there to witness th
... 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....
When you are looking for people to join your team, the process usually consists of asking the candidate questions about the technology you are currently using. That's the wrong approach, unless, of course, you want to lock yourselves into what you are doing now.
.
What you should be probing is how well a candidate is able to learn and apply new technology.
When you are interviewing, you are looking for a candidate to help you move into the future, not stay with what you have now. The questions you should ask need to expose how a candidate learns and adapts to new technologies and the application thereof.
If you ask the wrong questions, you'll get the wrong answers.
and your HR department is paying "competitive wages" at the 50th percentile?
Let me know how that works out for you.
I'm reading a lot of "You can't know everything. I've been at this X years and I've never had to learn the particulars of how to encrypt anything! I'd learn it if I had to." in these comments.
Any application that deals with data should be built with an understanding of when and how to use cryptography to protect sensitive information. They aren't, but they really ought to be, and I wouldn't hire anyone to work with me if they couldn't give me a high-level overview of the basic concepts of PKE. I'm with you on that, OP.
But in answer to the original question, I kind of have to agree with the more cynical posters. Good help is hard to find. I say this as someone who is trying to hire talented software engineers in LA (seriously, if you're awesome, email matt at gem.co) and has been disappointed.
Clearly, an engineer should not take a senior position of a job he has no knowledge of. It's against the engineering code of ethics. However, not knowing something specific you think might be obvious, in a field with topics as numerous as there are stars in the sky, is silly. A worker is not judged by what they know, they're judged on what they can do. And what they can do is capable of changing with the application of learning.
Your man might not know public key encryption when you asked. The test of a man's character is "What did he do afterward?" If he immediately noticed he didn't understand a fundamental topic, and started researching it, he's a damn fine employee.
You may think you're looking at an employee who doesn't know fundamentals, but I'm doing the same thing. Looking at someone who doesn't understand the fundamentals of running a business long-term.
Stop asking the H1-b candidates and start asking US citizens. There are plenty of good engineers in the US, much more if you become less picky.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
There is a reason why people recommend having technical tests in interviews. Most interviewees fail the basic FizzBuzz test.
A lot of software engineers are bad, and this is much worse in everything related to web development.
I am a software engineer focused on low-level C and C++, and my company once needed to do some web development, a front-end for a web service we developed. We contracted someone with 8 years of experience in web development to do that, since it wasn't the kind of thing my company did.
I was in charge of working with the guy to ensure that his work met our specifications and that he called our web service correctly. The person struggled with such basic concepts as doing a HTTP request, serializing/deserializing data, and testing whether an RPC request went well. He couldn't understand our formal specifications and I had to basically write the code for him to show him what he did wrong and what he needed to do to comply.
Long story short: the level of skill an average web developer has does not meet the expectation we have of software engineering outside of the web development world.
I have been in the industry for 18 years or so and have worked for many fortune 100 companies. The answer to your question is "yes, it is this bad".
"Back in the day" we used to need to know several core functionalities to even just get a unix box up and running. I know many "enterprise architects" and they couldn't tell me anything about a tcp stack, how to configure a unix box for performance, how to pxe boot a system, how to patch a system, what mode to configure the network interfaces for LACP, should we use ipmp or LACP?, etc.
The only thing they do is certify a list of requirements to enterprise standards and drag and drop Visio diagrams to show how to plug things in. Then they turn it over to procurement to order it, then it comes in and admins are stuck trying to figure it out, working with vendors to install expensive software.. Which the whole process ends up taking a year or two in the "enterprise".
So if you want an "experienced architect" what you really should be looking for is a young smart kid and test him with a quiz to see if he's willing to work hard, stay focused, and has excellent troubleshooting skills with a verity of experience with various technologies. It doesn't even necessarily matter if the experience is in the technologies you are working with. Anyone curious, hungry, and willing to work hard is worth their weight in gold in today's world. Those have been the hardest to find, in my opinion.
Finding people to solve your riddles will vary in success, but the root of the problem is deeper.
Half of them are below average!
See office password protection. The encryption of Excel version before 2007 was laughably weak. The last such file I had to crack took minutes. And that's still what you get if you use the older file formats.
The encryption starting with Office 2007 is as strong as your password. It's still possible to break weak ones, but you need to apply a fair amount of brute force. Here's a typical cracking program. The way it advertises support for multiple cores and GPU acceleration is a clue it's not trivial to crack.
Four score years ago I was grilled on ISAM and BDAM for a junior programming job.. I passed. When I got there I found our they had a DBMS that used ISAM and BDAM, but the programmers only access the files through the DBMS. Totally useless questions. I have designed the architecture on systems highly reliant on technologies I only had a moderate understanding, No architect can be an expert on all the technologies in any type of system except the most trivial systems.
Oh, they never specifically reference the professor's own papers (as far as I've seen). But the topics chosen and the expected answers are highly biased by the professor's specific interests. If you are familiar with the writing professor's work and specific interests, you will do better on the exam. Even if the question appears to be asking a general question, the "best" answer is the one that deals with the professor's personal interests.
Note that this discussion is about PhD qualifying exams and not exams in general. Also, I'm not criticizing the whole situation as much as I'm making a general observation. Many students have trouble with this phenomenon.
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
Don't comment about stuff you know nothing about.
PKI is everywhere. You use it all the time and you don't even know it, obviously.
I set this stuff up all the time. From simple web site to ldap/dap authentication to some really big stuff.
When I hire even tier-1 type people (deal with idiots on the phone), they have to show me they can deal with at least a web server pki. They're a dime a dozen.
I have a feeling your asking for the wrong person. I know from experience you'll get a lot who are just unqualified even with a very good description. However I'm having no trouble with new hires and encryption. Key I think is they must know unix/linux. As long as it has that in the description I generally don't have a problem. If I ask for a Windows person, forgetaboutit! They're morons generally speaking. This goes right along with the general windows user - they're a moron too. I know, being captain obvious here. I bet I go through 100 windows applicants to find one that's any good.
So what's the threat model? To give a good answer to a security question, it really helps to know the threats to guard against. The NSA? If so, how many resources are they going to give to it?
Using MS Office password protection may well be a suitable answer, and it has the virtue of being fast and easy.
In any case, only a crappy interviewer would decide not to hire a software person on the grounds that he or she tried to get the problem details.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I think it's DOMAIN knowledge;
Casteism
Customers do not value...as in pay extra for....security and quality. If their sports score phone app crashes every five minutes they do not look for a different one or ask for the money back, they just restart it and do not even bother reporting this issue. Companies with massive breaches like TJX, Target, Anthem, or Sony spend a few millions on credit monitoring for affected customers and may fire a scapegoat, but other than that it is business as usual and people still do business with these companies. Microsoft even fixes massive security issues every single month requiring entire systems to get rebooted with the admin sitting at the console hoping that everything comes back up. Yet, nobody gets fired for buying Microsoft...and their licenses are not cheap! So what do you expect? Security and with that quality are not generating shareholder value. Businesses do very well throwing more features into their products at an ever faster pace (thanks to the mindless agile craze) opting to fix stuff later (which means not at all). Free email services have better security than most banking sites. How should a developer ever learn how to craft proper encryption, how to write good unit tests, how to properly comment code, how to deliver code that will pass all QA tests and user acceptance if none of that is valued? Why should a developer even bother with this when pressure to release more features is growing exponentially so that there is no time to learn and do things right the first time? All they hear is do something quickly and we iterate over it (which never happens). In your company the take on these things might be different and I applaud that, but you are the exception. My advice is to look for a developer who has some experience in the industry you are operating in. Hire one who has done a variety of things or has a variety of interests. That shows that they are open minded and not just a one trick pony. Whatever else they are missing you need to teach them, but start that off with explaining to them why this matters to the business. People are much more eager to learn and adapt different approaches when they know why. And no, this is not an excuse to pay them like a junior developer unless they truly are (recent graduates).
Well ...
"If Engineers built buildings the way programmers write programs, the first woodpecker that came along would destroy civilization!"
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.
Because writing code to do balanced (as opposed to unbalanced) binary trees is a "homework assignment" level question (with multiple branching decision points and subtasks) vs a "test question" level question. Traversing linked linked lists is an idiom that should be internalized if you're going to be messing with data structures and pointers.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }