Code Your Way to the Top: A Guide to Crafting the Perfect Software Engineer Resume

Are you tired of sending out resumes and getting no responses? It might be time to reevaluate your resume game. From weak and passive verbs to unnecessary jargon and cliches, there are a lot of common mistakes that I see job seekers make on their resumes. But don’t worry, I’ve got you covered. In this post, I’ve provided tips on how to make your resume stand out, including using strong action verbs, quantifying your achievements, and avoiding common pitfalls. So if you want to increase your chances of landing that dream job, keep reading!

As a hiring manager, I can’t tell you how many times I’ve been stuck reading a never-ending, rambling resume that just goes on and on. It’s like the document is trying to test my endurance or something. Trust me, no one has time for that. Keep your resume concise and to the point. Two pages or less is the sweet spot. Not only will it make your life easier (less time spent writing and editing), it will also show off your editing skills. Plus, let’s be real, no one wants to be the resume equivalent of a drunk, rambling uncle at Thanksgiving dinner. Keep it short and sweet, just like a good joke. And if you’re struggling to condense your experiences, just remember: it’s not the length of the resume, it’s how you use it.

And for goodness sake, please don’t get too fancy with your resume design. Trust me, no one wants to read a resume that looks like a circus poster. Keep the fonts and formatting simple and professional, and save the graphics and images for your LinkedIn profile.

It’s generally a good idea to avoid weak and passive verbs in a resume because they can make your writing sound less assertive and confident. Weak verbs do not convey a strong sense of action, and they can make your writing sound vague or passive. For example, “assisted with” is a weak verb that does not convey a strong sense of what you did. It’s much better to use a stronger, more specific verb that clearly conveys your contribution.

To really sell the “action words” use them in conjunction with quantifiable metrics to demonstrate the impact of your achievements. For example: “By implementing a new marketing strategy, I increased website traffic by 25% and generated $50,000 in new revenue for the company.”

Here is a sample of the best 15 action verbs that are particularly effective for improving the quality of a resume:

“Achieved, improved, managed, enhanced, increased, developed, expanded, improved, generated, reduced, transformed, streamlined, pioneered, innovated, and created.”

Here are some alternative phrases you can use instead of “duties included,” “responsible for,” “served as,” or “actions encompassed”:

Handled, performed, managed, led, coordinated, overseen, supervised, facilitated, and assisted.”

Using more specific and active language can help to make your resume more impactful and convey a strong sense of your capabilities and accomplishments.

Here are a few non-passive phrases that are particularly well-suited for technical positions:

  • Designed and implemented
  • Developed and maintained
  • Analyzed and resolved
  • Created and tested
  • Configured and optimized
  • Troubleshoot and repaired
  • Upgraded and maintained
  • Created and delivered
  • Utilized and supported
  • Developed and deployed

These phrases convey a strong sense of action and responsibility, and they demonstrate your ability to take charge of technical tasks and projects. They can be especially effective in a resume for a technical position because they show that you have the skills and knowledge necessary to successfully complete complex projects.

Also, I want to get a sense of who you are, and what makes you tick, so use a summary or objective statement to introduce yourself and your goals. This can be a few sentences at the top of your resume that give a brief overview of your background and what you hope to achieve in your career. I want to see passion. If I cant get a sense of your personality and why you are in this profession, don’t expect a call.

In addition to professional experiences, a candidate’s hobbies, interests, and leadership experiences can also provide valuable insights into their motivations and values. For example, someone who has volunteered with a non-profit organization or taken on leadership roles in team projects may be driven by a desire to make a positive impact and contribute to the greater good. These experiences can also demonstrate the candidate’s ability to work with others and contribute to a common goal. Including this information in a resume can help to give me a more complete understanding of the candidate and their potential fit with the organization.

Similarly, it’s also a good idea to stay away from business jargon or cliches in a resume because they can make your writing sound insincere or overused. It’s important to use language that is clear and straightforward, and that accurately conveys your skills and experiences. Jargon and cliches can make your writing sound artificial and can be confusing to readers who are not familiar with them.

