It's a fact of life that resumes are crucial and that structure makes a difference. But I've noticed that people often disagree about approaches.
This particular resume is based on a template that people in a channel liked. I've received a number of compliments IRL regarding both the layout and the content.
The only thing that people IRL seem to agree should go is the part about reasons for leaving.
The resume does need a new release. For example, I should start to fill in the years after 2009. But it isn't the resume that's the primary issue here. It's the fact that the market has shifted away from generalists, combined with mistakes that I've made.
FWIW, I've heard multiple recruiters and managers/directors compliment me on my resume style [1]. It's a bit more narrative and a bit less focused on bulleting out skills. This seems to attract more progressive forward thinkers (if you're into those sorts of companies).
At the same time, it does highlight my skills at the top of each area of experience, so some developers reading my resume may skim over the narrative part, focusing on the listed skills. So it works for them too.
It's also quite honest in a few areas that may turn off some people, but to me, it turns off the right people (those I don't want to work for).
[1] Check it out in my profile if you're interested.
That sounds about right. In my experience most recruiters are only capable of matching two words, with very little understanding of what the words actually mean. They have no idea that RDBMS / Oracle/ SQL are synonymous to a degree.
Be careful about trusting compliments people give you when they're physically standing in front of you. When people are looking you in the eye, they tend to tell you what they think you want to hear. Online communication creates a distance that makes people more likely to speak their mind.
An advice I have been given is, "don't break expectations". I'm not talking about the content, which can easily have good surprises. I'm talking about the form. There, conformity is probably king. This means things like being a young white male with short hair.
Breaking conventions in your résumé can elicit positive reactions, or catch someone's attention. But it will often elicit such a strong negative reaction that your reader even look at the content. This thread alone contains examples of this.
For instance, saying "I" in the resume is breaking a convention. Nobody will reject you for not writing "I". But some will reject you for being cocky or narcissistic, or whatever. Same for your recommendation citation. It is not expected in the résumé, it is expected in a separate reference. (Edit: that last one may be an obviously good surprise, though.)
Try making a boring, conventional résumé. It should give you a second point of reference, and may help you out of a local maximum.
The interest is appreciated. However, we have different perspectives.
My 'C' experience dates back to 1976 and is probably still relevant. FWIW I never did much COBOL though my firm did have a COBOL-Lint.
I don't think that your 20 years of Linux experience, or mine, is "meaningless". Not if the experience has been continuous. And, in my case, I've not only used Linux almost daily since before Slackware existed, I've developed my own distro, I maintain copies of nearly 2,000 packages, and many of my copies have patches of my own design.
Regarding the "masters of" issue, I may not have made the "generalist" point in the post clear enough. I'm only a "master of" a few things. But I'm very good at getting back up to speed on the things that I've had "experience with".
This is what a generalist does.
I agree with the "Take off your reasons" point. I'm going to keep most of the rest. The difficulties that I'm facing are partly due to my own foolish mistakes. But they aren't about the fact that I've listed hobbies on my resume or that I have a nick that implies age.
I'm not going to pretend to be a twenty-something specialist. It isn't what I am. I'm a highly experienced generalist. In this context, the decades that you feel that I ought to hide are relevant.
For some perspective... I'm 49. Last time I looked for a job (six months ago), I had two offers in less than two weeks. In general, I can get a job in no more than three weeks, just by answering the calls. And I don't think I'm all that special.
What I do have is a relevant resume, both buzzword compliant and impressive to humans who actually know their ass from a hole in the ground. It's carefully honed not to present me as a "generalist" (or some other self-perception), but to get me to the top of that pile for interviews.
Look at your resume as a piece of software. No matter how aesthetically pleasing and warmfuzzy your resume feels to you, if it isn't working, then it's buggy and needs fixed.
If I was a recruiter, this would go in the not interested heap.
While some companies want generalists, this isn't tailored for that either. You indicate projects you've been on, but not what your specific responsibilities were. Describing the project's language, DB, and how the project is pipelined is not useful. What did -you- do? What experience do -you- now have that could translate to other projects? "Core was a Perl server that collected binary data from upstream devices, stored data using SQL, and relayed it to clients as XML over HTTP." tells me about the project, but not what -you- did, not what experiences -you- now have. Even better if you can highlight keywords for me. The whole 'typical projects' section is kind of a waste; it's project names that have no meaning to me, or which may, but tell me nothing about what technology you know. 'Email client programs'; does that mean you have familiarity with the various email protocols? TCP/IP? GUI development? Nothing anywhere else tells me what it is you know.
Most companies want to fill a niche. Highlight what niche you can fill (yes, preferably tailored for the company), and make that -obvious- in your resume.
In general, take this approach - assume a recruiter, HR person, etc, will spend 3 seconds looking at your resume before deciding whether to bin it, or continue reading it. They are looking to match a certain set of relevant keywords/terms. What message do you want to send to someone in three seconds/what words/terms do you want to be matched against? That should be what I as a reader get from the first sentence, the first item in your experience, and the first item in your skills.
The message you're currently sending is "Old coder, part of a large team that did...some stuff that isn't spelled out clearly, and generalist with a whole lot of bullet points". Not interested. But tell me "Perl, C, and Linux expert, extensive application development experience, double CS/Math major", and suddenly if I have a Perl or C codebase I'm interested. Right now I have to do too much reading and thinking to get that information out, and no recruiter will do that.
Also, in general, you are correct that there is a bias against age. You're making it so the first thing I notice is your age. Make it so the first thing I notice is your experience; make it clear that you fill the niche I have, that you may well be the ideal candidate for my needs, BEFORE I notice your age.
These points are sensible. But aren't you simply confirming what I said to begin with?
You're essentially saying that companies use checkbox filters to sift through applicants looking for specialists. Exactly what I was trying to say myself.
The solution that you propose is to create a targeted resume.
But I've worked on hundreds of projects. Many of which used technologies that are no longer relevant Is it possible for me to produce a tailored resume based on perhaps one project from 20 years ago that matches a specific niche?
It doesn't seem likely. So most firms are going to be out of reach. I'll need to acquire more specialties. Or identify firms that are interested in generalists.
You are not a highly skilled generalist. That implies you are a master of everything. You are not because no one is. Being a master of a few things with experience with many things makes you a useful specialist. The proverbial T shaped person. This is a good thing.
Highlight the things you are actually very good at, put the rest as experience. It looks like you've written a lot of Perl, so you're highlight that. Highlight Linux package management. Despite what you think, these are specializations.
Yes; you're correct about the "highly skilled" part. I should edit the point. I'm a highly experienced generalist as opposed to a highly skilled one.
You're also correct about the fact that I do have a few specialties, including Linux and Perl. I'm pretty good at a number of languages, but Perl has been a favorite for 20 years.
Perl is friendly and fierce
Perl all problems shall pierce
Perl is the duct tape
That holds together all things
Of Perl we sings
Perl is all things beautiful and bright
Perl is a magical sight
Perl each day and each night
As a generalist myself, usually what other people consider "master of" I consider "back to speed in a few weeks." So I claim mastery on my resume because "mastery" is highly subjective.
For example, with my current position one of the reasons I got the job was that I claimed to be an expert with C++. Before jumping into this role it had been 5+ years since I had done any real work in C++. Shortly after joining I was asked to assist on a project written primarily in C++. Any time you join a new project there is some onboarding to learn how things are done in that project. I was able to get back to speed with the language and ecosystem within the period expected for onboarding. I was complimented on my expertise of C++.
I believe I am a seasoned software developer who has attained a fairly high level of mastery in the core skills required to build highly-complex software systems. Yet if I were to compare myself to some of my coworkers in the past I would be hesitant to call myself an expert on a particular subject like embedded programming (for example). However I claim to have this expertise on my resume as I have done quite a bit of embedded work in the past and I am familiar enough with that type of development to ramp up quickly again.
So even though I perceive myself as a generalist, many times my resume looks like that of a specialist. I am comfortable making these claims because I know I can deliver on them. You have to separate your self-evaluation (in which I tend to take a humble view of my abilities: that which I do not know vastly outweighs that which I do) from your self-presentation (in which I will make the boldest claim I believe I can support). Long years of experience are extremely relevant, but you have to connect the dots on your resume, you can't rely on the recruiter or hiring manager to see the intrinsic benefit of your experience.
You sound like a "T-shaped" guy: Broad knowledge and skills, with actual expertise of a few areas. Some companies, such as Valve, actually seek that. Have you sought them out? (I'm guessing that you have, but who knows…)
Here's how I look at it: The only job of your resume is to get an interview. So whether the knowledge is relevant doesn't matter - the only question is whether it'll help you'll get to the interview. And from that view, I agree with your parent and 300bps' comments.
Over time, it's hard not to become a highly experienced generalist if you're good at what you do.
When a developer starts out its easy to find and beat a tribal drum of specializing in a few things.
This is often due to only having one or two cycles of learning and experiencing "a few years specializing in x". Add to the mix the veiled glorification of the twenties as a magical time to go hard (where ultimately everyone goes home), it can become an incredibly distracting echo chamber that one has arrived.
Something happens every few years though on the path of being a specialist, you get deep enough into one skill that it overlaps into another skill. The specific few skills collected in the first few years, become a specific 5-10 with equal depth.
Take someone who has developed 15 to 40 years and imagine how many cycles of learning they have been through to implement similar algorithms in multiple syntaxes.
That's someone I want to learn from when I shape my aporoaches, instead of having to feed my own snowflake quotient to relearn the same lessons before me.
As a polyglot, I've been programing for 20 years and am only in my mid-30's. Most developers will end up the same. way I've ended up with enough web, desktop and mobile development, along with the hardware and networking experience that building these solutions once required in addition to programming alone. It's full stack across hardware and software and networking, not the full-stack of frontend and backend dev that specialists espouse as full stack. I sure as hell didn't plan on this path, maybe it's the path of a lifelong problem solver.
One thing that some twenty something specialists may not yet have noticed is that programming is a separate skill from the syntax of any given language. The experience of figuring out how to do what you already know in a new syntax. It seems there can be more fascination in recreating libraries that have existed for decades, but not what the next leap is.
There's a fundamental mistake most recruiters are making too. They aren't qualified or trained to hire for technical positions. In the hiring I do and references I give, recruiters are generally clueless without their checklist. Programming isn't a skill like knowing how to drive a forklift. It's much deeper, and with the correct type of polyglot developer much more transferable between languages.
I'm inclined to work with an experienced generalist more often than not because I prefer to work with others who not only keep up, but help lead the strategic charge. Depending on the problem, younger specialists often go through relearning what experience has already taught. Both skillsets are valuable and necessary on any team, but I have my preference.
My advice, is to consider focus on a highly fluid and evolving area of technology that is in high demand, pays well, and you can effortlessly pick up. It's where you're talents shine. One area is mobile development. Build some projects and spin current skills into the next area. It will better highlight your ability to integrate everything from top to bottom.
I admire and am in respect of your experience and journey through creating so many solutions. If there's an interest to connect offline I'd love to learn more about your story to see if I may be able to help and if I may be able to learn more from your experience.
Will anyone who is half good at what they do will end up in any different situation than this in 20 years? Our creators need to keep creating. Maybe there is an evolution and growth needed in our field for the highly experienced.
Some of my friends have told me I'm too literal about job listings. They echo a key point that you've made here, "JAP positions normally require just the basic coding skills".
But if I apply for positions that need specific frameworks, plenty of people who have those frameworks are likely to apply as well. I've got experience, but won't applicants who match the checkboxes in job listings be more likely to obtain interviews?
Don't say no for them. That's their job. If you think you would do the job well and enjoy it, apply anyway. Just be upfront about the things you'll need to learn about as you go, so they know what they're getting themselves into.
Doesn't experience count with Sales regardless of age? But you're correct in general. Age discrimination is probably more significant in some non-tech sectors than in tech.
And I agree that the social network issue is crucial.
Heh. I had to do all that at the dot-com because they fired everybody else after the money ran out. I was the only rank and file employee left except for one left-over junior marketing person. I turned him into a coder and he wrote a GUI for one of the CLI products. I did pretty much everything else for a couple of years.
I think you're right about the "Reason for leaving bits"
The "my own distro" part is about more than sysadmin. I'm fairly proud of it and recruiters have sometimes contacted me specifically because of the project.
The "my own distro" part is about more than sysadmin.
I'm fairly proud of it and recruiters have sometimes
contacted me specifically because of the project.
Yeah, I agree that this is really impressive. Everybody's advising you to trim older things off of your resume and perhaps that's good advice but starting/maintaining your own distro seems like something to leave on. One question: why not name the distro on your resume so people can check it out and verify and/or be impressed by it?
What I would say is rather than trim old stuff indiscriminately, focus on what it is you want to do (or what is relevant to the position you are applying for) and remove stuff you've done but don't want to do again (I've done COBOL programming but I've NEVER put that fact on a resume). Resumes do not need to be exhaustive lists of everything you've ever done.
I would suggest applying for university IT jobs. Their salaries will pale compared to what SV pays, but you will be able to live, the hours are sane, the work environment tends to be decent, the benefits tend to be excellent, and if you are at least moderately competent and ethical you're unlikely to get fired.
LACLIN will be 10 years old, in its current incarnation, on Christmas Eve 2014. I use it for all of my work. But I haven't created a public release yet.
I'd hoped to create a public release this year but I needed to suspend development in 2012 due to unforeseen circumstances. Work will resume if things stabilize.
I looked at OldCoder.org and saw that you do have extensive screenshots of your distro. Very cool!
I don't mean to myopically focus on your distro but since you said you're quite proud of it (and you should be!) ...perhaps mentioning the distro by name on your resume, and also by name on your site, could make it much easier for people to make the leap from your resume to finding out about it on your site.
Yes, it's relevant. It was part of the reason that I never built a social network. Additionally, in some face to face interviews, it was a significant factor.
However, in recent months, I've done better. Four random strangers that I've talked to this year, in a bar, a photo processing shop, a LiveScan facility, and a phone store, all talked about doing business with me. Whether or not anything comes of it, this is encouraging.
It had to do with coming across as confident and relaxed. If you Google (tm) the article "Topological Theory of Autism", you'll read about something called compensating. I think that, as I speak with more people, I'm improving at that.
Perhaps you should talk to subject matter expert about whether you apply for social security disability. From what I read, it's possible to qualify if you are unable to find work due to mental health issues. Good on you if you'd rather make it on your own, but it's better than being homeless and it's pretty much what the program is for.
You are on the path to understanding why this is difficult for you. If you touch it deeply and think a great deal on it, you can learn to acknowledge and overcome it.
You may like to read some of Thich Nhat Hanh's books. He teaches people how to transform their suffering into peace and joy.
Most contract jobs that I see seem to be apps or webdev.
I expect to get up to speed more on native apps and/or web apps. So I've got a shot at this side.
I've done basic webdev. I might be able to make a go of small sites. But I don't know much about building a client base. Note: I've held onto an octocore server with 32GB RAM, so I could probably combine webdev and hosting.
Yes, it's U.S. specific. I don't think it will happen in the EU. The EU may go through some changes, but I feel that health care will continue to be seen as something that countries need as part of a sound infrastructure.
Unfortunately the change is inevitable, just as with pensions, because the population is aging and there isn't enough youth left to pay for it. And due to automatization or outsourcing, cheap labor is less and less needed anyway and high unemployment rates will be pretty common.
This reality in fact highlights another reality - our economic models based on scarcity don't work anymore and we need to either transcend it, maybe with technological improvements that drops the price of basic necessities, like food, energy and medical healthcare, or we're fucked.
Well, you're overlooking mistakes that I made. I feel that generalists should be valued more highly; this is a significant issue. However, I should have built more of a social network, taken better care of myself physically, diversified my investments more, and kept up more with how the market was changing.
I agree with that; I think people undervalue generalists, get stuck with a specialist which is nice while you are in that particular field, but the world changes. Specialists are specialists because they spent a lot of time on one thing; depending on your age that means you didn't spend a lot of time on anything else and that might turn out to be VERY difficult when you get older. I don't know many PHP 'specialists' above 30 who can actually 'change' their calling. They have an extremely hard time picking up anything else as they have been coding PHP (and a tiny bit of JS) only for the last 15+ years. It takes serious effort to switch at that point if you're not used to that flexibility in your brain.
Keeping up with the market is a big thing though; as someone who was in the dotcom boom and who did backends at the time, I only noticed that everything changed years 'too late'. It wasn't really too late, but my eye wasn't on the ball for sure as I had a cushy position anyway I didn't need to, but when I sold my stock and went looking for the next interesting thing to do I noticed that the world changed significantly.
I don't deny that getting older has an impact but your statements above are applicable to anyone and probably more so to older developers. Reading over your story the main thing that stuck out with me is that you've had a it rough for the past few years and its obviously had an impact on the career.
What I would add is to focus on your health. I don't know what problems you have but if you can work on the diet, work on the fitness, get on some kind of weight training program. The better you feel, the more energy you have will make you more effective everywhere else.
I started a few days ago. It hasn't been a good week for medical issues but things are looking up.
I've been to the Emergency Room twice since Sunday. And I had a fever of 102 degrees just a few hours ago. But I'm feeling O.K. and I'm scheduled to go back in a few hours to nail down what's happening physically.
Due to recent changes in U.S. laws, I might be able to qualify for medical care now. If it works out, this will be a big help.
Still, you should be preferable than any college graduate in any kind of junior role. Correct me if I'm wrong, but doesn't a junior role mean 100K in SV? Or do you want a more senior position?
There is a bias against having highly experienced people in middle level jobs.
Apart from the stereotype of the jaded guy that has seen too much shit, there is the power balance between a youngish manager and a very experienced programmer. Sometimes the programmer will see a flurry of incoming problems very soon and flood the manager with them, and the latter won't know how to deal with this kind of situation. He'll be relying a lot on the more experienced person, but the power balance is reversed and the responsibilities as well, and it takes a lot of tippy-toeing and ego swallowing to sail smoothly. It's tricky on both sides, and company would prefer to avoid that kind of situation.
This is highly unfortunate and seems like the problem is with the younger managers not having adequate support.
In my early 30's I had the the privilege of being able to recruit 50+ developers onto two separate teams at a startup. These were people who's experience vastly outweighed my own. I was still responsible for guiding my teams to meet the business needs, but what I learned from these people literally changed my life.
Completely agree. I had the chance to be on project where I was the least experienced in programming, and got to deal with the management stuff (in the most basic meaning: I was doing just anything needed to let the other devs focus on their tasks, not telling other people how to do their jobs). I learned a lot, I got explained a lot of tricky problems that I wouldn't have understood otherwise, and on their side they didn't have to care if the client answered their email or not.
It was a really nice experience, but more an exception than the rule. I never got to work in another place where people wouldn't focus on the titles as a hierarchy thing, but just as different roles in a projet.
If I stay in the S.F. Bay Area, I think that a junior tech position here might work out. Above entry level and below lead. The trick will be staying above water long enough to find a good match.
I'd expand my options, both tech and non-tech, if I took the right courses and obtained certifications. I'm seriously considering doing something like this.
For example, the person who did my LiveScan recently (it was a background check for a tutoring job) teaches an EKG Technician class and said that it might work out for me.
A police detective who I phoned by mistake one night told me that I should consider getting a Digital Forensics certificate. He seemed to feel that I might be a match for that. Note: The story of the call is on the same weblog as tonight's post.
The medical care issue may be looking up. I had to go to the Emergency Room the other day. Didn't wish to, but no choice. I learned that the laws changed in January and that I might qualify for assistance after 10 years without care.
The digital forensics suggestion seems quite good to me. It's a growing industry and people with decent skills are hard to find, where decent skills means being cable of working with technology from hardware up to data structures and encryption, while also making sure processes to capture and present evidence is followed properly.
In everyday situations, outside of job interviews, if I feel confident about a situation, and I'm not under time pressure, I often come across as polished.
I've been mistaken for an attorney repeatedly over the past few decades. At least twice, people have thought that I was a government official of some type.
If the confidence isn't there, I do poorly. And I haven't felt confident in interviews because of the types of questions that you're referring to.
I don't memorize data structures and algorithms. I start with projects and learn what's needed in each case.
Coding tests are another problem for me. If you review my GitHub repos or technical site (oldcoder.org) you'll see that my code is reasonably good. But it involves flow. If I drop into flow, I can do anything. But it's difficult to reach that state while somebody is waiting.
I understand, of course, that companies have their processes, and that I need to be the one to adapt as opposed to the other way around.
I'm around 40 and I struggle with the exact same issues, at least with algorithms (I'm pretty much OK with data structures).
Funny thing is, I've enjoyed doing things like Project Euler just for fun, and I can usually work out an algorithm given a little time and the ability to work on my own in an environment I'm comfortable in.
But put me in front of a white board, or phone interview, with one or more impatient interviewers in front of me? I'm toast. Many of these interviewers were studying these algorithms in depth in school only 4 or 5 years ago.
Anyway, I've resigned myself to the fact that I have to earn my own living by freelancing and side projects. I'm doing OK with that, and I hope that an upcoming side project will provide even more financial stability.
Have you considered starting your own company? These days, you don't need much.
On the off chance that you'll look back and see this, I'll response. Your implication is that data structures are algorithms, and while that certainly may be true, both traditional computer science curricula and hiring tech companies make a distinction between the two.
In the latter case, what they call algorithms usually tend to be similar to the kind of "brain twister" problems that Microsoft was famous for.
In the former case (academics), data structures include things like stacks, queues, deques, linked lists, and on to graphs and trees. Whereas algorithms are specific procedures carried out with data structures, like sorting and searching, and dynamic algorithms. And then on to much harder stuff, like FFT.
My point is simply that I feel comfortable creating stacks, queues, linked lists, graphs, trees, etc., whereas when someone asked an open-ended algorithmic question to be solved on the white board or phone, I struggle under the pressure and gazing eyes of multiple interviewers to solve these problems (whereas I do fine in my own environment with only the pressure of finishing a job).
Thanks for the reply. Yes, I was going for "data structures are algorithms" bit. Eg what good is a Fibonacci tree without the operations on it? And on the other hand, lots of `algorithmic problems' fall into place naturally, once you have the right data structure.
> My point is simply that I feel comfortable creating stacks, queues, linked lists, graphs, trees, etc., whereas when someone asked an open-ended algorithmic question to be solved on the white board or phone, I struggle under the pressure and gazing eyes of multiple interviewers to solve these problems (whereas I do fine in my own environment with only the pressure of finishing a job).
I actually do way better in the interview than when I just have to convince the computer (or myself). Enough confidence often persuades interviewers to accept handwaving.
That advantage is unfair, and makes the interview less predictable of success on the job; but I won't complain. For you, I can only recommend practice, or looking for companies with different hiring procedures.
You should study up on algorithms and data structures. You should get some coding interview books and do the problems in them. It will make you more confident, and it'll let people see the skills you have. Unfortunately, traditional interviews are really bad at actually figuring out if someone is a good coder... but if a company you want to work at uses those methods, you have to be able to pass their tests.
You mention social network, I think it is also critical to build up a good professional network. The group I am part of has a couple of individuals in their 50s, one a specialist and one more of a generalist. They joined the company through professional connections they had worked with before.
I'm purposefully making a distinction between "a random set of contacts" and a more targeted group of people who you have worked with, know your strengths, and want to work with you again.
This particular resume is based on a template that people in a channel liked. I've received a number of compliments IRL regarding both the layout and the content.
The only thing that people IRL seem to agree should go is the part about reasons for leaving.
The resume does need a new release. For example, I should start to fill in the years after 2009. But it isn't the resume that's the primary issue here. It's the fact that the market has shifted away from generalists, combined with mistakes that I've made.