How to READ a Job Posting

After reading a recent article on DZone about writing developer job postings I started thinking about how job seekers often read and sometimes (mis)interpret job ads. At least once every few days I encounter some rant about how unrealistic job postings are, whether on a so-called Entry-Level Job that actually requires three years of experience or a spec that appears to seek an entirely unrealistic collection of skills. Must have ten years of experience with Node.js is coming to a job ad near you!

As someone who writes job descriptions for companies, I’m not here to defend those in the industry who use a highly exclusionary style that can be off-putting for many job seekers. Until some spec writers learn to do a better job of representing what makes for both an exceptional candidate and an acceptable candidate, I think it is important that readers understand how to interpret what is written to make the best judgment on whether to take the time to apply and to further set their own expectations properly regarding the likelihood of a positive response (interview).

man-791049_1920

Some key considerations when reading a job post.

Postings (Like Resumes) Are Written With SEO in Mind

You know how some people pepper their resumes or LinkedIn profile with popular buzzwords in hopes that some recruiter will be searching for that term? Well, people writing job specs do the same thing, and writers will include what we might call complimentaryskills listings without those skills actually being considered as a requirement. A Clojure shop might include “Haskell” and a company using Redis might list “MongoDB” somewhere in the posting, as we can’t expect every functional programmer or NoSQL enthusiast to only be searching for their particular stack. Maybe the “ideal” candidate is an expert in Clojure and Redis, but the company doesn’t want to miss out on the Haskell developer either.

Postings Represent “Ideal” Candidates

In most cases a job posting is an elaborate wish list with several requirements and nice-to-haves, but hiring managers or recruiters generally don’t expect candidates to be able to check off every box from the list. Technology hiring varies greatly between companies, and in my career I’ve consulted to companies that demanded at least n years with a specific framework as well as firms open to hiring engineers with programming experience on any stack.

Non-negotiable Requirements Should be Fairly Obvious

In most cases, writers of job specs will be explicit about requirements that are truly required. There will always be companies that believe four years of Java experience is inadequate but five years is just right (without even considering how we try and justify what a year of experience even means), but most shops will show flexibility on items where years of experience is listed. It’s probably a waste of time to apply for positions with more binary requirements, such as those involving citizenship, education, or a required certification.

Look for the Gotcha

Over the past few years job post writers have attempted to verify that an applicant actually read the full post by including some obscure directive in the post. Please include your salary requirement and favorite color in your cover letter.

Format, Focus, and Culture

Readers of job descriptions should be able to draw some conclusions about the hiring company based on the format of the job spec and what content the writer chose to include and emphasize. Companies advertising for a Software Engineer IV vacancy that dedicate multiple paragraphs to describe employment policies and procedures may be more likely to have a regimented environment when compared to job specs that instead choose to include the core values of the development team.

Job postings are an opportunity for a company to both describe an ideal candidate and explain why readers might want the job. The way an employer chooses to use the space may speak volumes about how the company sees itself and how they want others to see them.

Pythonistas, Rubyists, and Gophers: Hiring Preferences Across Language Camps

For many years I recruited exclusively for clients that were seeking to hire Java developers and architects at all levels. When I opened my new recruiting practice almost four years ago, I made the decision to expand my focus and include development shops that were not using Java as their primary language (or at all in many cases).

My strategy to move beyond Java was based on obvious trends in my circles. First and foremost, I wanted to recruit primarily for startups and smaller companies, and I found that startups were not choosing the Java language as regularly as they had earlier in my career. Second, many of the Java pros in my wide network (including many of the most skilled among them) had moved on to focus on other languages. After over ten years building my reputation as the “Java recruiter”, I decided it was time to follow some of the crowd.

I can only speak from my own experience interacting with perhaps a couple hundred companies and thousands of job seekers, but I quickly noticed some patterns and trends in hiring preferences within these different language communities that were new to me. The standard comment to articles about languages and hiring will be the thought that language is just a tool, and I get that. Hiring managers might use dozens of criteria (some more applicable than others) to evaluate candidates on paper and my observations may not reflect your personal experience, but I thought it would be worth sharing my experience and hopefully hearing from some readers on what they have witnessed.

