How can I accurately and truthfully present my experience in Software Engineering on my Resume?

Question

I believe I've gotten mostly inappropriate roles for my level of expertise throughout my software career. I judge this in hindsight by most corporate or startup developer roles I've had ending before or shortly after the probationary period. The reasons given have consistently been something like "not a skills match", but no in-depth feedback is ever offered.

(I am based in the USA, as I suspect that answers could be different for other regions and laws)

Now, I undestand from the perspective of the company that they don't want to use man-hours to explain to me where I went wrong in their eyes. And at the same time I realize they don't want to open themselves up to lawsuits for saying the wrong thing.

But, that doesn't help me to know exactly what I did wrong so that I can begin to fix it. I have tried to make different changes, but they were all mostly superficial:

At different roles, I took a somewhat scientific method-ish approach and said "Maybe I won't get fired this time if":

• I have a stack of programming books on my desk
• I ask less questions this time
• I ask more questions this time
• write my questions down in detail with screenshots and submit formal reports this time
• I just use other devs as resources when I have questions
• I don't bother other devs and instead direct all my questions directly to the team lead this time
• I wear a suit every day this time

Now I can hear someone starting to cynically type "Maybe if you just did your job" ...

Well, let me tell you I did it to the best of my ability, I have an excellent what they call "midwest" work ethic, and I have been successful in other roles in IT (e.g., Graphic Designer, Field Repair Technician), having only lost those to economic downturns.

And, it would be one thing if I was showing up late to work every day, for instance. When the termination came I would have an inkling that "well it is probably because I'm late all the time". (To be clear, I pride myself on showing up at least 15 minutes early to work every day). But, it was nothing like that. No malfeasance or laziness, just mostly confusion on what I was supposed to do and always trying to calibrate how many questions was too many. If you asked me to build a LAMP/PHP database app that tracks albums, I can do it. But, that's never what the jobs entail. It is always multiple levels of extra stuff. I believe I'm applying for and attracting higher-level jobs than I'm capable of and I'm not sure to fix that.

I did also go back to school and got a 1 year certificate in web development specializing in WordPress and freelancing. But it was just the first step and I was not able due to finances to finish my AAS (that would be my second AAS, the first one was in a different field). In addtion, I completed over 90 software development certificates on LinkedIn Learning. And I began contributing to my GitHub profile regularly. All this was to "update" and keep my skills fresh so that I would be more prepared to work in a modern codebase.

So, if they are right -- that I'm not a skils match -- why did they hire me? And how did I pass the code and whiteboard tests? I must have some talent, right?

I suspect it may have a lot to do with how I advertise myself in my resume. In order to stay anonymous on this forum I cannot show you my actual resume, but I have included some examples below for context.

Example: SDLC knowledge

For instance, a recent job lead that was emailed to me by a recruiter lists this requirement:

Knowledge of the full software development lifecycle: from business/systems analysis, through requirements gathering and functional specification authoring, to development, testing and delivery.

Ok, I says, that one is definitely a match for my background and skills. I understand the basic principles of each one of these items in the lifecycle and I have a 101 understanding of the five stages of project management, which seems to run parallel with the stages of SDLC. So, in honest evaluation I would say that I definitely "have knowledge" of the SDLC in that if somebody is speaking about a particular phase I know what they are referring to.

And I have been responsible for the full SDLC in my own self-learning coding projects, some where I've actually created working solutions to problems I've had, (mostly DOM scrapers in various languages including Perl, PHP, and JavaScript). But, I realize now that SDLC in small personal projects are significantly different from SDLC in complex, multi-layered, enterprise software applications/systems.

Therefore, it is NOT true that don't have knowledge of SDLC. But, it IS TRUE that I don't have the level of depth of understanding that an enterprise client may require.

How do I accurately present that in my resume?

Example: Object-Oriented Perl

Another example is how to list my experience with programming languages. For instance, I have been writing my own Perl scripts since 2000 (self-taught from Oreilly books and online tutorials), and have even worked at a Jr. Dev role where I worked in codebase that was basically object-oriented Perl XML modules for building web pages. The company essentially was building React in Perl a year or two before React was even known about. I was promised 6 months of closely-mentored ramp up training. But after only two months my mentor jumped ship and took a job with another company leaving me in the lurch, and despite my working hard and doing my best, I was confused and didn't understand enough to be self-sufficient in the role. I was let go for not a skills match.

I have seen requirements similar to this before:

`Experience developing object-oreiented Perl modules for complex data-driven codebase`

Ok, it is NOT true to say I don't have that experience. It IS TRUE to say I don't have much of that experience.

Further, to leave that off my resume entirely negates all the years of self-learning and understanding I have in Perl. It would be like saying I don't know Perl at all or have never experienced it, which is not true.

Final Example: Listing Times/Durations

And for a final example, let me present the issue of times, durations, and dates.

