We’re hiring a bunch of engineering roles here at SketchDeck, and quite a few applicants get rejected due to the projects they attach to their application. I want to share the reasons we reject them, and as an applicant, what you could do differently.
SketchDeck is a graphic design service powered by a sophisticated online platform. We’ve clients and designers all around the world collaborating through our software. I’m David, one of the founders and CTO/Product Manager.
A whirlwind history of engineering applications
Previously, engineering applications followed the traditional pattern: A résumé and a cover letter to the hiring manager.
However that’s changed a lot over the last ten years. Attaching projects and GitHub profiles to applications is a relatively new phenomenon that’s rapidly grown in popularity:
Taking a very unscientific approach to charting this, google search trends for “GitHub résumé” gives a rough picture of the rising popularity:
Thanks to GitHub and simple, affordable cloud hosting it’s now easy for engineers to share their code and creations with future employers. This is similar to the traditional designers portfolio, except now there are lines of code and interactive apps to play with.
Common problems with projects on engineers’ résumés
Unfortunately, a lot of applications I receive end up rejected after looking through the projects attached to them.
When reviewing an application I’ve a few questions in my mind: “Is this person smart?”, “Does this person get things done?” and “Is this person interested in what we’re doing?”.
All too often, projects are so broken/low quality that they portray the applicant as someone who does not care enough about doing good work and could not be relied upon as a team member.
Here’s a list of the common problems I see:
URL does not load
A dead link is like having a typo in your résumé. It always makes me feel sad after clicking on a link, getting excited to see the project, then finding it doesn’t exist.
App is very broken
Some résumé projects I open in my browser are so broken that they are not usable. Any functionality that you have slaved to produce is lost in a sea of broken buttons and missing content. This is worse than a non-loading URL: now it’s clear that your work is definitely of poor quality.
A related issue is that the app is only half written, but has the UX for the envisioned functionality. This leads to lots of controls that do nothing, missing content and “work in progress” signs. The visitor has a jarring experience, uncertain whether the app is intentionally or mistakenly not working.
Quite a few projects I open are functional, but do nothing of interest. Often they’re a coding-bootcamp exercise in using model-view-controllers and url routing, where they look like an app (it has four different pages!) but do absolutely nothing. Sometimes they are over-engineered list managers.
Whilst this is clearly better than outright broken, it is not a good advertisement of your creativity and ability to solve real world problems.
Think of this little app as a giant opportunity. You have the undivided attention of your future dream job and manager, and can show them anything you want. Be interesting! Teach them something cool, show them something beautiful. Feed their inner curiosity. Make them smile or laugh.
Confusing UX and bad visual design
As an engineer you’re possibly better at coding than designing interfaces. Therefore it’s natural your projects will have had more focus on their code than their looks.
However, when I visit your app, the UX and visual design dictate 80% of my experience. One of the reasons that graphic design services like SketchDeck exist is because people cannot help but to judge based on visual experiences. Therefore, it’s important to put time into (and seek help when neccessary) the UX and visual design.
Require a login
Googling the topic suggests people spend between six to thirty seconds checking out résumés. It’s likely that anyone reviewing projects attached to résumés has a similarly short attention window (I know I spend about 15 seconds clicking around unless something engrosses me).
Therefore don’t put up unnecessary barriers. It’s great you know how to handle authentication, but now’s not the time to stress that credential (maybe unless you’re applying to Okta). You are probably stopping people from seeing the rest of your work. Instead, try having a guest account, or removing the concept of users/login all together.
What does a good project look like?
The best projects I see on applications are viable apps in their own right. They may be really small, but are complete in what they try to achieve and they are polished.
Data visualisations make good projects because they’re typically interesting, look pretty and usually fun to play with. Similarly, games can be good as they’ll entertain the visitor and look good too. Both of these types of application can be kept quite small. Finally, mash-ups between different APIs can be interesting (e.g. a Slack plugin to send SMS messages, or an online chatbot that’ll tell you jokes from Reddit).
How to make it look good
It’s important to make your project look good, but that’s easier said than done. There are some quick hacks that can get you a long way:
- Keep it simple — avoid extraneous controls, colours, fonts, and keep it plain and focussed on just the most important controls.
- Be consistent — a surprising amount of polish comes from consistency. By consistency I mean every button has the same look and feel (it’s ok to vary colour depending on function), fonts are always laid out the same size with the same margins.
- Find a good UI skin — there are tons of cool themes available free online for most major frameworks. Find a good one and use it consistently throughout your application
- Ask design-minded friends for feedback
Your app doesn’t need to be perfect, but being neat and presentable in everything you put forward in an application gives you the best chances.
The bigger problem
Projects and GitHub profiles have now become expected on résumés. However, it takes a lot of time to build something impressive . The reader of your résumé will be used to using polished apps and big open-source projects, so their bar for quality is really high.
As the applicant you’re being expected to create a world-class app/codebase, in your free time, potentially whilst being unemployed, as a team of one. It’s tough.
I totally appreciate the effort being required for these projects and am happy to look past blemishes and limited functionality. It’s really impressive when an applicant has set out to do something well (no matter how big or small) and delivered on their idea. It’s often clear that they learned valuable skills whilst doing it.
Think about what projects you’re putting on your résumé and only include those you’re really proud of. If you’re creating a portfolio project, think about what will be interesting and what fits into the amount of time you have. Expect to spend half your time polishing it. Then finally, once it’s complete, share it and be proud of it! It may quite possibly get you a great job!
I hope you enjoyed reading this — as we try new things and learn from them we’ll continue to post those experiences here on Medium. If working for one of the most innovative design services in the world interests you, check out our jobs page, we’re hiring.