Some thoughts…

  • Python or Ruby Accepted Here – Shops using Python or Ruby as their primary language widely accepted devs from the other camp interchangably. I can’t think of an instance where a candidate was rejected for not knowing the used language if they knew the other. If you know Ruby or Python, it seems you can get hired to use either.

 

  • Young Managers and Java “Discrimination” – Younger CTOs and hiring managers seemed less open to Java devs with particular disinterest in Java devs from traditional enterprises. There might be an inclination to claim ageism based on demographics of the Java community, but I found this trend regardless of a candidate’s age. A Java developer in her mid-20’s at banks or pharmas had it no different than someone twice as old. I also found this trend in shops using other JVM languages. I feel that Java developers from large companies, particularly those with long tenures at one employer, face the most “discrimination” in the startup hiring market today.

 

  • Older Managers, Flexibility, and Simpatico – Companies with older hiring managers or CTOs expressed openness to multiple language backgrounds, treating language as a tool. The most experienced managers often cited some obscure language or tool commonality with a candidate (“I too wrote $LANGUAGE once…“) or declared that their interest was due to a well-worded project description that caught their attention (“I’d love to hear about what he did on $PROJECT“).

 

  • For Functional Languages and Go, Interest = Experience – Several clients using functional languages in production treated personal interest in any functional language (demonstrated through self-study, user groups, etc.) as sufficient to grant interviews, and I’ve found this true (with an admittedly smaller data set) in the Go community as well. This may be due to the relative newness of FP, although I don’t tend to find this in other hot language markets with low supply. Self-study and a single GitHub repo seems likely to get you into an interview at a Clojure or Go shop, but might not be enough for companies hiring Node or Angular talent.

 

  • Java Shops Most Specific – Companies (regardless of age or size) that primarily use Java have been the most specific on their job requirements and are much more likely to give minimum number of years with the language and related tools than my non-Java clients. One likely explanation for this is that Java shops might be more particular simply because they can be. With the millions of Java devs worldwide, hiring managers can probably find someone with experience using certain frameworks and tools.

I’d be curious as to what readers have experienced out in the wild.

The Worst Developer Resume in the World, Redux: Best Practices

Last week I published The Worst Developer Résumé in the World, which resulted in three things.

  1. We are not alone – The article resonated with many hiring managers and recruiters who immediately recognized this style of résumé. We’re forming a support group.
  2. RIP Inbox – Readers wondered “Is that my résumé?“, with many reaching out to me or my résumé review/writing side project (Résumé Raiders – shameless plug) for a personal inspection. Some résumés were good. I had to open some reviews with “Are you sitting down? Because you might want to sit down…“.
  3. Thanks…but where is the rest?– A handul of readers asked for details on best practices and tips for résumé writing. “You told us what not to do, now tell us what to do.” OK, I’ll do that.

WARNING: Keep in mind that entire books have been written on résumé writing, which I’m also considering as a future project. I dedicated a full 20 page chapter to résumés in my 2013 ebook, so a few hundred words is only going to scratch the surface of what it takes to craft a résumé that gets results (interviews).

That said, here are some best practices for a good résumé.

A Short, Detailed Summary or Profile

In my opinion, this is the most important piece of a résumé and the section most often overlooked by job seekers.

Why? There are two simple reasons you need a good Summary.

1. Your résumé’s audience. We must assume a human will read your résumé at some point, and we (unfortunately) must also assume that the human is not highly-qualified to assess your background. At many companies the reader will be an HR or recruiting professional who may know little about technology. Startups too small to have dedicated recruiting/HR personnel use administrative or operations staff to review incoming résumés, as dev time is too valuable.

Do you want to miss out on a great job because the résumé screener was an accountant unable to decipher that you have the required five years of Python experience? Or because the reader didn’t understand that the “J” in J2EE is Java? Make it easy for them, which in turnbenefits you.

2. It may be all you need. A well-written Summary can be the only thing a reviewer needs to read before passing your résumé to the next step. In those rare instances where I receive a résumé leading off with a descriptive Summary that includes the skills and experience level we are seeking, I can immediately reply “I like your background. Let’s talk!“. I’ll read the full résumé later as I prepare for our phone conversation, but the powerful Summary got an immediate “Yes” answer from me. The résumé’s purpose is to try and start a conversation, and a Summary alone can do that.

How? A Summary should be written in a way that leaves the reader little room to misinterpret who you are and what you can do/have done. It should be no more than a few sentences. The biggest Summary mistakes, which were detailed in the previous post, are ones that go way too long (and cease to be summaries) or those that contain useless, homogenized, non-descript content.

A Summary that reads “Passionate software engineer with excellent communication / interpersonal skills dedicated to writing elegant code” sounds nice and might be someone I want to talk to, but says nothing about qualifications. Does this Summary make it any easier for the reader to say “yes” to you? No, it doesn’t.

