Adventures in academic advisory

This post is written for a faculty audience. It targets CS programs, which may be geographically distant from an established tech community.

I primarily develop applications using open-source tools, so my recommendations are informed by that industry and tool set.

In my experience non-technical considerations receive inadequate attention, but they often impact performance, so I emphasize them here.


To perform well in an interview and the workplace, a student must demonstrate an interest in the role, even if it’s just a connection with a personal interest.

David Byttow elucidates this well in his posts ABC: Always Be Coding and Four Steps to Google, Without a Degree. As an aside, his second post argues you don’t need a degree to compete effectively. I believe school, while not strictly necessary, provides a structure for learning and a solid foundation.

I recommend helping students discover and explore their interests, so they can then compete effectively for jobs aligned with those interests. Ideally, each student will find a career in which she enjoys going to work, and derives real, personal value from her contribution.

An academic program should encourage creativity and self-direction. Two software development tasks are rarely the same, and it’s often up to the developer to make an educated guess about which aproach to take. I recommend asking students regularly to describe what they would like to learn about and why, and including the resulting feedback in an academic advisory setting.


I recommend instilling a common sense principle: focus on providing value to a customer. A student can be his own customer initially. In an academic setting, the instructor can serve as the customer; assignments are the deliverables. Solving a problem for someone is personally fulfilling and makes business sense. This recommendation may seem obvious, but the highest-performing teams I’ve been a part of have been explicit about this goal, and I’ve seen other teams lose sight of it day-to-day.


We’re social creatures and software development is often a collaborative effort.

By fostering interaction with a diversity of people and ideas, a school can help a student refine her career goals. By including employers in this interaction, a school can expose students directly, and under the best of circumstances, to employment opportunities.

LinkedIn, Twitter, Facebook, and Github provide tools for interacting online with other developers without requiring everyone work at the same company. There are also activities like hackdays, unconferences, and meetups students can participate in to learn practical skills and meet like-minded people in the developer community. All of these are usually free. If these activities exist nearby, encourage students to participate. If not, schools can host these events themselves and support students by building a developer community around the school. Often a meetup just needs a room and some pizza. A school’s ACM chapter can help organize to distribute the work.


I recommend students create a LinkedIn profile and populate it fully. Recruiters pay LinkedIn for access to profiles. By maintaining a profile, students are proactively providing recruiters with the most up-to-date professional description of themselves.

LinkedIn is also convenient for keeping in touch with colleagues, and contacting them descretely regarding employment opportunities. I recommend students connect on LinkedIn with professors, and the students they would be willing to work with.

An alternative is to simply maintain a list of the people a student would want to work with again.

Twitter, Facebook, and Github

I recommend students use these services to listen to the thoughts of working developers, and reduce the perceived distance between the worlds of academia and industry. This is especially relevant if the student is geographically far away from the area in which he would like to work.

For example, suppose a student would love to work on high-performance, backend services at Twitter. I would recommend he:

  1. search for “twitter open source”
  2. Observe Twitter maintains several projects on Github
  3. find all the people listed under “Organization Members” on Twitter’s Github page
  4. follow all of them on Github and Twitter

By listening in on a group of people like this, the student will have a much better sense for the Twitter engineering community, and whether or not it’s focused on his areas of interest. The NPR program Help for Job Searching with Social Media (summarized on storify) describes this well.

Hack days

A hack day is a day devoted to creating and launching something that, for whatever reason, isn’t on the roadmap, i.e., if you had a day to build anything, what would it be? (The answer to this question is also an incredibly important signal regarding career choice.) Some hack days have a contest at the end. Yahoo! runs hack days around the world that often span a weekend. Twitter runs a quartlery hack event that lasts a week.

Given the limited timeframe, producing a functional proof of concept is valued over rigor. Developers often work through the night. Hack events are a lot of fun.

Variations on the hack day idea include Random Hacks of Kindness, which provides a way for developers to contribute to disaster relief efforts, and CityCamp Hackathons focused on improving public services.

Hack days are very common within tech companies as a way to foster innovation, expand skill sets, and meet new people. For example, Twitter Hack Week, Facebook hackathons, and Netflix hack day.

Participation goals:



A BarCamp is a self-organizing conference, a.k.a., an unconference. Everyone is welcome, and anyone can propose a talk. A great assignment would be to attend a local camp, present a brief talk on an area of interest, and report on the experience.

