Objective
The objective of this post is to detail how to highlight skills and experience in a resume that enhances one’s chance of landing an interview. Additionally, it talks about the ideas behind what makes a candidate successful and the mindset one should have during an interview and the general job application process.
It was written mostly from a software engineering perspective, but main concepts are meant to be generic enough for a wider audience.
Perspective
The most important thing you can do when writing a resume or interviewing is to put yourself into the shoes of the person looking to hire. Recruiters, hiring managers, managers, tech leads, etc. don’t necessarily have the same context that you do about your previous experiences or projects.
In the hiring process, you want to bring someone on a 🌈journey🌈 of your experiences.
With that in mind, these are the main ideas to take into account when writing your resume.
It’s basic, but the purpose of every single thing you place into your resume is to give them insight into the tasks you’ve worked on, the environment in which you’ve worked, what skills you’ve displayed while doing so, what principles you care about (in terms of your work), and any other background context that may be important.
Ensure that these points are qualitative and think about what exactly you’re trying to highlight in your example. Well thought-out points should intrinsically showcase the concepts you care about, while also showcasing the value you brought to others (ie: your coworkers, the clients) or the product.
This may be surprising, but in a lot of cases, many recruiters aren’t necessarily technical. I’ve personally been in many initial interview calls and screenings where the recruiter would be completely lost if I suddenly dove right into what I did technically. Even though this is the case, they still require a reference point to gauge your accomplishments. That’s why it’s so important to provide quantifiable values on your resume. Numbers are a universal point of understanding and anyone can grasp the scope of what you’ve done.
Even in the technical portions and conversations, the tech space is vast and wide, so you should always provide enough context for them to understand what it is that you’ve worked on. Give them a baseline and share a common understanding first. Only then can you highlight your accomplishments. The whole point is for them to grasp what you are communicating.
Just remember, this whole process is with people and you are having a conversation with them on your experiences.
Practical Examples
Background Context
Example: For co-op, Alice worked at a SaaS (software as a service) company which focused on dashboards that monitored the health and performance of applications.
The interviewers are curious about you and what you’ve experienced, so this gives the other person knowledge of the company you’ve worked in and what sort of space you’ve been exposed to.
Already, they’re trying to relate to how your knowledge may fit in with what their company may be doing. For example, many companies don’t necessarily talk about monitoring and alerting (ie: logging and tracing data through an application), because it’s more of a chore to do than a cool, client-facing feature they’re working on. Yet, many, many, many companies should all do monitoring and alerting. Already, they may positively think that you have some knowledge in this area. Or maybe they’re a more inexperienced company that doesn’t think about emergency use-cases and maintenance yet, but perhaps they have a client-facing dashboard and so they still like that you’ve worked on them before.
Regardless, it’s always good to give a quick blurb about the company and what the product you’ve worked on does. You can keep it short and sweet if you’d like. If they’re curious, they’ll ask more.
Environment & Skill
Example: Alice was part of a tight-knit team of 5 on the front end web application team. They participated in 2-week sprints that included meetings which planned and delegated tasks to every member on the team. She also collaborated closely with the marketing research team and designers to produce the screens and user stories.
Whether you’re applying to a large company or a startup, most engineering teams are around 3-6 people. So the fact that you can work together within a framework and understand the process is a positive signal. Oftentimes, employees have to collaborate with teams across the company who all have differing views and motivations. The fact that you can communicate your team’s needs and understand another team’s needs is another positive sign.
Quantifiable & Qualitative Tasks
Example: Alice utilized React in order to create 10 responsive screens and 30 re-usable components. This included UI which cached user data used across every page for an efficient and seamless user experience.
This highlights many things.
The obvious one is that the interviewer can gain perspective into what language (hard-skill) Alice uses and can put a number to her effective output.
Less obvious, but I’d argue more important than the first point are her principles. These set her apart from the pack. Think about the keywords she uses. This candidate values and thinks about the clients of the product when she talks about responsive screens and seamless UX. Companies want their users to try and continue to use their product, so they must develop applications that are customer-centric and have a good user experience. Otherwise, they lose their hard-won, paying customers. Once again, this shows she possesses an important skill — perspective. Re-usability in code is a sign of a competent developer. You never want the same code repeated over and over again in the code base if you can help it. Valuing best coding practices is what differentiates a good vs mediocre/bad software engineer. And I’m being very honest when I say that this industry has a lot of mediocre software engineers.
Lastly, for the more technically-inclined interviewer, caching data shows that she cares about what most engineers care about — efficiency. Instead of making requests to the back-end every time the user navigates to another page, by caching it, there only needs to be a single call for all the pages to utilize this data.
Summary
It is your responsibility as an interviewee to give context to someone who has no idea as to what you’ve done. You want them to understand what you bring to the table. Give details on:
— Background.
— What environments you’ve worked in.
— What hard and soft-skills you displayed.
— What values you possess.
— What tasks you’ve done.
— Provide both quantifiable and qualitative values.
Breathe! On the other side is a just another human being. If they’re not an absolute twat, they’ll understand that you’re probably a little bit nervous. Prepare, be confident in the facts of what you have accomplished, and have a conversation!
Principles
Why this is important
While I can only speak about engineers, I’m sure this is the case with many other people in various positions. Lots of people tend to be overly concerned on hard-skills, such as programming languages, frameworks, and technologies. However, it is the soft-skills of the people around you — those who are able to communicate, collaborate, possess attention to detail, have a desire to excel, etc. — that make a work environment enjoyable and productive.
The overall competency of someone is not solely their technical expertise or prior experience. It all depends on their general attitude, how they deal with tasks, challenges, and people.
Every company has teams, so more likely than not, you are going to have to work in a team. How you engage in conversation, communicate, and present ideas are fundamental skills to every person.
The language, framework, and technology one uses in a workplace can change. But something that applies to all companies are principles, such as best coding practices. A lot of engineers don’t explicitly say this, but they all want things such as:
— Readable code that every developer can understand.
— Good naming of variables and functions. This is surprisingly very challenging.
— Side tangent: when you get the chance to name a system, make it ridiculous/funny, so that developers who read your code get a laugh. I was so close to naming my company’s latest system “BOB”. I immensely regret not doing so.
— Small, atomic, easy-to-use functions.
— Defensive programming that can run through use-cases and preemptively capture bugs that may break the system.
— Ensure bad and malformed data is caught as early on as possible.
— And if you’re a back end engineer, just constrain the shit out of your database tables (think through use-cases and utilize both unique and compound constraints).
— Understanding design choices.
— Later on in your career, you may be responsible for architectural design. You’re gonna need to understand tradeoffs between database types, monitoring and alerting, availability, bottlenecks, security, etc. This is just a minimal list of the concepts I had to think about for my latest project. which demonstrates that this stuff really is important and is actually used in industry. So if you’re ready to step up your development game by learning system design, this is a great starting guide.
— From what I’ve seen, you actually use design patterns more than algorithms… Seriously, algorithm questions in interviews are useless.
— Perspective of what each actor wants in a system. Examples include:
— Users: intuitive and easy-to-use UI/UX.
— Business side: Features for administrative usage. If they’re sales, something that looks impressive and robust enough to help them sell. Many engineers struggle to showcase work that isn’t front end, so a tip is to present ideas and principles that they can understand. Such as security, cost, reliability, alerts for when services (yours or other microservices your system utilizes) go down.
— Maintainers: Monitoring and alerting.
— Developers: Feasibility and performance.
— DevOps: Understand utilization of different environments (ie: development, staging, production) unless they’re Meta.
— DevOps/Developers: Pipelines to automate stuff, because manual deploys and order of operations for scripts, etc. can get substantial. It’s also useful if you have a sizable amount of developers and you don’t want them to care about DevOps.
— Documentation.
— I cannot stress enough the importance, yet lack of, good and clear documentation!
— Diagrams and pictures count as documentation and are so, so great.
So step back and take stock of what general skills you bring to the table that aren’t dependent on a language, framework, or technology. Showcase them on your resume and interview.
While interviewers care whether you can do the job you applied for, more than that, they care if you will be a good fit and that they want to actually work with the other person.
Curiousity
While work is not the end-all-be-all, there are 168 hours in a week.
Activity | hr/wk (roughly) | Static |
Sleep | 49 | ☑️ |
Life Necessities (ie: brushing teeth, showering, eating, etc.) | 28 | ☑️ |
Black Hole of Time™ (ie: doomsday scrolling, buying groceries, parking your car, answering calls from your needy mother) | 14 | ㅤ |
Hobbies and Interests | 37 | ㅤ |
Work | 40 | ㅤ |
Say you somehow get 7 hours of sleep a day, so you’re asleep for roughly 49 of those hours and life necessities take another 28 hours. Then assume you spend 2 hours a day doing dishes or blow-drying your hair or photosynthesizing or whatever. I like to call it the Black Hole of Time™. Boom! You actually spend more time working in a week than on hobbies and interests. If we only include waking hours, let us calculate how much of a week you’re at work for:
You’re in an office or your home office for almost 44% of your waking hours!
Where am I going with this?
Other than giving you an existential crisis, I want to emphasize that it should be important for you to enjoy work, since it takes such a significant amount of time during the prime years of your life!
Take as much initiative as you can in order to ensure you’re not stuck hating 44% of your week. You should care about how the company and team will treat you. You should care about what you work on to some extent. You should care whether the processes and how you work is enjoyable or not. So try to gather as much data as possible on them.
A great way to do so is to ask clarifying questions during your interview.
Interviews are a two-way street. You are also interviewing the company you’re working for.
Clarifying Questions
There are advantages of asking clarifying questions:
— They’re the medium in which you are able to get information on what it’d be like to work at this company.
— It shows the interviewer you care about the company, product, team, people, and your place in it.
— What you ask can show you have some personality.
— In some cases, the questions you ask are able to show your maturity in a profession and what insight you already possess, or want to know about.
Some questions that’ll fetch you good data
— What does your onboarding process look like?
— How do others share knowledge? Is there mentoring available?
— How do teams interact for the product, process, operation? (Ask one at a time)
— What day-to-day tasks do you [the interviewer] do?
— What sort of processes does the team I’d potentially be joining have in place?
— What project does the team work on? What is its purpose? How does it fit into the bigger picture?
— What has the team released last/this/next quarter?
— What does the team maintain or fix?
— (More relevant for large companies) What’s the hierarchy like? Especially for what affects your team.
— (More relevant in smaller companies, but still relevant for big corporations) Is there a vision that the company wants to achieve? In the near future? Further on?
— (If it’s a startup, the 3 Rs) How much did you Raise in your latest round? What’s the Runway? What’s the current Revenue?
These are some things I’d personally be interested in no matter the company. But, don’t just ask questions for the sake of it, try to think about what you’d like to know more about. Actually be interested, be invested in your future career, care about what it’d be like working here.
Closing Thoughts
The job application process is long and arduous, it’s difficult and hurtful to receive rejection. I’ve been there a painful amount of times.
But the best interviews for me were ones that were conversational, regardless of whether the interviewer focused more on soft-skills or more technical skills. I loved analyzing the company and trying to understand the systems and processes they had in place or what they actually did. I’ve progressed in many interview pipelines, advanced through many stages, and gotten intermediate software engineering positions just from having conversations.
Of course, the technical conversations include a lot of… Well, technical knowledge that you can only really get from experience. It’s probably why interviews for co-op and junior positions are so dumb impractical and focuses on stupid algorithm questions. Because most people don’t know how else to assess a student or new graduate without asking about what CS majors learn in school. It’s very unfortunate, because knowing how to reverse a linked list or memorizing BFS (breadth first search) is not an important thing in your professional career. My belief is that if you have a baseline knowledge of certain concepts, such as data types, how and when to utilize each, how to analyze basic runtimes, maybe know certain algorithmic patterns (though design patterns are much more important imho), and some other fundamentals. Then with the right mindset and a good personality that is eager to learn, you have the potential to become a competent software engineer.
What is important and stays relevant in all levels or roles you’re interviewing for are a person’s general soft-skills and principles. So make sure to place importance on these things and hash those out.
Good luck.