A quick aside: And while we’re talking about self-assessments of communication skills and interpersonal skills on résumés, do you think any hiring manager in history has said, “Did you see this résumé Frank? Says here that Ms. Thomas has excellent communication skills. VERRRRRY INTERESTING… Get her in for an interview at once!” No. Don’t waste this space with self-assessments that every résumé on earth also uses. Show me (don’t tell me) your written communication skills by writing a decent résumé, and we’ll cover speaking in an interview.

Back to the story…

How about “Accomplished software engineer with seven years of experience building SaaS products using a range of technologies including Java, Python, and JavaScript with multiple frameworks.” This quantifies experience and includes more detail on at least some skills that might be required (or requested) for the role.

If you’re thinking “but DAVE, the job spec listed like 50 languages and tools”, let me stop you there. The Summary isn’t the place to test out your ATS-gaming SEO skills. It’s an overview, like a quick plot synopsis for a movie on IMDB. It’s not meant to give every detail and spoiler.

Realistic Skills in a Digestible Format

Why? Long laundry lists of skills gives the reader a few impressions of the applicant. First, we hear the theme song to our favorite game show – let’s play Buzzword Bingo, Résumé Edition!

Recruiters are often accused of just matching keywords, which is a fair assessment at least for the minimum requirements of an initial résumé screening. Development managers are likely to start with the same method. A suitable candidate needs relevant skills and accomplishments. Has this candidate done anything relevant to our job opening? That determination entails scanning for certain required technologies, experiences, etc.

A long list raises the question as to how much the candidate actually knows these technologies. The barometer for experienced professionals is usually to include something you’ve used (at home or work) enough to answer some questions. When someone posts what is likely an impossible list, the reader may get a sense of some dishonesty which could be verified in a conversation.

The digestible format is also important. If recruiters are playing Buzzword Bingo, they need to know which columns and rows to look in to find their desired words. Again, make it easy for the recruiter in order to maximize your own positive outcomes.

How? Keep the list to a reasonable size based on your overall experience, and remember that listing outdated skills may do more harm than good. If you are now doing Go and Node.js work, listing all the technologies from your days cranking on AS400s might not be a good use of space. You don’t need to be an expert to list something, but show some restraint.

Separate the skills into a few sections. Common categories might be Languages and Platforms, Frameworks, Databases, Operating Systems, and perhaps a catchall like Tools orOther. If you find yourself creating categories for just one or two skill listings (e.g. IDEs: Eclipse, NetBeans), you run the risk of adding unnecessary length to the document and might be better served with using an Other section.

Clearly List and Bullet Accomplishments, Ideally Quantified

Many résumés use the Experience section to bullet multiple responsibilities instead of detailing specific accomplishments. It’s not always easy to point to accomplishments, but it’s important to try.

Why? The reader wants to know what you have done, that you can communicate what you have done, and (most importantly to some managers) that you understand how your accomplishments positively impacted the business. Writing about accomplishments also gives you the opportunity to influence your interview, as projects that are on the résumé are infinitely more likely to be discussed than projects you don’t list.

How? It’s best to list responsibilities before accomplishments, with the responsibilities written in paragraph form and accomplishments bulleted. Just below the employer, title, and dates, you’ll have a few sentences you may use to describe the company’s business (if unknown to most) and how your role helps the business (usually entails either saving the company’s money or making the company money).

Bulleted accomplishments should list your role, some details on the technology used to solve the problem, and outcomes. Quantifying details such as dollars saved, revenue generated, or performance improvement metrics are a nice touch when possible. Accomplishments can be both individual or as part of a team, and it’s important to differentiate so you don’t accidentally claim too much credit.

Trim the Fat, and Optimize For Relevance

Why? There are a few reasons for résumés to be kept as short as possible while still covering the necessary content. First is the signal-to-noise problem, where relevant and impressive accomplishments get lost in a sea of useless bullets. Second, a long résumé intimidates a reader, which is another reason for a lazy recruiter to hit delete. When you see a résumé is seven pages, you may look for reasons to stop reading it on page one or two. Lastly, a long résumé with irrelvant content makes it appear that the writer is overestimating the value of a past accomplishment. Hiring managers mostly want to know what you can do today, not what you did in the 90’s.

How? Most of us can safely eliminate details on jobs from 10+ years ago, as they are usually less relevant to today’s work. Your job title and employer for early jobs is enough to give you credit for the experience without giving the reader the impression that you are clinging to accomplishments that are now distant objects in your rear-view mirror.