barcamp pic 6, by Tech Yizu

barcamp pic 6, by Tech Yizu (“Signing up to give a talk at Barcamp! Anyone can give a talk at Barcamp”)

The official BarCamp site maintains a list of upcoming BarCamps, and links to helpful resources for running a BarCamp.

If you are hosting a camp, survey students to see which employers are the most sought-after, and then reach out to those companies for space and/or sponsorship. In addition to recieving assistance, the sponsor may insist on representation at the event, putting students in direct, but low-stress contact with employees, who are often engineers themselves.

Participation goals:


Tech talks

Tech talks are a great way for students to learn about interesting and novel technologies, meet representatives from the company or school hosting the talk, and meet other like-minded developers from the local community. I recommend all universities encourage students to attend talks, and/or experiment with hosting talks.

Getting started:

  1. search for a topic related to any area of the curriculum requiring support
  2. attend a meeting to get a feel for the group
  3. suggest a meetup at your location

Participation goals:



From the CoderDojo website’s about page

CoderDojo is a movement orientated around running free not-for-profit coding clubs and regular sessions for young people.

At a CoderDojo, young people learn how to code, develop websites, apps, programs, games and more. Dojos are set up, run by and taught at by volunteers. Dojos organise tours of technology companies, bring in guest speakers to talk about their career and what they do, and organise events. In addition to learning to code, members meet like minded people, show off what they’ve been working on and so on. CoderDojo makes development and learning to code a fun, sociable, kick ass experience. CoderDojo also puts a strong emphasis on open source and free software, and has a strong network of members and volunteers globally.

As in a school for martial arts, CoderDojo defines a set of belts (white, yellow, red, black) for coding ability. Students ascend in rank by learning technologies and skill-sets such as JavaScript, Python, game development, and mentorship.

CoderDojo started in Ireland, but has since spread around the world. The website maintains a list of locations. If there isn’t one in your area, consider starting a dojo for students and/or the community.

Additional information:

Participation goals:


Programming competitions

The ACM International Collegiate programming contest and the International Olympiad in Informatics are two international programming competitions.

I don’t have experience in either as a competitor, but I have interviewed people with experience, and they generally perform very well.

Participation goals:



I recommend students have awareness of a variety of compiled languages, but develop proficiency in one. Based on my experience, I would recommend Java. A student should be able to say “I am proficient in writing, reading, testing, and debugging in Java”.


As with compiled languages, I recommend students have exposure to several interpretted languages, but develop proficiency in Python. Python is a widely used tool for a variety of applications from system scripting to web app development, and its terse, self-descriptive syntax makes it convenient for interview whiteboarding. It is close enough conceptually and syntactically to Ruby, PHP, and JavaScript that a student can compete effectively for roles using any of these.

Reading, testing, debugging, committing

Interns and new grads generally have very little experience reading other people’s code, testing, debugging, or working with a source control tool. This is quickly picked up on the job, but a student with some experience has a competitive advantage, and these tools are often already used in an academic setting, albeit perhaps not in a structured way. The goal is to make it easy for an interviewer to imagine working with the student. The closer a student is to being a productive member of the team, the better.

Github provides review tools, which are free and easy to use. For perspective, students can compare features with comparable tools like reviewboard and gerrit.

If possible, incorporate code review into project evaluation. For example, students can submit projects via reviewboard; projects must have a “ship it” from a teaching assistant before the professor will grade it; assistants can iterate with students via the review. Consider defining “review teams” composed of 2-3 students who can review each other.

For testing, I recommend a basic unit test framework such as Java’s JUnit and Python’s PyUnit.

For debugging, I recommend jdb or gdb, on the command-line or via an IDE. IntelliJ provides a free communitiy edition with an excellent debugging interface.

For source control, I recommend git for a few reasons:


I recommend all CS students create a Github account for a few reasons:

Note: please encourage students to be vigilent about maintaining the code that is viewable online. We want a recruiter’s first impression to be a good one.


See recent article on Vietnamese education wrt Google’s hiring criteria:

There is no question that half of the students in that grade 11 class could pass the Google interview process.


Thoughts? Suggestions? Hit me up @erikeldridge


This work is licensed under a Creative Commons Attribution 4.0 International License.
Creative Commons License