I haven't ticked off anyone in a little while. So I guess it's time to open this can of worms that's been sitting on my desk ever since I started this little blogging journey.
Over the last several years, I've had numerous people come to me for advice on how they can (kick)start their programming careers. As you can probably imagine, they're typically stuck in that "junior" bucket - and they can't quite figure out how to get any real momentum in their job prospects.
My advice may shock you. It may lead you to believe that I have poor (or no) moral fiber. And you may view my advice as outright dangerous. But I'm not gonna apologize for what I'm about to say.
If you really want to accelerate your career prospects, there's a good chance that you'll need to lie.
There. I said it. And I don't even feel particularly bad about it.
But what exactly does that mean?? Am I implying that you should just march into your next interview and spew any tall-tale that happens to pop into your head? No. Of course not. But you might want to reconfigure what you've previously defined as "lying" and what you've defined as "marketing yourself".
Allow me to explain...
Algorithms Don't Care About You As A Person
Unless you manage to get in somewhere based on a personal referral, you're probably applying for jobs online. And when you apply online, there's a whole series of digital hoops that they ask you to jump through. Online. Before you ever speak to a meat puppet.
I know all-too-much about this. My first "real" programming gig was for a company that built an applicant tracking system (ATS). Since then, I've worked on several other ATS's as well. To put this another way, if you've ever applied for a job online and been forced to fill out 47 sequential pages of detail about your personal data, your education, your employment history, and your favorite Mighty Morphin Power Ranger - there's a good chance that I had some hand in writing that digital obstacle course.
Here's the first thing you need to understand about online applications. Online applications are not designed to let the potential employer learn more about you.
Online applications are designed to eliminate you.
Depending upon your region and the current economy, a posting for a juicy new IT position will almost certainly attract dozens of applicants. And it will probably attract hundreds of applicants. So the employer's first challenge is to eliminate as many of those applicants as possible - because they can't possibly give every single applicant an interview - or even an honest assessment. Instead, they look to automated tools - like their ATS - to do that dirty work for them.
Knockout Questions
When you're filling out those forms, there are many factors that could send you to the digital dustbin. But the most egregious example is the knockout question.
When employers post a job, they can define their application criteria. Specifically, they can designate certain questions as being "knockout" questions. This means that if you answer that question wrong, you'll be immediately moved to the "disqualified" queue - and the recruiter will never even see your resume.
Thankfully, it's often quite easy to spot these "knockout" questions. They're usually presented after the normal info-gathering part of the application. They're typically shown on their own standalone screen. They're almost always simple yes/no/Boolean-type questions. Let me give you a tangible example of where I have disregarded (i.e., lied on) these questions.
I don't have a 4-year degree. In fact, I'm an entirely "self-taught" programmer. After being in this career field for a quarter century, I now know that almost any employer will consider you if you really KNOW how to program. No dev shop in their right mind will take a degree-holding idiot over a non-degree-holding code-jockey.
But when you're applying for something online, the HR person almost always creates the posting with a "knockout" question that requires a 4-year degree. (Sometimes, the "knockout" requirement even asks if you have a 4-year degree in computer science.)
So I'm halfway through an online application, and I'm shown a screen that has a single yes/no question on it:
Do you have a 4-year degree?
Right away, I know what this means. If I honestly indicate that NO, I do not have a 4-year degree, I might as well just shut down my browser right there in the middle of the application. Because, for all intents and purposes, once I select NO, the application is over.
So instead, I select YES. And no, I don't feel bad about it. At all. Not even a little bit. And neither should you.
Always Lie To The Purple Squirrel
Do you know what a "purple squirrel" is? It's a collection of attributes that can never be met - by any candidate. Employers search for purple squirrels when they have unrealistic expectations or when (more commonly) the person creating the job posting is out-of-touch with the real needs of the business.
The company wants to hire a fluffy mammal. With a bushy tail. That eats nuts. And lives in trees. (Everything sounds kosher so far...) And the ideal candidate should be purple!
Umm...
Or the "business" decides that they need a new Java developer (ok, sure), who also has experience with Oracle (yeah, that's totally reasonable), and feels comfortable cranking out frontend code (ok, that's possible, but it kinda runs counter to "Java development"), has extensive experience with Wordpress (wait... what?), has at least 5 years experience working in a manufacturing environment (huh?? c'mon...), and has experience writing custom Haskell compilers on marine-biology exploratory vessels (oh, sweet jesus...).
When you see a job listing like that, you shouldn't have the slightest bit of shame about lying your way through the application. After all, they're asking for someone who doesn't exist. They're searching for a purple squirrel. And the only people being considered for this job are the people who lied in the application process - because NO ONE meets all of those qualifications.
Find The Truth In Job Postings
We've all seen job descriptions that list a few dozen skills/requirements. The "qualified candidate" should have this half-dozen skills. And also this other list of experiences. And also an additional pile of random qualifications. In other words, we've all seen "purple squirrel" listings.
So... after reading this article, you're thinking that you should just outright lie about all of your qualifications, right???
Umm... no.
My best advice to you is to look at the list of supposed-qualifications and split it into thirds. Those thirds will tell you where you can lie, where you might fib, and where you should be dead-honest.
For example, I just went to a popular job site and grabbed the first Java posting I could find for my area. These are the technical skills listed as "requirements" for the job:
- Java, Tomcat, AngularJS, Angular, React
- JSP and Servlets
- Web Frameworks : Spring, Jersey
- Service-oriented architecture/web services (SOAP/REST)
- Web technologies like HTML, CSS, JavaScript, and JQuery
- Markup languages like XML and JSON
- SQL, Linux
- J2EE, WebSphere
- Enterprise Java Beans, RMI, JDBC
- Object-oriented programming (OOP) concepts and patterns
- Java virtual machine (JVM) and memory management
- Dependency injection
There are 12 "requirements" there. And I've met far too many people who'd look at this entire list and, if they failed to meet even one of these requirements, they wouldn't even bother to apply. I'd like to suggest a different approach.
The first third of those requirements - the first four in the list - those are the "real" job. That's what they're really looking for. They really need someone who can do Java, Tomcat, Angular, React, JSP, Spring, Jersey, and SOAP/REST.
Do not lie about the first third. Those are the "core" part of the job. They need someone who's really comfortable with those technologies - and if you're not, you shouldn't try misrepresenting that fact.
The second third may be, on some level, "important". But you should not self-eliminate just because you don't have those skills. Those are technologies that you'll probably be exposed to in that job - but you won't need to be a subject matter expert in them.
Think about it like this: If you were a Programming Legend in Java, Tomcat, Angular, React, JSP, Spring, Jersey, and SOAP/REST - but... you didn't have any particular experience with jQuery, do you really think they'd want to eliminate you as a potential candidate??? If you are a national speaker on All Things Java, but you really have no direct experience with Linux, do you think they'd want to eliminate you as a candidate??? And if they wouldn't eliminate you for these "shortcomings", why would you allow yourself to be eliminated just because of some automated experience check in an online form???
And what about the last third?
Barely pay any attention to it at all. I mean - you can look at those so-called "requirements". And if you happen to meet them - then great! But that last third rarely has much to do with the actual day-to-day duties of the job itself.
So in the example shown above, maybe you tick all of the boxes, but you don't have much experience at all with Java Beans? WHO CARES??? It won't matter one bit for this position.
It's Not A Lie If You Can Back It Up
When you're trying to land that Next Big Gig (or maybe - that First Big Gig), the interviewer doesn't really care that much about the particulars of your experience and your history. They care about your knowledge and your skills. So if you find yourself, umm... <ahem> embellishing your credentials, the real issue isn't whether you're "lying". The real issue is whether you actually have the skills you claim to have.
Obviously, I wouldn't recommend that anyone just start advertising themselves as a C# developer if they've never written a line of C# code. But if you've been writing thousands of LoC in C#, over a period of years, but that "experience" hasn't been quantified as formal experience for a paying employer... Well, then I totally understand where you're coming from.
You see, most employers looking for C# help want to first look at devs who've been writing C# for many years. And if you just walk in off the street and belligerently claim that you are a C# God - with no real skills to back it up - well... that's not gonna end well.
But if you've managed to mold yourself into a true C# God - without the benefit of a "formal" C# job?? Well... go for it. Do what you need to do. Say what you need to say. Just get that interview. Cuz once you get in that interview, they're gonna realize that you truly know what you're talking about.
Some time ago, I landed a nice gig as a Java developer. I'd never "formally" been a Java dev for any paying corporation. But I'd been writing a hellacious pile of Java for years. So I was beyond-confident that I knew my stuff and I could hold my own in any interview with "regular" Java devs. And I was right. Once I got that interview, the other Java devs immediately realized that I knew my stuff - and a sweet, sweet job offer immediately followed.
Several years ago, I hadn't "officially" been a React dev. But I'd started writing a massive volume of React code in my own time. The job postings all wanted years of "formal" React experience. So I... embellished. And I got numerous React interviews. And I eventually landed a really nice React gig.
Now... I'm on my third "official" React job - and there's no longer any real need to embellish anything in that arena. But I don't feel one iota of guilt over the fact that I had to find some "creative" ways to define my real-world React experience as "corporate" experience. If I hadn't, corporate America would still think of me as someone with "no React experience".
Lie To Machines - Not People
You may be thinking that I'm just an inveterate liar. But I don't believe this is true at all. In fact, in "normal" day-to-day interactions, I believe myself to be inherently honest. But I don't feel any compunction to submarine my own chances when I know that I'm working within an automated system designed to weed me out.
For example: Remember, previously, when I said that I would answer the Do you have a 4-year degree? question as YES - even though I do not have a 4-year degree? Well, I would only do that when I'm going through someone's predefined algorithm. When I'm talking to someone, in person, I have always answered the question truthfully. I've never claimed, in any personal communication, that I had any degree - or any qualification - that I didn't actually have.
You might be thinking that this will put me in legal jeopardy. After all, if I claim that I have a 4-year degree, and then they hire me and find out that I don't have that degree, couldn't I be fired??
Yeah. I suppose they could do that. In which case, I would no longer have a job with that company. But at the point when I needed to clear their mindless online hurdle... I didn't have a job with that company. If I answered the question as, "No, I do not have a 4-year degree," I wouldn't have been considered for the position - which means that I would've been just as unemployed as if I'd said, "Yes" and later been "called out". And the simple fact is that, once I'm in that interview and they realize that I can actually do the job, no one much cares about the college I did-or-did-not attend.
Top comments (18)
Hey Adam,
This was an AWESOME article. I really loved the way you phrased everything and I totally agree with you. I have a question tho about the education part. I am ALL ABOUT lying to the bots about education and telling the truth to the person but most applications don't have drop down boxes that ask about degrees but instead have you list the school, degree, and graduation date. So, do you think I should just add a random school to my resume and then explain to a recruiter that I had enrolled but never finished the degree?
I think that makes sense. I wouldn't put down a school if you've just never been there. But if you went somewhere for a few years, I think it makes sense to put that data in the form - and explain the details to the recruiter/interviewer if they ask.
Oh you'd be surprised. I vividly remember interviewing somewhere that insisted that a degree in Computer Science was a requirement. I'd talked to the recruiter about this ahead of time, since I'm entirely self taught. I even did their online coding challenge.
They rejected me, because, and I quote, I didn't "comment the code enough" - my response to the recruiter? Phew, I dodged a bullet!
Later, after a promotion to being a dev manager myself, I happened to interview someone for a senior position. I genuinely wouldn't offer them a junior seat based on the things they know. But that company that refused me, was more than happy to give them a senior role.
After that, and talking to a lot of CompSci post-grads, that's now my only "knock out"... Do you have a CompSci degree? Yes? Goodbye!
Wouldn't that basically make it the same as the other company? Rejecting people based on a trivial question instead of skills? (Just from the opposite side of the spectrum)
Indeed, it would!
We like your attitude and style.
You've done an excellent job exposing that many systems are designed to whittle the candidate pool down with knock-out questions, but I'm not sure that I wholeheartedly agree with the splitting of requirements into even thirds directly.
That even-thirds technique is dangerous when, for example, the company has a basic job template and the hiring manager adds their real position requirements to the bottom of the list. I've watched managers do this. A candidate following your even-thirds split would lie outright about the most important requirements on that type of job post.
Perhaps a strategy to complement the even-thirds would be to reorder the list of requirements by specificity. Something generic like "object-oriented programming" should fall to the bottom, while requirements like "Enterprise Java Beans" or "Web Framework: Spring, Jersey" should rise higher in the list. I figure that the more specific a requirement is, the more likely it applies to that position. (And on that note, I would run the opposite direction of anyone talking about EJBs in 2021.)
Now for a personal story: Much earlier in my career, I recognized the knock-out questions in an online application system. One of the knock-out questions asked for "A degree in computer-science, software development, or related field, or at least 6 years of experience in software development." The degree that I hold is in East Asian Studies, and I had less than 6 years of professional experience in development at that point, but I indicated that I satisfied that requirement. I got through the HR interview, programming aptitude test, panel interview, background check (including degree validation), and all other stages.
Finally, I got a call from the head of recruiting: "We were just performing a final review of your application and noticed that your resume lists neither 6 years of experience nor a degree in a software-related field, but you indicated that you satisfied that requirement. Are we counting incorrectly? Or did you forget to include some experience?" I responded that I had more than 10 years of experience and the question didn't indicate the experience had to be professional. (That was completely true: I have been programming since elementary school.) I also told her that part of the reason I decided to pursue a non-technical degree was that I had initially taken some software classes, was correcting the instructors in certain areas, and had absolutely no trouble completing programming assignments that students in higher-level courses showed to me. (All of that was completely true as well.) I told her that instead of spending my time in classes for a subject that I already felt I understood, I wanted to broaden my skills and learn something I didn't know much about yet.
She didn't seem too pleased at the time, but thanked me for explaining my application and hung up. I received the job offer the very next day. Either my answer was satisfactory enough for the company to decide that I hadn't lied, or I had done well enough during the interview stages that they decided to overlook the lie they caught me on.
I agree that my "even-thirds strategy" is a bit... coarse. For every job description (and potential submission), you gotta apply a little bit of common sense to the equation. And yes, it is possible that the most important stuff is at the bottom (although I feel this is somewhat rare).
But I don't necessarily agree with your point about specificity. Here's why:
I've seen multiple occasions where an HR person is trying to put together a job listing to be posted online. They know that this job will be with, say... the dev ops team, so they talk to the dev ops manager and they ask that person for a list of all the technologies in the dev ops environment.
If that team/company has been around a while, they probably got a little bit of dang near everything lurking around. A stray VB.NET app over here, some ancient legacy Websphere sever over there. And of course, if you're in dev ops, you might need to "touch" all those different technologies, but that doesn't mean that you need to be functionally knowledge about nearly any of them.
I've literally seen job postings where they list a half dozen specific programming languages, and a half dozen specific database engines, and a half dozen different operating systems - but no one actually has to know all/most of that stuff to do the job.
As for your story - yeah... that's a classic example of what I'm talking about. In my experience, it's extremely rare that you ever get called out on such a detail - although it's obviously possible. And just as the process seemed to end favorably for you (even after getting "called out"), I believe it almost always ends up favorably for others who apply the same "creative truths".
Thank you for the detailed feedback!
The annoying part is that the system* is broken. We're looking for new people to expand our team. We are looking for interesting people with certain skills. But we cannot enter this into the system. The system cannot judge on people being interesting, or have certain skills. What we can insert in knowledge about tools and frameworks. These are then used to filter the pool, by the system, but often also by the people themselves. Skills are the valuable part, having used a tool or framework not so much. If you have the skills, you can learn those tools and frameworks on the job in a couple of weeks. To judge if somebody is interesting we need to figure out what drives people in life. Having a person who likes to build furniture in their spare time can be a worthwhile asset to your development team.
The problem also goes into the other direction. Most job postings are simply bad on describing the work and workplace. It's basically always the same few lines. Like, "you will work in an agile team using scrum". Really? in what way? Maybe describe an average week of somebody in the same position as the application is about. Maybe explain how the system is build/maintained, rather than what tools do you use.
*) the system is the recruiting system composed of HR, recruiters, and the technology they apply to match.
I was in this boat, so I changed the system*.
Now, I personally review all applications, and if needed personally talk to potential candidates before they apply.
Sure, it sucks my time up... but I don't know a better alternative.
Lie in a manner you can always defend with a nice backup 😉....nice article 👍
Truly enjoyable! It's rare to find this level of honesty on the web. Thank you so much! 😁
Cannot read property 'comment' of undefined
Great article! I agree with all your points.
Thanks Adam!
I worked with a guy who later confessed to me of making up nearly all of his professional experience. I don't think he was ever found out.
Bingo! And while I wouldn't necessarily endorse "making up nearly all of your professional experience", I would endorse crafting a "story" about your experience that reflects your skills. In other words, that guy was never found out because he actually knew what he was doing. If he fabricated his resume - and he had no skills - he would've been quickly found out and it would've ended poorly.