Lightning Round

Some other quick tips that didn’t warrant full sections:

  • Email handles shouldn’t sound like they were created by a teenager, and AOL addresses aren’t retro cool (yet). If you need to ask, you should change it.
  • Contact info eats up valuable page space if you stack it (name above address abovephone above email), and it’s the least important thing on the document that ironically gets the most prime real estate. Use a small font (like even 6 or 8) and try to keep all of this to a line or two at most.
  • Personal web pages, blogs, GitHub, and LinkedIn links are nice to have if they are neat. Just remember that if it is listed, it’s fair game.
  • Nobody cares what you got on your SAT/ACT tests 20 years ago. Same with college courses.
  • If you decide to list non-industry positions, consider that the reader may have a hard time thinking of you as “Joe the DevOps engineer” instead of “Joe the former pizza delivery guy“. Most of us have had other jobs, but we don’t need to list full employment histories.
  • Don’t list your references names or email addresses on your résumé, unless you want them to hate you. Some recruiters will try and recruit them even if that recruiter never spoke to you. Provide references when asked for them.
  • Listing graduation dates gives away your age using the formula 22 + (CURRENT YEAR – GRADUATION YEAR) = CURRENT AGE. If you fear possible ageism, deleting graduation dates and removing your earliest experience is one way to prevent discrimination. It’s a résumé, not a full autobiography. In some countries it is popular to list birthdays and even photos on CV’s, but not in the US.

RECONSIDER, Startups, and Hiring Stigma

If you are in the technology industry and haven’t read the recent blog post RECONSIDER, you should. As I’m most interested in hiring-related issues in the industry, I’ll get to my point once we get through a bit of background.

tl;dr RECONSIDER

In RECONSIDER, Basecamp founder and Rails creator DHH describes how the term startup is becoming synonymous with the unicorn phenomenon and the potential dangers of this intersection for entrepreneurs and the industry as a whole. He writes “nobody these days is content to merely put their dent in the universe. No, they have to f*&%ing own the universe.” Much of what is written about startups reflects the attitude DHH describes, and he asks readers to reconsider that there may be motivations beyond billion dollar valuations for starting a company.

DHH reports that he co-founded his company over ten years ago and they’ve grown to a modest 50 mostly remote employees without a presence in the Bay Area. Clearly Basecamp never fit the unicorn profile and their maturity may preclude them from being defined as a startup today, but it’s hard to say they haven’t been successful. Few get to commission a special edition race car. The path of Basecamp might not be what the stereotypical startup founder sets out to replicate, and DHH seems to wonder “Why not?“.

What’s a Startup?

One part of the problem is which definition of “startup” is used. Startup is popular shorthand for new and (usually) tech, but some definitions require ambition of fast growth. DHH writes that the term startup has been “narrowed to describe the pursuit of total business domination“. He leads off by identifying Basecamp as a startup upon its founding and later describes it as “a company that doesn’t even have a pretense of an ambition for Eating The World™”. If their intent was never for quick growth or (dare I say) “disruption”, Basecamp may meet DHH’s (and others) definition of startup but doesn’t really meet the definition used most famously by Paul Graham.

Being that there are companies self-identifying as startups of varied age/size/ambition, and some nuance as to how those within the industry define the term, there is opportunity for misinterpretation.

One issue that DHH doesn’t really touch upon is how the somewhat hijacked redefinition of the term startup impacts careers and hiring, or more accurately, how some job seekers may be averse to any company that describes itself as a startup.

Hiring and Stigma

The term startup alone may conjure images of programmers (probably young and male) logging 70 hour weeks for pay well below market salary, poor benefits, and insignificant amounts of equity. These images may be a holdover from the first dotcom boom if you’re over 35.

Startups in many markets across the US today may bear almost no resemblance to that image, and unfortunately thousands of firms need to overcome a stigma with job seekers due to the ubiquity of the meme. It is assumed by some that a startup in Philadelphia or Boulder, solely because of their self-identification as a startup, is likely to expect employees to accept significant cuts in compensation and benefits as well as increased hours. It’s this often false expectation that leads some to stop listening about potential new job opportunities once the word startup is introduced into conversation.