Nothing annoys me more than a resume littered with the latest generation of techno-babble:

“Our decentralized, blockchain-based web 3 platform leverages artificial intelligence and machine learning to enable friction-less, stateless-less data interoperability, resulting in a paradigm shift in the way we consume and monetize digital content.”

Garbage! A “buzzword bingo player” or a “buzzword spewer” someone who is more interested in using flashy, technical-sounding language to impress others, rather than having a genuine understanding of what the words mean. This kind of behavior can be seen as superficial or insincere, and it can be off-putting to people who value genuine knowledge and understanding. If you DO fully understand the language — you run the risk of looking like a brilliant jerk — but it doesn’t matter because I don’t want to work with either.

Last of all, and this goes for the interview as well (and its hard for some and easy for others) —demonstrate humility.

Changes to ActiveRecord::Dirty in Rails 5.2

A while ago I wrote a small post on how to manually mark an ActiveRecord model attribute as dirty. Since Rails 5.2 has some fundamental changes to ActiveRecord::Dirty.

Specifically, three methods have been deprecated and changed in 5.2. These are:

  • attribute_changed?
  • changes, and
  • previous_changes

Using these methods in a Rails 5.2 application will now result in the following message (or a variation of it) being outputted in your logs:

DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead.

attribute_changed? and changed? remain the same when called within a before_save callback. But when used in an after callback there are new methods you should use instead, which the Rails Core Team believe should reduce code ambiguity of changed? before saving to the database: will_save_change_to_attribute? and has_changes_to_save?

In summary, if upgrading to Rails 5.2 and after modifying an object and after saving to the database, or within after_save:

  • attribute_changed? should now be saved_change_to_attribute?
  • changed? should now be saved_changes?
  • changes should now be saved_changes
  • previous_changes has no replacement, since the behavior for it changes.

And (optional; less ambiguity, more readable, but longer) after modifying an object and before saving to the database, or within before_save:

  • attribute_changed? should now be will_save_change_to_attribute?
  • changed? should now be has_changes_to_save?
  • changes should now be changes_to_save

NotImplementedError Must Have Battered Wife Syndrome

I’ve been doing something very wrong my whole life.  I think it’s time to confess and seek help.

You see, like so many developers I see the NotImplementedError class in various languages and think, to my self “I haven’t had a chance to fully implement this class, so in my methods that my colleagues call that I didn’t finish yet, I will raise that exception to let them know.”

I am ashamed of myself.  And it’s time to get help.

You see the actual purpose of the NotImplementedError (as defined by the Ruby docs) is:

Raised when a feature is not implemented on the current platform. For example, methods depending on the fsync or fork system calls may raise this exception if the underlying operating system or Ruby runtime does not support them.

ERMERGERD!  I am a terrible person. Abusing this error class just because  my sub classes cannot meet the contractual obligation of the super class.

And I know I am not alone.

So whats the best practice, then?

Well, in Ruby’s case it turns out the answer is super simple; don’t raise an error at all! Instead, document the expectation and if a subclass fails to meet it a NameError, or often its subclass NoMethodError, will be raised automatically.


Converting TEXT columns to JSONB in PostgreSQL

Recently I had a text field being used to store JSON data from my web application. I hadn’t yet discovered the amazingness of the PostgreSQL JSONB datatype.

JSONB is an amazing datatype because Postgres understands how to query the structure and the keys and values can be indexed.

So if you have a text fields you want to convert to JSONB (provided the existing data is in properly formed JSON already) You can change the datatype and convert the existing data using this simple SQL command:

alter table tbl_name alter column col_name type jsonb using col_name::JSON;

You may be inclined to covert the text using the to_json function like: ‘USING to_json(col_name);’ – BUT DON’T DO THAT! What happens with that is you get a single string encapsulating the valid JSON, containing your JSON. Effectively a double-encoding bug.  The former (casting the column to JSON is the correct way).