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.
And about half are above average.
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
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.
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.
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!
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'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.
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.
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.
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."
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.
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
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.
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.
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
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.
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.