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.
All depends on who you ask :)
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.
This isn't just about developers. The vast majority of people in any field are incompetent about key concepts of their profession.
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.
By definition, 50% will be below average. That's a good enough definition of "bad" for me.
Wow... Posted from mobile. Thumbs are poor typing instruments.
The only reason I know about it is because my teacher Dr. Klarner wanted to talk about it that day instead of numerical analysis.
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.
90% of everything is shit.
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.
of American workers are bad at what they do, which is why you should hire people with visas. Also, outsource as much as possible to India or China.
Also, be sure to hire enough African-Americans (not Africans) so that you can meet your quotas.
If your company writes software that implements public/private key encryption, then you probably need to find developers who understand the mechanics. On the other hand, if your company merely uses public/private key encryption, why would you need a developer to know how it works? There are many kinds of frameworks and subsystems in use these days. No one can know how they all work, and very few need to. You need to focus on the parts of the development ecosystem relevant to your development process.
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.
I think employers have unreasonably high standards. Software development isn't about knowing it all, it's about knowing how to figure it out. Don't ask me some obscure logical question...let me take an hour, and use Google, examples, existing code to figure out what's going on.
first
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?
shouldn't you be asking why your recruitment pipieline is so broken they are sending you
people on an entirely different level than what you are looking for?
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.
This is true.
Best answer: exact technical explanation you're looking for.
OK answer: I don't know, but I know where to find out.
Bad answer: Something he pulled out of his ass. Do not ever hire someone who does this.
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'm guessing most of the real good people are employed already, and will not bother to interview unless the pay is great. I do agree not all developers will know PKI, but and good dev will be able to look it up.
I'm kind of tired of everyone trying to only hire only the best developers. Most dev work is not that complicated, It's getting all the requirements and communication that slows everything down...
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.
Its a ridiculously high percentage if the people I've worked with over the last two years are any indication.
Change your ad to read, Senior Developer/Architect wanted, $250K+, must be expert in [list skills wanted].
Do this and I guarantee the quality of your applicants will increase substantially.
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.
Developers are specialized in different things same as scientists do not all now physics or biology. From what I am reading, it seems that you are trying to hire a developer that has a wide range of knowledge, high skillset, and security awarness. Well.. Try to hire a geologist physicist and micro-biologist that are all one person. Generalist developers that keep up with trends, software projects, and various CS topics exist, but I suspect there is less than 10% of them.
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!
I'm a Senior Engineer and mediocre developer. But I'm great at knowing my limitations, and I'm good at knowing when other people are exaggerating their abilities. So, I leave enough time, limit feature-creep, and make reasonable decisions. I stay out of the way of people who know what they are doing. It all works out.
--AC
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.
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.
TFA didn't specify if it was a position that specialized in security or not. If you're advertising specifically for a position that specializes in it, then being disappointed with people not answering that question is fine. If you're advertising for something else, then springing questions like that on them for fun, that pretty just makes you a know-it-all douche, and I'd rather wash dishes tan work for you.
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.
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.
You should jump into the pool for making such a ridiculous conclusion!
Email is a best effort UDP "like" service that older people tend to think "is now reliable, and can be made secure". I call BS in such thinking.. its lazy. Email was never designed that way and is fundamentally insecure.. even with PKI.. your keys can be Stolen! File transfers are only reliable and secure handled by a third party.. not peers.. this question is dumb. Asking for more information is the Correct answer.
Remember, you are dealing with a bunch of nerds and many of them are going to lack the social skills that work in an interview, but put them in a good office environment with the right tools and they will do well. I hope you can discern the difference in interviews, but it may not be easy.
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.
Just remember that 50% of Doctors graduated at the bottom half of their class.
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.
You're probably posting a low salary for your candidate pool, so you're dredging up all the candidates that are desperate enough to take it.
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.
Really? I knew about PGP 20 years ago.
I
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.)
Really? What if the document type includes provisions for strong encryption? If that's the case, then it could just be a matter of enabling the relevant bit for the document creation tool and then entering a password. It looks like the PDF standard includes provision for AES 256 bit encryption among other things so just telling acrobat or other app that you want an encrypted PDF document and then calling the other person and giving them the password might be appropriate.
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
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.
Demand a CS degree then train to fill any holes in practical knowledge needed for the job. If you want "just a programmer" don't be surprised if they don't under stand algorithms or even computers.
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.
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
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.
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.
Engineers just aren't what you're looking for.
Why the nonsense. WHY?
Sounds like you are looking for an encryption expert. What don't you start by describing the position accurately? Applicants can't read your mind. Had I applied, I'd be disappointed with the competency of management.
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
Okay kid, I'll see your Apple II and raise you an Altair. Now get off my lawn!
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.
SCP uses PKI, so... That's why you don't substitute PKI for SCP.
Well?
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.
The value of a good developer isn't what they know and can regurgitate, but what they can learn and how fast they can do it.
I didn't know 90% of the tech used in my current job, and in two months time I knew it all, inside and out.
Jesus Christ, no one needs to remember the best way to do everything. Give them a task, a computer with internet access, and an allotted time. Hire the person that can solve the problem by not reinventing the wheel, not the one that remembers every detail on everything.
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
If I do not know something, it is because it isn't needed for my job.
After 15 years of experience, I went to an interview where the the person hiring asked me to describe the layers of a network stack.
I haven't had to know that since school and all I could remember was maybe 3 layers.
But what REALLY annoyed me was that this was for a C#.NET job where we use the .NET networking methods. And this organization did not roll their own, so I was baffled as to why I needed to know that information.
I think some interviewers have a chip on their shoulder about what a "good" developer should know.
And I think all this "I cannot find qualified people" is because people looking have unreasonable demands.
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
Just like rockstars/pop-tart-divas, they come in, talk it up, sell some level of management on 'we must do project X in ', throw some crap class-ware together, ignore correctness, and then leave it to the rest of the people to clean it up to make it usable.
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.
This is why I hate technical interviews where they want me to design something in 10 seconds. If I give them a different answer than they expect, I'm automatically wrong. The good thing is that I don't want to work with developers or companies that think this way. In one interview I was ask to design a web application to sell items. I did. Then I was asked to design the return of the item. I put a negative sign in front of the price. Commerce, after all, is ins and out being equal. Well, my interviewer couldn't understand how that would work. He was basically projecting his solution onto me, when it didn't fit, I was wrong.
Part of being a good developer is being able to ignore the specifics at the right time and be able to speak in generalizations. Sometime people work so long at a job or with a technology that they lose site of what is objective and what is subjective.
You had HR filter out anyone who didn't recently graduate university with a CS degree, or at least (insert ridiculous number here) years of experience, preferably at one company?
Try interviewing more candidates and loosen your grip on what's necessary to do the job. You might just find the stellar candidates didn't get a university degree, nor do they necessarily have 20 years of experience.
>The person started off by asking me if it was an excel file, a PDF
Just filter out Windows' programmers who do not think how to solve a problem, but which icon in some well-known GUI program does it. Windows leaves people brainless.
Maybe I'm working at the wrong companies but I am SHOCKED at how bad some developers are. I'm working at a 2 year old funded startup and just by playing with the URL (as an end-user) I can view other people's accounts (private information). I'm sorry but that is entry level shit.
Maybe you shouldn't be hiring if you dont understand the basics yourself. Asking a web developer how to encrypt and send you file that you can then decrypt ,and then stating that your concerned about them creating secure websites. Your comparing apples to oranges. A web deveolper isn't going to typically be worried about file encryption just the encryption between the application and the server. The database admins are the ones who are usually in charge of securing the files. Then the bridge between the two is the systems analyst and the guidelines they produce. To many compaines are trying to skip that analysts step and go straight from idea to deveolpment with no roadmap.
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...
I think the excessive use of H 1 B is to blame. Poor wages and working conditions tend to push the more talented and skilled engineers out of the industry early in their careers, leading to a shortage of qualified senior engineers.
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.
Some of the best developers I have worked with were unable to install av OS or even plugin a keyboard. They did however know how to code... But then again, they were real developers, not webpage kiddies. Why do people insist on calling something as easy as building websites development?
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.
Just look at the typical supporter of systemd. All they do is make personal attacks and act like children. Example from today:
http://slashdot.org/~Eunuchswear
Look at those systemd fanboi posts! Most of the replies are to someone that has the legitimate complaint about systemd's policy to drop stderr. Obviously, any old UNIX user knows why that is a problem. Instead of being willing to learn, systemd supporters like him lash-out at people that are trying to help.
seems like a pretty straight forward question...
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
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.
The funny thing is I've seen this with only specific parts of the STEM world, more particularly on the technology and engineering side.
On the science side, things can be so specialized and detailed, no one expects anyone else to have much background. People are hired with the expectation it could take 3-6 months to get up to speed, and a year before a chance of papers start coming out. Usually once you make the jump from grad school to another job, which has a high chance of being somewhat different, future potential employers will notice you have an ability to learn quickly and work in a science environment.
On the other side, engineering tends to be a mixed bag. I've seen interviews that grilled to very gritty details about various aspects of something, which is not surprising when some work has a lot of subtleties that take experience to learn. It can even be mixed within the same person, as I've seen some that have biases that will grill potential hires with engineering background, but not so much with someone that has a science background expecting them to be more likely to learn. Which seems silly to say the least, because there is a lot of overlap in technical skills and work used by people with "engineer" and "scientist" titles, and usually both have to adapt to rapidly changing technology.
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.
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.
That's one of the big reasons that I left and went into "real" engineering: the techies may think that the systems that refineries and chemical plants run on are quaint and behind the times but it has been refreshing working on established systems and tech that has been refined over long periods and doesn't change when the "new hotness" comes out several times a year.
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
It's a normal issue if your candidates are "pre-filtered" by HR. What most companies do is they have HR do a research on salaries. And they typically come with somethig like "Software Developer" average $80K, maximum $120K, "Senior Developer" average $100K, maximum $150K and so on. Then they start thinking to not pay the maximum "to save costs". The line of thought is - if someone is working well for $80K average, we don't need to pay $150K. We'll get someone who will learn. Yet we want the room for some of the best people and we'll keep maximum at just 10-20K below maximum. Or maybe even at the maximum. Hence their salary range is set. What's missing in the picture is that those who are super good and super productive perform at 10x those who are rated. They do not want to stay at $150K and are trying to figure out how to make more. As such, they cofound or work in startups, go into consulting or do whatever it takes to get roughly double that amount. They know that they produce 5-10x of many others who make close to the top of that salary range. So they don't see a valid reason why they should not be compensated at least 2x of that. Some companies, mostly in financial and investment sectors realized this, and they easily adjust top salaries and bonuses to compensate for that. As such, they usually get some of these top people. Yet, those companies that try to stay with keywords "competitive salary" will never have that chance. They are simply not paying enough to be able to keep such people. More than that, the way their HR and management works is that they don't look for signs to increase salaries. Instead they simply try to avoid such conversations. This results in even perfect candidates trying to learn as much as they can, ramp up really quickly, become extremely valuable and leaving shortly after just because another company finally decided to pay $10-20K more. Meanwhile, the current company is at a loss of slower productivity due to hiring someone new. This pretty much happens everywhere.
yeah, why would anyone take a while to recall material they haven't needed in 10+ years and think through it a bit? why is it superior to regurgitate an answer because you last thought through it in the last few months? how many linked lists have you reversed today?
What was the comp package? If you pay half of what the going rate was then don't be surprised that you get what you pay for.
There is a reason that tools are easier to use then build.
Since companies have stopped funding Basic Research, why would you think people would continue?
Why would you expect people to be knowledgeable on things unrelated to their job?
What's next, a quiz on the physics behind chips?
Seriously, how was the ad written? Was it a laundry list of technology and years or was it asking for problem solvers?
You need to flip the script. Rather then ask them about random spit, Ask about their best story.
Of course this does require you to learn something about what they've done.
But since this, presumably relates to what you are doing, it might actually be useful.
BTW, simple PKI is a joke for security, it's a MITM attack waiting to happen.
There is no reason to believe the channel between Alice & Bob is secure!
In fact if you look-up MITM PKI is the example given!
A little bit of knowledge is a dangerous thing.
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'm always interested in opportunities: Regarding encryption, I picked-up Bruce Schneier's Applied Crytography first edition (the blue book) back in early 1995 and practically inhaled it again and again.
I don't at all consider myself an expert in info sec. but damn it was such a interesting book...
If one line of questioning does not work, try something else.
For each direction, push the balloon until you reach the limit.
Ask the person if there is a direction he/she would like head in.
Often the interviewer learns something as a bonus.
After you are done, look at the whole result and decide what you have.
Your process stopped before you did even the encryption direction justice.
The guy might have been thinking aobut something you never considered about protecting certain file formats.
In my experience, all developers are bad.
Their designs have problems,
their use cases are full of stupidity,
their comments are full of spelling errs,
their code is confused,
their documentation is about something else.
However, that is on an absolute scale.
On a relative scale, the team they are in usually determines how bad they effectively are.
In other words, since you know so much in this area, you balance their ignorance,
so hiring them would create a more complementary, better team.
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
As other people have said, you are asking questions that involve a very specific skill set. What you've described, I could use Google and figure out in 30 minutes (having done that the first time) - I certainly can't tell you that in an interview. With Public/Private key work, I find that I use the information ONCE to build the routine/library and never look at it again except for simple maintenance.
Things I would expect a software engineer to know during an interview:
1. Design Patterns
2. Data Structures
3. How to build an algorithm to do something.
4. MAYBE SQL depending on the position for which I was hiring (mainly because it is ubiquitous in my field)
If I needed something more specific than that, I'd put it in the job reqs for what I was hiring. Otherwise, I'd assume that if the applicant is smart, she can LEARN the tech. After all, in Software Engineering, you have to be able to assimilate new technology CONSTANTLY.
NOW, all that being said
I am worried at how many applicants have difficulty writing a "FizzBuzz" routine during an interview.http://ask.slashdot.org/story/15/02/13/1612226/ask-slashdot-what-portion-of-developers-are-bad-at-what-they-do?utm_source=rss1.0mainlinkanon&utm_medium=feed#
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
I have spent my 20 years in software development always thinking I was the worst of the worst when it came to technical knowledge but I know in great detail how public/private key encryption works and have had to actually implement a few systems using those technologies and defend them to clients, hence having to whiteboard them in great detail so a project manager who is not an engineer could fathom.
I may have to rethink my position as the very bottom of the barrel....
Also, 3.) Ensure all scope changes are properly documented through change orders, *no exceptions*
I would say 99% of the Rock Stars are actually bad developers.
They always say: "Yeah! I can do that!". Then they make a heroic effort to get the show running leaving a pile of unmaintainable crap behind. And that unmaintainable crap may be over-engineered garbage, or something that's just slapped together no respect for layers or design. But either way it's crap.
I see crap developers at all levels, but the Rock Stars are the worst because they should know better.
... 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
The OPs example of grilling a developer about PKI (which honestly isn't widely used in the industry) is a poor one.
I have a better one.
I worked for a company in the Chicago area that spent *two years* looking for a java candidate.
The test we issued was "Write a java program, using any IDE you like, which can "randomly pick a name out of a hat".
How you decided to implement the "hat" class was up to you.
Essentially all applicants, applying to a Java position, could not write this simple Java program.
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.
Oh, and FWIW, they used a large C++ code base that processed incoming data at high rates. They really did want people with enough of a clue to understand how linked lists worked and how to traverse/manipulate them without fucking up. Then the interview group would discuss with the candidate about what he did (on the whiteboard), hint at errors, etc.
But seriously, this is second-year CS degree stuff. Anyone with a BSCS or higher degree should fucking know linked lists work. Reversing a linked list is the kind of thing that would be a test question, not a homework assignment. It's like asking someone to do long division on paper. We weren't asking more complicated shit (that we didn't even use anyhow) like sorting algorithms (I can only write binary search and bubble sort from memory), or like I heard one about one interview somewhere, balanced binary trees.
This is honestly a really good point that I did not think of.
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.
Knowledge of and experience with basic cryptographic primitives *should* be as widespread among software engineers as knowledge of and experience with certain statistical methods *should* be among scientists. Several decades ago neither of these things was as important and basic to the respective fields as they are today. But times change.
Sadly, in both cases people tend to rely on HOWTOs and cargo cult incantations, without developing a true understanding.
If you can't do RSA or DSA with pen and pencil, then you don't understand basic public-private key cryptography. It's such a small, inconsequential, and seemingly useless thing to do, but it's the _kind_ of thing you *need* to do to truly understand how these things work. And even if all you'll use are off-the-shell components like OpenSSL or GnuPG, it's something you should have done at least once just to have that base for understanding problems later on, as well as judging the competency of others you may hire or work with.
However, most people don't have a real love of learning, and that's the kind quality somebody needs in order to have the motivation to develop fundamental skills. Most people have a love of tinkering and using new toys, and mistake that for learning and skill development. But if you have no clue how deep the rabbit hole goes, even if you know you'll never learn the details of a field, then how can you be expected to make sound and rational judgements about the tools and software you use?
We all stand on the shoulders of giants. We all have our specialities, and we can't know everything. But you shouldn't be standing on shoulders that you have no basic understanding of. They could be the wrong shoulders entirely and you'd never know.
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.
Crap, I meant to reply to the other reply. But knowing "SELECT field FROM table WHERE condition;" probably put you above 90% of their candidates. And if they only had 10 or so candidates to begin with...
Security is its own specialty and is generally a subset of a broad education in IT proper, not software development. Very few schools would teach you even the basics. CS just isn't security on its own. If you really want to learn something CS specific take this (CSSLP - Certified Secure Software Lifecycle Professional), it will make you more knowledgeable in secure coding than 95% of all programmers regardless of education or experience. It is also quite a bit harder than anything a recent CS grad would have encountered, that is why ITSec is so much fun.
Really? As a compiler implementer with 20+ years experience I have better things to use my bandwidth on
than cryptography, which is totally irrelevant to what I need to know. If it becomes relevant then I'll learn
about it.
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.
Hey, you can learn a lot about a chef by watching the way they make gravy...
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
I've met people like you. You have no idea how much depression and anger you cause.
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
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.
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."
What are you people talking about? This is a perfectly accepted, and widely used, model for employee training and professional development, it's called On Their Own Time, On Their Own Dime (TM).
You get it. There's 100 correct answers to his encryption question. Simpy using gotomypc and pasting the file on the desktop is a correct answer.
Telling your applicants to research PGP before scheduling an interview?
I've got 15 developers on my team - it took me 9 months to find/hire them (in Toronto). The boss bitched at me regularly, but we ended up with a fabulous team. Why did it take so long? Because many failed the types of question you asked. But failing that type of question can be overlooked if: 1) The candidate said 'I don't know', which is waaay better than bullshitting, AND 2) The question wasn't directly related to the work they were going to do.
But I like asking this type of question because it tells me the breadth and depth of the candidate's knowledge. If you're looking for top guns, keep looking. You'll interview twice as many candidates, but get 10 times the productivity (assuming you don't accidentally hire prima donnas). Good luck, and like another poster intimated - sharpen the job description! This raises the odds of finding someone you like in the first 10 interviews.
When was the last time you asked your car mechanic how to rebuild an airplane's turbine engine? Or the last time you ask an airplane mechanic how to rebuild a Black-hawk helicopter rotary assembly? Or asked a Black-hawk mechanic how to do a front end alignment on a Ford pick-up truck. That 20+ year programmer gave you the exactly the correct answer and I bet a hell of a programmer.
The problem is that many people simply lie on their resumes. Others have a decade or more experience mainly in office politics and taking credit for others work. About 80% of candidates I've seen couldn't even write a for loop to sum a sequence of numbers.
If you don't provide training for your employees, you are the problem.
Really? A graphics designer working on a computer should know public key encryption (information security) and the OSI stack?
The age of AI sentience cannot come soon enough. Once we are at that stage, folks will have the exact candidate they want with just a few mouse-clicks. How different people, working in different capacities (like left vs right brain) are supposed to have the knowledge and recall of a god is beyond me.
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?
How do I know that the public key I receive is really your public key?
..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.
Because in real Engineering new usually means unproven which CAN KILL PEOPLE. The cavalier attitude of many of the code monkeys I have met would never make it past their sophomore year in real Engineering, if they did not wash out. Coders working on critical systems terrify me.
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!
Go fuck yourself. The questions you asked are inane. The problems are already solved. If you requested politely, perhaps the interviewees could have steered you to some web pages explaining this or that algorithm. But you should pay for such assistance, not have an outsider solve your problems for free.
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
...says every developer ever.
Do this and you will be successful.
What mythical company completes the business requirements before the project begins?
Do you hire remotely? :) I can tell you a lot about assymetric cryptography and deep internals of OpenSSL
Speaking in defense of development staff.
I have about 30 years of IT experience, my last roles as Director and Senior Architect with about 20% of my time doing demo code and helping management understand the technology.
I will say this about developers: More often than not - no matter where I go and who I deal with around the world - whether you're an Indian developer, from Romania, Russia, a former hacker form the Ukraine, a corporate drone type in China, a former employee from Seattle and Microsoft, or a guy from Arkansas - my experience has been that about 10% of developers are truly bad at what they do - BUT I learned a massive lesson - THE INDUSTRY AND WORLD NEEDS THEM!
In my experience, THESE bad developers RARELY effect the end product, what truly effects the end production is simple mismanagement of the organization - which almost felt intentional at times.
I say felt because I have spent 3 years homeless, waiting for the Holodeck Programmer position to open up.
In any case. What makes an end product bad is a lack of awareness and consideration of the customer's needs.
Developers - working from bad requirements by analysts and project managers who work more to preserve their own jobs than they do actually being beneficial - do not seem to understand nor want to consider the various customers on a project and what they may need.
It's subjective, right? But developers are rarely treated 'as customers' - and it shows - because most people fail to take the time to 'get to know how a programmer thinks and works - and this leads directly to the poor implementation of the code.
The 'bad programmers' within a team make us laugh, smile, ease the work situation. Their lack of productivity or introduction makes us feel better about ourselves, they can frustrate us a developers, they can piss management off to no end with they way they work (or not). They are typically social clowns or the 'hot chick' programmer added because she wants to learn and male dominated programming teams need a woman in their midst.
What portion at like this? I'd say 10% maybe up to 20% if the unemployed and underemployed like myself weren't shooed at.
I am not the greatest developer in the world. I enjoy what I do. But I'm homeless because I care more about living life than I do perceived 'productivity'
I wasn't always this way. I had one consultant who we talked about for years after he left - for three months he took long lunches, hit on all the women at work, and quite literally changed code by adding 'spaces and tabs' throughout the code.
We laughed for years on that one.
And I took note on a more engaging and fun way of operating in life in general from that man. '
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?
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.
The number of web developers that can't explain the life cycle of an HTTP session, and the role cookies play in that is, frankly, shocking.
You seem to be asking for a high level architect that knows just a little bet of everything and can do overall system level designs. There are people like that, most likely gainfully employed and not looking to change.
The field in general appreciates depth (you're a crack Node.js / rails / SQL / kernel, etc person) and people with breadth are less appreciated by techies, but liked by upper level management (you).
Its likely that you did not make the position clear to the recruiter / sourcer, and / or the applicants did not understand that. I'm pretty much no expert on anything, but I know a little about lots of things. My value rarely comes from writing lots of code, but from knowing that if person A makes a little change in system 1, then system 2 will have to have person B fix this other thing, etc.
Dunno what to tell you other than to make it very clear what you're hiring for.
Gee, it's almost as if I was lampooning that very concept...
Perhaps you need to review how much salary you are offering for the position. You may only be attracting the worst because your pay isn't enough to entice those that know what they are doing to apply.
Those types of questions have only one purpose: to make the interviewer feel smart. I worked with a gentleman who had 30 years of experience as a developer, he ended up building an entire MES system from scratch, defining and developing an entire manufacturing process raw material to finished product, integrating it with complex ERP software and retail software, and ultimately setting the foundation for a hundred million dollar company that probably wouldn't have made it without his work. He had no clue how encryption works or what an IP address is, he would often call on us junior developers to do the most simple things to set up his development computer. Yet you would probably pass him up. Maybe it's you that's not qualified to be interviewing developers.
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.
no one uses their own "reverse linked lists" anymore. We use data structures from libraries to do it. This is 2015.
100%
Thank you.
I'm a mid-level systems analyst at podunk state university and not an 'architect' (whatever the hell that means nowadays) and I totally agree with you.
I'm sure the poster created his own encryption algorithms from scratch too. That always works out well.
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".
...until your CEO irrevocably commits you to integrating with a credit card processor whose "security consultant" demonstrates that same level of incompetence. Fun times.
Hear Ye... Hear Ye...
I did the first fucking interview of my life. And I asked the guy a question on something I read about yesterday. See slashdot I know more than the guy.
Oh get a life.
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?
Sorry to say, you are a bad interviewer. I have 10 years experience as a lead developer and have experience on both sides of an interview. A senior level developer with 20+ years of experience has probably covered virtually every aspect of software development. You expect them to memorize every concept that google can answer in 30s? I have 10 years experience and just got a new job. I dealt with interviewers like you and it frankly irritated me. I actually turned down second and third interviews because of exactly that type of question. I ended up with three job offers and took the highest paying one.
You are limiting your talent pool with questions like that. It may seem like a basic concept and, when you are in security, it is. But a highly skilled developer may deal with security only rarely. That doesn't mean they are bad at their job. You need to test for abstract problem solving skills and fast learning. The best developer in the world may never deal with the specific "concrete" concepts you require. But a good developer has a passion for learning (very quickly) and understand ABSTRACT concepts in great detail. They have BREADTH, and not necessarily DEPTH of the specific skills you need.
To test for depth means you, personally, tend to be a static thinker. Most of the top talent are dynamic thinkers; producing solutions that cover a massive array of concrete topics. A good developer doesn't fester on a specific concrete concept and memorize it. A good developer can jump in and out of a wide range of concepts. Perhaps never being able to recall very specific details but can pick up the necessary knowledge in an instant.
Do you want someone who can memorize crap, or someone who can solve problems?
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)
If you know the answer, why are you hiring someone to do it??
Seems like you have actually no clue what you need, and until you do, you'll just create more problems for others and yourself.
Btw, I can read from your post that you're probably a very technically-oriented person. Why are you doing the hiring?? You should assist hiring, not direct it...
Technical people are the absolute worst people readers you can encounter.
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.
Tell me more about these goat based home business opportunities. My Cousin has done will with llamas but I'm not so sure about llamas. They have an evil gaze. Goats I could deal with.
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?
...followed by...
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.
Let's look at the assumptions you both made.
His:
1. Excel's inbuilt encryption is secure enough.
2. He can communicate the password to the intended recipient without it being intercepted.
Yours:
1. PKI encryption is secure enough.
2. The public key your using to encrypt the message with actually belongs to the intended recipient.
How paranoid you want to be about these assumptions is left as an exercise to the reader.
I'll share some of my thoughts on the matter...
Public/private key encryption depends on there being no known solutions to certain mathematical problems.
The NSA have been busted trying to get algorithms with backdoors accepted as industry standards.
If I hack your CA and DNS your PKI isn't worth a pinch of poo.
A developer should thoroughly understand the environment in which he works. An architect on the other hand should know the general way a LOT of things work and how to specify to the developing team what needs to be implemented. The architect needs to have the ability to ask the client - "Why do you want that?" Because they may be trying to solve a problem unrelated to their "preferred solution". And an architect must know the technical limitations of the developing team and the installed equipment.
Maybe it is just as well I am retired.
I mock your lack of knowledge of balancing binary trees. Jeez, that's third-year CS degree stuff, man. And you've been working in the industry how long to not know basic third-year CS degree stuff?
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.
Your problem, Mr. Interviewer, is that you seem to think that you know more than you actually do.
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.
shut up, dumb guy
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.
This is the problem with bad interview questions. There's always someone (this time it's you) that says "Sure, maybe that's a bad question, but HERE'S a good question" and it's inevitably another bad interview question. First, your "second year CS stuff" question requires remembering a kind of uncommon data structure, then sorting out how to do something to it that would really rarely ever need to be done in real world applications (I read the example below, and it's hardly a universally encountered problem). To top it all off, I googled "reverse linked list" and got several hits with answers in a moment. Regardless of the actual content of the question itself, if you can find the answer in a search engine's top 3 hits quicker than someone can access their memory of their collegiate education, it's an awful interview question and you prove nothing by dismissing anyone who doesn't have an immediate answer for you, no matter how "simple" you think the question. (This is even further true because an interview environment is about the furthest thing as possible from a real development environment. Maybe the applicant just froze and drew a blank?)
tl;dr You're a bad interviewer, and your "point" is moot
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
Yeah, and that's bullshit. As an architect you'd better damned well know a lot about a lot.
Then again, you're probably easily outsourced so it doesn't matter.
If you offer terrible pay/benefits of course you're going to be stuck with the bottom of the barrel when hiring.
that aren't white males
... 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.
You must have at least version 19.63b of DNS-drop(b), the absolute minimum of 24 years of SQL-RA version 32.69b, and advanced microcode development with the Xylox-R package (minimum of 19 years with version 32 or 24 years with version 22+). Persons without *all* of these qualifications as an absolute *minimum* need not apply. Now you can say "but SQL-RA was only at version 31.1 6 months ago, how can I get 24 years experience in it" and the answer you get is "so you aren't qualified then, are you". Its very easy to pull requirements out of a book, and insist that those not meeting their standard simply unacceptable. What they are asking for is a bespoke suit from off-the-rack people (and everyone coming out of university is off the rack, and most people know most stuff). The idea of 'build to suit' is an abomination to them. They insist on bespoke or nothing. And then you get old geezer types yelping 'whut's wrong with all the kids taday?'
Based on the developers I've known and worked on I'd have to say about 50%. How representative they are of the rest is anyone's guess but one thing I'm convinced of is that, just like people in any other occupation, very few are anywhere near as good as they think they are.
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 actually worked on public/private encryption systems, I designed and developed one entirely on my own for a corporate client 8 years ago. For the last few years I have used such things on a daily basis to secure my own work (all quite automated). Even I could not answer the question of how it works. I knew it at the time I needed to know it, but given how easy it was to discover this information I saw no need to memorize the explanation. I couldn't even tell you exactly wtf the thing I was making was for, I just don't remember anymore. I don't go around remembering every little thing I do. Most of the things I've done I didn't already know how to do - and (side note) doing an IT degree wasn't about learning everything there is to know, it was about being aware of the fundamentals and learning how to learn (which many have been doing since childhood anyway).
Being a developer isn't a game show either. I've looked up a bunch of "job interview quiz" type things, sites that offer questions to IT employers to ask their candidates, and a lot of it seems to be about tricking the candidate and making them feel stupid.
There must be a problem in the IT world where people are saying they can do things but can't actually do them (Is that an actual issue employers face?) which is leading to these types of interview questions. I think these employers have their priorities in the wrong place. I don't have an answer for how to weed out such candidates, but I think a lot of good talent is overlooked with this interview stupidity.
If you want your employee to be good at something, or to do something a certain way, just tell them that's what you want. Just hire someone who cares to do that for you.
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.
I worked at a very large computer company for 17 years. I found that so many software engineers were incredibly stupid. Not just ignorant of the facts, but even after I explained the steps to do something in great detail, the very next time they had to do that procedure, they would have no idea what to do. Engineers from other teams would send me emails and instant messages long after I left the team I led because they knew that most of the people still on that team did not know much.
What is worse is that management liked and even promoted the morons. They were easier to manage and just said "yes" to everything because they did not know better. I delivered a long list to our personnel manager of the stupid things one of the people on my team did, including when she said she had run a test case successfully when it was unequivocally shown that she had lied about her work. She even started daisy-chaining power strips in the lab because she was either too lazy or too stupid to look under the raised floor for more power drops. Then when workstation computers would randomly power down, she blamed the contractor who worked in the lab. A few weeks later, this moronic, lying woman on my team was promoted!
It's a wonder how the multi-billion dollar company where I worked for many years can produce any working products at all.
Half of them are below average!
Maybe this applies to other fields, but after 20+ years of being at a university between undergrad, grad,and working at one (never teaching myself), and taking classes, sitting in on classes, and helping colleagues proofread tests & answers, I don't think I've seen a single one that references the professor's own papers. This includes everything from CS and math, to physics and engineering courses, including some physics courses where the professor actually did a significant amount of the work on one of the main topics of the course, but by that point there were review papers not written by the prof. The closest I've seen to a paper intensive "exam" is a couple profs who had students pick a topic, and do a presentation to the class on a couple papers covering the topic, in place of an exam so that students could discuss a variety of recent research.
I would agree with this *if* the first question the interviewee had asked was something like, are we developing an end to end solution ignoring any possible application level encryption, or are we attempting to leverage existing technologies first then wrap or manage that so the end user has a consistent, single method user experience.
I encounter similar problems when looking for reliable staff. I have managed large teams in the past and current run a small business where every staffing choice can make or break the company -- we're really small. The biggest hurdle when staffing for a technology position is to keep context clear. Getting a feel for the ability of the candidate to learn and grow is also a key element to watch for.
Public key cryptography to cipher a randomly generated symmetric key, and send that together with the ciphered data to you.
Can I has job?
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.
"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 would bake it inside a cake. Duh!
You can't know that your open source encryption software is safe either. Even if you compiled the software yourself, the most likely didn't compile the compiler yourself. And even if you did that, you didn't boot strap it by typing the machine code in yourself. You used compiled software that was most likely out of your control.
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).
The vast majority. If you are actually taking the time to find good hires, I would not be surprised you go through hundreds of pre-screened resumes, and dozens of interviews before finding someone decent.
And I bet you'll pay that guy the same amount of money all the other failed candidates are getting paid at some other place where the hiring managers are incompetent.
On the other hand, if you want to attract top talent, you can do so by posting a top-notch salary (with real numbers) in your job listings.
Well ...
"If Engineers built buildings the way programmers write programs, the first woodpecker that came along would destroy civilization!"
The Hole Hawg is a drill made by the Milwaukee Tool Company. If you look in a typical hardware store you may find smaller Milwaukee drills but not the Hole Hawg, which is too powerful and too expensive for homeowners. The Hole Hawg does not have the pistol-like design of a cheap homeowner's drill. It is a cube of solid metal with a handle sticking out of one face and a chuck mounted in another. The cube contains a disconcertingly potent electric motor. You can hold the handle and operate the trigger with your index finger, but unless you are exceptionally strong you cannot control the weight of the Hole Hawg with one hand; it is a two-hander all the way. In order to fight off the counter-torque of the Hole Hawg you use a separate handle (provided), which you screw into one side of the iron cube or the other depending on whether you are using your left or right hand to operate the trigger. This handle is not a sleek, ergonomically designed item as it would be in a homeowner's drill. It is simply a foot-long chunk of regular galvanized pipe, threaded on one end, with a black rubber handle on the other. If you lose it, you just go to the local plumbing supply store and buy another chunk of pipe.
...
The Hole Hawg is dangerous because it does exactly what you tell it to. It is not bound by the physical limitations that are inherent in a cheap drill, and neither is it limited by safety interlocks that might be built into a homeowner's product by a liability-conscious manufacturer. The danger lies not in the machine itself but in the user's failure to envision the full consequences of the instructions he gives to it.
A smaller tool is dangerous too, but for a completely different reason: it tries to do what you tell it to, and fails in some way that is unpredictable and almost always undesirable. But the Hole Hawg is like the genie of the ancient fairy tales, who carries out his master's instructions literally and precisely and with unlimited power, often with disastrous, unforeseen consequences.
...
It is not hard to imagine what the world would look like to someone who had been raised by contractors and who had never used any drill other than a Hole Hawg. Such a person, presented with the best and most expensive hardware-store drill, would not even recognize it as such. He might instead misidentify it as a child's toy, or some kind of motorized screwdriver. If a salesperson or a deluded homeowner referred to it as a drill, he would laugh and tell them that they were mistaken--they simply had their terminology wrong. His interlocutor would go away irritated, and probably feeling rather defensive about his basement full of cheap, dangerous, flashy, colorful tools.
Unix is the Hole Hawg of operating systems, and Unix hackers, like Doug Barnes and the guy in the Dilbert cartoon and many of the other people who populate Silicon Valley, are like contractor's sons who grew up using only Hole Hawgs. They might use Apple/Microsoft OSes to write letters, play video games, or balance their checkbooks, but they cannot really bring themselves to take these operating systems seriously.
http://www.cryptonomicon.com/beginning.html
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.
You don't think a developer should be able to send a file?
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; }
Encryption: Alice encrypts the text with Bob's public key. Bob decrypts with his private key (which only he has).
Authentication: Alice hashes the text and encrypts it with Alice's private key. Bob can verify it by decrypting with Alice's public key. Since only Alice has her private key, we can be sure it was encrypted by her.
You have an encrypted, non-authenticated message when only the recipient needs to be able to see it but the sender can remain anonymous. You can add a hash to the original text to ensure it can't be altered.
You have a plain text, authenticated message when you want to send a public message that clearly only you could have made.
Finally, we can have what you are talking about when you want to not only protect the text in transit but ensure the sender is who he says he is.
Right away... and stop filling out LCA's.