What if I told you there were many fairly new and relatively small software firms solving complex problems that pay engineers at or above market rates, offer work/life balance, provide comprehensive benefits, grant options, promote diverse work environments, and never describe themselves as “we’re like $UNICORN for $PROBLEM“? Because of the popular startup stereotypes, I often feel obligated to lead off conversations by defensively telling candidates about a company’s highly-realistic hours expectations and competitive salaries before describing the interesting technical challenges that should be the focus of the conversation.

RECONSIDER hopefully has shined a light on the fact that there may be thousands of startups like Basecamp that never get huge (perhaps never sought to get huge), yet still created great products that impacted users’ lives while providing opportunities and financial stability for both employees and founders alike. Maybe these are the real unicorns.

The Worst Developer Resume in the World

As someone who has been recruiting in the software industry for nearly 20 years, I’ve read perhaps tens of thousands of résumés. Good and bad. My experience prompted me to launch a part-time résumé review and writing business (Résumé Raiders if you must know), as I found that résumé services were both grossly overpriced and of poor quality.

There is one résumé type that I get at least once a day, and it’s unreadable. It is immediately recognizable once I open the document and see the first page, and my suspicions are confirmed when my eyes wander to the bottom and see the dreaded “Page 1 of 7”.

I’m not sure as to why, but I belive this style is more common among Java developers – although admittedly my sample size for Java is larger than for other language communities.

The Résumé

It starts with a “summary”…

Image title

So the résumé’sImage title summary is a half page long? The writer regurgitates every single technology they’ve ever used, puts them into bullet points, and has the audacity to call it a summary? This creates what we call a signal-to-noise problem, where the sheer volume of content makes it impossible for a reader to decipher what is important information and what is not.

I preach to all my résumé clients that a summary is the most important part. Why? Résumés are often initially reviewed by recruiters, many of whom are inexperienced and not the best at identifying talent. The summary is an opportunity to tell the reader exactly who you are without having to let the reader interpret your experience.

You want to hire a Python developer with at least five years of experience? If a summary starts with “Python Developer with five years of experience…”, that doesn’t give even the most incompetent recruiter the chance of missing the qualification. Keeping the summary clear and concise is the key.

So what’s next?

Image title

Thanks…but didn’t we just do this??? We’ve now read the first page of the résumé, and the applicant has mentioned every technical skill at least twice. I know what you’re thinking. This is an attempt to get the attention of those ATS’s (applicant tracking system) we keep hearing about. When it is assumed that the reader is not human, some may choose to repeat keywords in an SEO-like attempt to game the system. Does it work? Probably not, but I don’t think that is the reason behind this.

But let’s keep reading…

Image title

After starting off with a summary which was really a set of bulleted lists containing buzzwords, followed by a skills section which was just a categorized list of the same buzzwords, we come to the experience section which is the same list of buzzwords accompanied by a short description of what those buzzwords do.

The Problems

There are a couple problems here.

The first is that the reader is looking to quickly qualify or disqualify an applicant. When the reader discovers that the résumé is seven pages that seems to mostly be lists of buzzwords, that doesn’t provide much incentive to read it. The size is intimidating to a reader, which gives a negative instinctual reaction. Imagine a friend is relocating and asks if you can help with the move, and on arrival you see a garage full of barbells and bags of sand.

Even if it’s part of the recruiter’s job to review résumés and make a yes/no decision, this style résumé is a lazy excuse to just say “no”.

The biggest problem, for both the applicants and the industry at large, is that these résumés sometimes belong to good developers. I’m a strong résumé writer but a weak coder, and there are likely thousands of people who are strong coders that have no idea about résumés.

If your résumé bears any resemblance to what I’ve described above, do yourself a favor and fix it ASAP.

Teach Something You Haven’t Learned Yet

Last week I started training a new employee. I’ve been working solo for the past few years and hadn’t trained anyone recently, so having to thoroughly explain the fundamentals of my industry has helped reintroduce me to some concepts that I hadn’t thought about lately.

The training process got me thinking about the best speakers I’ve had in 15 years managing the Philadelphia Java Users Group, and how well some presenters were able to explain concepts that were entirely new to audiences. Even as someone who doesn’t write code at a high level, I left some presentations with a firm grasp of the concepts because of the speaker’s performance.

There were a handful of instances over the years where speakers volunteered to present a topic unfamiliar to them, adding that the task of creating a slide deck and preparing to answer audience questions was a good excuse for learning something new. These were situations where a speaker decided to learn a technology just so they could immediately teach it to others.

