The Tech Resume and Interviews

Resumes

A good entry-level resume comes from many iterations and refinements over the course of your time here at Williams. A first-year’s resume will look very different from a senior’s resume. Below is more information about building your resume.

Build a Log of Noteworthy Projects

During your time in college, you’re going to be a part of many projects in wide-ranging fields. You could draw from your academic courses, co-curricular activities, personal hobbies, or summer experiences. As you go through each project, reflect and document your hard work so that, when the time comes to update your resume, you have a list of interesting activities, tasks, and skills to showcase. Think of your resume as exactly that: a showcase of your awesome accomplishments.

Tailor your Resume Toward the Position

Now that you have a list of past projects and their descriptions, you can leverage that information to craft your resume. Read the job description for the position that you’re applying for carefully, and pick out the projects that you think are most relevant for the role. Review our resume guide here!

Craft Effective Resume Entries

For technical resumes, that means using detailed terms (you “deployed a server using a NodeJS backend tied to a NoSQL database with a front-end powered by React”, not “built a custom website”). Whenever possible, you should also include metrics that showcase the effectiveness of your work (you “crafted an ARIMA model that had a 6-month forecast accuracy of 97%”, not “built a statistical model that made better predictions”).

Many large firms use automated tracking systems in order to filter applications by keyword. Ensure that language used in the job description appears on your resume. For example, software engineers should consider adding data structures and algorithm design since those are skills that companies are looking for.

Here is a standout example that you can use to inspire your own finely-crafted resume:

Interviews

Though interview sequences ultimately depend on the employer, many tech interviews have a common structure: Application, then Phone Screen / Online Assessment, then Final Interviews. The best way to practice for an upcoming interview is to practice with someone else. The ’68 Center has a peer-to-peer mock tech interview program to assist with the logistics – keep an eye out for emails from us about it. Also, take a moment to review our interview guide here. With that said, here are some things to consider:

Phone Screens and Online Assessments

Be sure to find a quiet location for these, and ensure that you can keep your phone, headphones, and laptop charged at that location. Call quality sometimes suffers deep in Schow Library, so it’s best to check if you can get reliable communication quality at your testing location. During phone screens, it is essential to over-communicate your solution, as you do not have the benefit of an in-person interaction or whiteboards. On that note, be sure to have a pen and paper handy for note-taking or brainstorming.

Technical Interviews

In a technical interview, you will be given a number of challenging questions to solve. The interviewer often under-specifies the question so that you can ask questions to construct the full picture. Ask clarifying questions so that you fully understand the question. Do not start coding immediately. Take time to think (and talk) the entire solution through, and once you have a plan you can begin coding. You will be expected to write up clean, concise, efficient code to solve the problem. Here are some good questions to ask during the process:

  • How did I analyze the problem? Can I find a data structure or algorithm that helps me solve a part of the problem?
  • Did I miss any special cases? Oftentimes, there are corner cases that need to be dealt with separately.
  • Did I produce working code? Did I test the code? Is the code clean, easy to read, and can it be maintained?
  • Did I explain ideas clearly? Would I be considered a collaborative and nice person to work alongside of? Did I verbalize my thoughts? Remember: you’re being tested to see if you’d be a good fit on the team. Much of the work in the industry is collaborative, and a pleasant experience in a cooperative setting like an interview is a good sign of a strong hire.

It’s often useful to draw pictures to explain your approach. Your interviewer may give hints as to how you might solve the problem in a better way, but only if you communicate where you are at in the process. Summarize your approach and verify its sufficiency with your interviewer, then proceed to write clean, error-free code to carry out the problem. If you get stuck on something small (ex: is it ab() or abs()? Do I use curly or square brackets?) ask your interviewer if they know or if you can look it up. While it’s best to avoid these situations when possible, it is always better to admit you don’t know something small and end up writing a great solution than to get stuck on the simple thing for 30 minutes.

These challenge questions often share the same underlying algorithms, and by mastering a set of specific skills/techniques, you will be ready for anything the interviewer throws at you! According to students, alumni, and experts in the field, these are some platforms to get yourself familiar with coding interviews:

As a final note: consider the experience as less of an interview and more of a discussion. Your interviewer wants to see you succeed and can help you get to a solution if you communicate well.