It is well known that employers are likely to pass up good candidates who have significant gaps in employment history. The conventional wisdom in the "job hunting" field has been for decades to use a functional or combination resumes instead of chronological to "accentuate the positive" and deemphasize the gaps. But, in the last five years or so, it seems -- especially when recruiters outsource to "sub-recruiters" or "recruiter middlemen?" -- that I am always asked to provide a complete chronological listing anyway.

The most honest explanation is that I got fired from various contracts because they decided after 2-3 months that my skills weren't a great match. But, following advice of many recruiters I've talked to, I usually phrase it as they were short contracts.

But, the thing that really confuses me is when the JD says something like

7+ years LAMP web application development required

Well, I have been developing web apps since 2000 when I wrote my first Perl script to scrape all the images off of a gallery site. Since then I have written many web scraper scripts in JavaScript, originally in jQuery, then ES6, and most recently using fetch API.

But, I would not consider myself and expert-level or even senior-level web application developer. Maybe Jr, intermediate, associate, or even entry level. But, how can I be entry level when I've been working in software development (professionally) since 2009?

Further -- and more to the point -- though I have been developing since 2000, it feels dishonest to say that I have 20+ years of web app development experience in Perl, PHP, and JavaScript, because those 20+ years have many gaps and only one software job I have had so far (Jr. PHP Developer) has lasted longer than 3 months. I have worked a total of 6 or 7 software contracts and one of the them lasted 9 months because I quit to move out of state, and the others I got fired from.

The successful team leads I have met in my career had at least 2-4 years of continuous experience in software development with the same company. Because I've had so much 'stop and start' with different companies, I've not had a good opportunity to absorb a particular workflow, system, product, etc. (which for me is important -- especially with complex abstracted systems).

My Question

Here is my motivation for the question: I am currently in need of income quickly, can only work remotely (I live in a rural area, so no software roles locally), and am revising my resume to target jobs I will be a great match for and that I can actually hit the ground running.

How can I ensure my resume accurately reflects my level of expertise to meet the expected expectations of recruiters and clients?

Additional Reading

• Is there a career path as a Software-Engineer for a CS-PhD?
• How can I properly describe my years of experience on my resume?
• Resume: How to quantify my contributions as a software engineer?
• Mistake in years of experience in resume?
• Can I add software engineering to my resume if I do not have a software engineering degree specifically?

Answer 1

Your resume is obviously not the problem. You're getting looked at for roles. You're making it through interviews, and you're getting offers. I would say your "work ethic" needs work.

Showing up on time or early isn't work ethic. Getting your job done as it's expected to be done is work ethic. Some questions to ask yourself:

• Are you learning what they need you to learn?
• Are you learning it within expected timeframes?
• What feedback did you get? How did you respond to it?
• Are you able to absorb information in a self-sufficient manner?
• Is the mentorship you require a drag on the people around you?
• What is your bug return rate on code you delivered?
• What level are common comments in code reviews you've received?
• How much of your code has gone to production?
• Does anyone ask YOU any questions?

Very few people care about your certificates or that you went back to school. They want to know one thing: Can you deliver? You need to be a value add to any team you join regardless of your level, and judging by your results you have not been that. Reading this post, I see a lot of excuses, and I don't see any accountability. As @JoeStrazerre asked: Have you tried reaching out to former coworkers to ask them what you could have done better?

Have you tried cataloging previous feedback and think about how you responded to it? Did you argue and make excuses or did you buckle up and focus on the change? Think about what you did to make a change regarding that feedback. You should be able to list the specific actions you took that were expected to lead to that result.

Answer 2

As Joel already pointed out, the resume it's not your problem. The problem is that you have no clue what's happening and why.

"not a skills match"

That's just a non-committal phrase that doesn't mean anything. If you got terminated multiple times in short order it's unlikely to be related to actual technical skills (or lack thereof). Skills typically are the easiest things to vet during the interview process and while a major gap can fall through the cracks once, it's very unlikely to happen consistently.

It's more likely that there is a problem with your communication style, behavior, work or collaborations style, quality or timing of deliverables, planning/tracking, etc. Unless you figure out what that is and address it, you are prone just to repeat the cycle.

Next time around I would recommend

1. Make sure you ask a lot of question during the interview process. Make sure that you understand what skill level is required. Be open, honest & accurate about your own skill set: don't oversell, don't undersell.
2. Ask for a regular check in meetings. Once a week is good. During the check in meeting ask for feedback "What's working, what's not?" "What should I be doing differently?" "How can I improve?"
3. Track your own work, deliverables and progress formally (if your employer doesn't do it anyway). Make sure there is a written plan that's agreed upon up front by all parties involved. Look for employers that use Scrum, Sprints, Jira etc and if they don't, just do it yourself. You want to make sure that you know when you are falling behind
4. Ask for feedback after each deliverable. "What could I be doing better next time?"