Image titleWhen I give advice on public forums like Reddit’s /r/cscareerquestions, in blog posts, or in private conversations, I typically encourage people to learn new technologies by building something they can then showcase to demonstrate proficiency to potential employers. I still feel this is sound advice, particularly for job seekers who may need a bit of extra material to get their credentials to the level of their peers.

I’ve never suggested that someone learn a technology with the end goal of then teaching it to someone else. Those who learn by building have a safety net in that they can “release” their demo when it’s ready. Studying a technology in order to teach it in a group setting usually provides a strict deadline, and also gives an added incentive with the desire to appear knowledgeable and professional during the presentation and Q&A that typically follows.

Next time you are looking to learn a new skill, consider lining yourself up to present to a local user group or even offer a company lunch and learn event. You may find the additional pressure may be the extra incentive you need to dive in.

The “Big 4”, GitHub, Bootcamps, and Rants – Conversations Overheard From the Kids’ Table

I’ve been on Reddit for the past few years, mostly giving advice in a subreddit (or “sub”) called CS Career Questions. The participants run the gamut of technologists, and on any given day you can see questions from high school sophomores asking which math class would better prepare them for a programming career to programmers in their fifties seeking input on how to keep skills fresh.

After participating in /r/cscareerquestions for about a year and doing a couple popular AMAs, I was asked to be a moderator. Mods have the enviable job of keeping content on topic, deleting offensive comments, and banning users (not to mention bots) who don’t play nice. As a mod, I’m now obligated to pay closer attention to the activity in the sub.table

I thought I’d share some observations on what I’ve noticed over the years, which may shed light on the thoughts of at least some in the next generation of engineers.

The Big 4, the Second Tier, and The Untouchables – When I entered tech in the late 90’s, the Big 5 was shorthand for the accounting firms (Price Waterhouse, KPMG, etc.) that had branched into tech consulting. Today the term Big 4 is used to signify the companies deemed to be the most select in the industry, and consists of some mix of Google, Facebook, Microsoft, Amazon, and Apple. Every college student seems to aspire to work for one of these.

Then there is a second tier of companies that are considered a half step down. Names in this tier tend to be newer companies like Palantir, Twitter, Netflix, SpaceX, LinkedIn, and perhaps one or two dozen other companies that most in technology will recognize.

If you listen to the conversations happening, these groups are the only acceptable employers to target. The second tier, which most in the industry would consider “elite” employers, are sometimes considered a fallback. Highly-selective firms have become safety schools, and many of these students don’t realize that the chances of being hired by even the second tier is not realistic for most of the population.

Industry veterans realize that most won’t end up in these 30 or so companies, but instead will work for companies their parents and peers won’t recognize. There is nothing wrong with aspirations, but it’s a problem when a high percentage of graduates feel they’ve failed.

Language/Platform Fascination – Because the group knows I recruit engineers for startups, I get many private messages asking me “Should I learn Node.js or Android?” or “Which pays more, Python or Ruby?“. I’m generally reluctant to try and answer these questions without some additional context. New engineers may not realize that they probably won’t be using the same tools or languages in five or ten years and how quickly supply and demand can change.

Self-learning, GitHub, and MOOCs – Many of the questions in the sub come from users who have a non-CS degree (or no degree) and are looking for a way into the industry. It reminds me of the push in the early 2000s for those without college degrees to get certifications in technology careers such as network administration or help desk. Today, programming is considered approachable.

The topic of self-learning comes from both those in the industry and those seeking entry. The value of personal projects is a constant conversation, although it’s hard to distinguish whether the newer engineers understand that the value of these projects should diminish as experience is gained. Bootcamps and MOOCs are relatively new concepts as methods to mint new engineers, and both seem to be considered as reasonable economic alternatives to a CS degree.

Recruiters, Resumes, and Networking – Based on the number of questions about recruiter interactions, resumes, etiquette, and professional networking, it seems universities might want to consider adding a course on these topics to the curriculum. Careers in technology have unique characteristics that are completely foreign to those outside the industry, and teaching some of these concepts before graduation would be helpful to students who clearly receive conflicting information from peers and family. Career advice for teachers and policemen isn’t applicable to technologists.

Expectations and Rants – When we have college graduates and rather inexperienced professionals being courted by multiple employers, it has the potential to create a class with unrealistically high expectations as to how they should be treated. If a recruiter from a Big 4 doesn’t reply to a job application or an email in a day or two, it isn’t unusual to see a rant. It’s a mix of legitimate complaints about industry hiring practices and concerns that they “heard during an interview that one engineer worked past 6PM” the night before.