A Response to "Crushing the Imposter Syndrome"
I came across a fantastic article on Hacker News called Crushing the Imposter Syndrome and I think everyone should read it. I have an addendum to make to it as it relates to my life and what I have seen in the IT industry over the past 16 years. Please go and read the article now, then come back and read this.
Back? OK, let's start.
I see imposter syndrome happening in IT quite a lot, but limited to a select group of people who really try to do a good job (e.g. solving a large problem). This is in contrast to the people in IT that are in it purely for the money and power or to sell something and then forget about that customer in the attempt to get a new customer. It possibly happens as much in other industries, but I don't know since I have only existed in IT (or the IT department of other industries). One big cause of imposter syndrome is the pressure put on IT applicants when searching for a job.
To cherry-pick a specific – recent – example, here is a job posting in Amazon for a Software Engineer III (I assume their highest level of a software engineer):
Basic Qualifications · Masters Degree Preferred; minimum of Bachelor’s Degree in Computer Science or related field, or 3+ years relevant work experience · 2+ years professional experience in software development · Computer Science fundamentals in object-oriented design and data structures · Computer Science fundamentals in algorithm design, problem solving, and complexity analysis · Proficiency in, at least two modern programming language such as C, C++, C#, Objective-C Java, Scala, Ruby, Erlang, Python, Smalltalk, or more · Proven track record of delivering complex systems and leading teams delivering mission critical projects · Experience of use of various system design models, e.g. queuing, messaging, web-services, batch/real-time, event driven
Reading this job description causes my imposter syndrome to (rightly or wrongly) flare up for the following reasons.
Requirements 1 and 2
Masters Degree Preferred; minimum of Bachelor’s Degree in Computer Science or related field, or 3+ years relevant work experience 2+ years professional experience in software development
I don't have a masters degree (only a bachelors) but I have 16 years of professional work experience. So it seems a masters degree is something that somehow puts one ahead of real-world professional experience. Oh, plus 2-3 years of software development experience. Does this mean I'm overqualified for their highest ranking software engineering position, or maybe that I have somehow failed and should be a manager or director by now? I don't know, but a masters degree requirement over paltry work experience suggests to me that they want someone that isn't me.
Computer Science fundamentals in object-oriented design and data structures
Object-oriented design and data structures is such a large body of knowledge that one can talk for hours about it… and then completely throw it out and then talk about the problems with it due to state and concurrent programming. Then it can lead me to talk about functional languages and how they could be useful. But in an interview, they are going to ask about some design pattern which I may or may not know the exact innards of at the moment and determine that my OO experience is subpar.
Put another way, is this employer expecting me to understand the difference between a hash and an array (as well as the pros and cons), or are they going to go straight to asking me how to balance red-black trees? If it is the latter, then I couldn't answer that because I've been out of school for over 13 years and that was the very last time I had to deal with it. However, if the company actually needed to implement red-black trees, then I would refresh my knowledge on it. However, in an interview, my hesitation or outright wrong answer on balancing red-black trees would be a signal that I don't know anything about OO-design, when in fact I do.
Computer Science fundamentals in algorithm design, problem solving, and complexity analysis
Algorithm design, problem solving and complexity analysis is also a large body of knowledge. Simply explaining what O-notation caused a bit of a stir on HN yesterday, and it was just one person's attempt to explain it. But to lump a complex and mind-bending concept such as algorithm design into the same sentence as problem solving and complexity is showing a lack of understanding by the person who wrote the job description. But in an interview, expect a question asking you to write some piece of code and then be asked what the complexity is. Sometimes that is easy to determine (e.g. a loop within a loop) but sometimes it is insanely difficult. But remember, 5 minutes per answer please. Chop chop!
Proficiency in, at least two modern programming language such as C, C++, C#, Objective-C Java, Scala, Ruby, Erlang, Python, Smalltalk, or more
Proficiency in two languages is not defining what "proficiency" means. I can write 6 programming languages very well, but I can read just about every language (even assembly). Does that make me a genius? No. It makes me recognize patterns. But can I write assembly? Hell no. Talk to a linguist, it's the same with spoken languages… some people can hear and listen in one language but not be able to speak or write in it. So what happens in an interview if you say that you have proficiency in Java but then they ask you to write an XML parser? Like me when I was asked it, I floundered because I don't just set out to write a functionally correct XML parser (note: it is very very difficult to correctly write a parser for XML). But instead I start to look like I am lying about my proficiency in the language.
I generally feel like I muddle along in the programming languages that I feel proficient in. I limit the use of advanced features of any language because I like to keep my code simple and easy to read for others (because I won't be around forever). Case in point, I rarely (maybe once?) use the
method_missing call in Ruby. I think it is magic and I don't like magic. I don't even like going near it, so I may not realize what some of the underlying aspects of the function are (I know what it does, but I mean the deeper knowledge of the method). Does this mean I don't have a proficiency in Ruby? In a way, I feel that answer is yes. And yet I am still able to write Ruby, or Java, or Bash very quickly and solve problems.
One last thing, because this really gets my goat, is when I state that I am proficient in Java and yet every question in an interview is how to integrate with Spring or Hibernate. I have rarely used these, but it doesn't mean I can't learn them. It also doesn't mean that I am not proficient in Java because Spring and Hibernate are frameworks. That's like assuming I don't know Ruby because I've never written in Rails. When I interview a candidate about their programming knowledge, I ask basic questions about the language itself (creating object, allocating memory, some basic operators) because I need them to be typing on day one. Everything else that is a framework or library can be learned in a day by researching it through Google.
Proven track record of delivering complex systems and leading teams delivering mission critical projects
I understand the need to hire someone with a proven track record of delivering complex systems but what does that actually mean? I have rarely met programmers that have delivered a system into Production (conversely, I have rarely met a system administrator or environment manager that has developed the software they are deploying onto the system). There is usually a number of gates in the software for delivering software. If by delivering they mean to simply write software that is complex, then by definition almost every piece of software is complex because it pulls in libraries with unknown risk that needs to be mitigated. So how does a candidate like myself field a question about this? Have I delivered complex software? Yes. Directly to Production. I've also been a part of teams N layers deep into the software delivery lifecycle that never even get a peek at a production-like system. But the wording makes it seem like I need to have experience building nuclear power plants and it scares me away.
Experience of use of various system design models, e.g. queuing, messaging, web-services, batch/real-time, event driven
To any programmer that is supposed of Tier 3 calibre, this is basically asking for experience in how systems talk to other systems. What is so complex about that? But where I feel like a fraud is that I don't know what type of experience or level of experience is required to meet this requirement. And, more importantly, it is not something that can be quantified by asking for X years of experience. It simply cannot be quantified. So all I can do is talk about how I have used Web Services to build XML-RPC and REST producers and consumers, what the pros and cons are, and so forth. But will they have the time to listen to be extol my entire career's experience working on these systems? No. What will happen instead is they will ask me some questions about how I would design a pub-sub architecture on some unknown system with unknown risks and architecture and judge me on that. How can I be sure? Because it has happened before and because, to repeat, there is no way to accurately quantify knowledge of this type.
Is There a Bright Side?
We need a better way for IT people to show their skills and proficiency. I sympathize with employers that want to hire workers that know what they are doing but, at the same time, workers also want to feel like they don't need to know every minute detail of everything, all the time and forever in the future. It is too much to bear and only brings on feelings of imposter syndrome.
As the article mentions, sometimes it is more about creating a simple tool to solve someone's problem that really makes their day. To them, it looks like you just performed magic, but to you it seems as natural as breathing. I just don't understand why job descriptions in IT need everyone to be a nuclear physicist. It is not helping employers find the best candidates, and it is not helping the candidates find the best employers.