in Culture

The Other Side of the Interview

Ever wonder about the submission process when you apply for a software developer job? We’ve all had delays and/or setbacks where we end up looking to the stars to ponder aloud, “Why didn’t my resume get a response?” Or, “I thought I did fantastic – why didn’t I get an offer?” “What did they mean when they said I wasn’t a good fit?!”

tumblr_inline_miqtxz9Obi1qz4rgpTech companies come in all different sizes with different cultures and philosophies; there is no single ‘best’ way to create a resume, apply for a job, or approach an interview, so I won’t attempt to create a general guide that applies to all tech companies. Franky, that would be boring and not very useful, but I believe some insight into our hiring process may help you—not only in applying to CoverMyMeds—but with many other like-minded tech companies.

Let’s begin with resumes. I’ve been handed some really, really bad ones. No one should have a resume longer than two pages. One page will suffice, two pages is acceptable, but any longer and it tells us you may not know how to prioritize and properly scope a solution. Plus, a long resume takes more time and is more difficult to review. Just keep this in mind: well-designed resumes have a lot in common with well-designed code.

Even though Microsoft Word is universal, it does not provide complete control. What looks great on your system may not look good on one of ours. Instead use a PDF or even a hosted HTML document. We are a web-development company so anything on the web is a plus.

We really like resumes that include:

  • Basics of your education – major, years spent, and degree(s)
  • List of technologies where you have reasonable proficiency (not just familiarity)
  • List of jobs and a couple of sentences on your role and what you accomplished
  • List one or two lines with outside interests. We like to know that you are an interesting person who can do more than write code. Are you a skydiver? Are you the lead singer of a band that only plays songs about tacos? Tell us about it!
  • Link to your GitHub account. You have one, right?
  • Link to your website. You have one, right?
  • Link to your Twitter account with interesting tech-related posts

We really don’t like resumes that include:

  • Listing Microsoft Office as a skill
  • Listing HTML or CSS as “languages”
  • A history of changing jobs every year or two — but it is what it is so don’t hide the truth. If you were consulting, make that clear.
  • Some kind of graph that quantitatively rates your skills — this is very subjective and looks made up
  • Typographical or spelling errors — proof read, proof read again hours later, and then have a friend proof read

Advice on cover letters: we look for something simple and to the point. The cover letter should be well-written and simply introduce yourself and your interest in the job. It should not go on effusively about why you think you are a great fit — this should be evident in your well-crafted resume. Also, just like your resume, proof read and proof read again.

Now let’s delve more into what we look for in the person behind the resume. For less-experienced developers, particularly college and bootcamp students, we look for people who have done a lot of things outside of their normal coursework. For instance, hackathons, online tutorials, creating websites for family and friends, and open-source contributions.

For more experienced developers, we look for real accomplishments in solving problems and bringing successful products to market. We also look for things that were done in a team setting either with other developers or with customers or business people. We also like to see:

  • A GitHub account chock full of original and forked repos and commits. The more green on your Contributions map, the better.
  • Your website that is your personal brand. It should have links to the things you’ve worked on and they should be impressive.  It should also have a nice design, even if you are personally not a designer.
  • A blog or a link to your twitter account where you have interesting things to say, either technically, culturally, or both. You should go easy on things that raise cultural flags such as f-bombs and politically-charged comments.
  • Pairing experience
  • Conference talks on interesting technical or cultural topics
  • A LinkedIn account is a nice bonus, but not required

We also use Gild to get ratings, data. and links on developers. If you can score a trial login with them, it’s worth it to see how you are rated. There are other similar services such as HackerRank.

In our initial interviews, we look for professionalism, technical expertise, and cultural fit. Let’s start with the latter—because our development process is highly collaborative, we want to see that you are a good communicator and are easy to work with. We usually end things quickly when someone trashes their current or former employer, or appears to be generally negative.

Evil-Dog

No.

Professionalism comes through in the whole interview process and can take on many forms, but primarily we look for timely communication throughout the process and — this is hugely important — well-thought-out questions on our business, culture, and tech stack.

Regarding technical expertise, we look for knowledge, passion, and understanding in the tools of the trade during the interview. We hire primarily full-stack developers, and while we expect candidates to be stronger either on the front or back end, we look for proficiency throughout the stack including good design sensibilities, solid knowledge of security and how to write secure web applications, and a good knowledge of web architectural patterns. Extra credit to anyone who works Roy Fielding, Brendan Eich, or Tim Berners-Lee into the conversation.

Since most of the software-developer job is writing code, our interview process is heavily biased towards, well, writing code. We expect people to be proficient in the web stack from the database up to the browser. Proficiency with an MVC web framework is a must but we don’t require any particular language – we want candidates in the interview process to be able to put their best foot forward. They can always learn our tools later.

The people we hire do the following during the coding interviews:

  • Get things working
  • Work under time pressure not just because they are fast but because they are good — they can move quickly because they do it all the time
  • Follow directions
  • Ask lots of questions
  • Accept guidance
  • Show confidence, yet humility
  • Check their work*
  • Exhibit good design sensibilities and user-empathy
  • Break down problems well, identifying the challenges and edge cases early
  • Talk through problems logically — i.e., they are good to pair with
  • Prioritize features well
  • Keep a backlog of unimplemented features or things that they would refactor if they had more time
  • Be able to tell us what code they are proud of and why, and what code they wish they had not written and why
  • Understand the sacrifices that they made in the interest of time and can explain them

[* A note on testing. Because our interviews are done under time pressure, there is typically not time for TDD or extensive testing. But we very much appreciate when people manage to sneak some in or can explain exactly what they would do of they had more time.]

So, there’s a quick peek behind the curtain at the way we do things at CoverMyMeds. Whether you plan on interviewing with us or someone else, I hope this helps provide you with the proper ammo and insight to rock your interview and get your dream job.

Write a Comment

Comment