Adventures in academic advisory
How can students in a standard CS program prepare for the job market, and how can faculty help them prepare, in a way that’s efficient for all involved (students, faculty, industry)?
Tldr: Faculty and industry should standardize approaches (to scale and avoid corporate bias) and provide material support, eg scholarships, resources and jobs (to avoid institutional bias in traditional hiring). Students should focus on academic performance (implicit interview prep) with a career goal (aka “passion”) and collaboration (we don’t work alone) in mind.
Software development has a large collaborative component. Soft-skills like interviewing, resume tuning, mentoring, reviewing code, etc are extremely important, but not formally covered by a standard CS curriculum. A regular meeting devoted to this enables students to develop these skills and helps scale administrators’ time by allowing industry representatives to drop in with minimum coordination. CSUMB’s ABCs is a great example.
Accelerate cultural normalization by hosting a showcase at the end of the summer intern season in which interns can share their experiences with other students. CSUMB’s 2017 CS internship symposium was a great example: each intern presents a very brief overview to the whole group in a “firehose” format, an industry representative presents a keynote and then the group breaks into a poster session.
Academic advisory panel
Enable industry to describe needs in a scalable way by hosting an annual panel and inviting industry to attend.
Industry can scale university hiring by empowering employees to identify and advocate for campuses and team up with other advocates. Help these teams by providing academic content (for teaching classes) and material support to relay to students, eg scholarships, technical resources, on-campus interviews, etc.
Nurture the tech community near campus by hosting events like hack days, unconferences, and meetups.
One thing well
The “one thing well” phrasing comes from Unix philosophy, but I think it works for career planning too. Pick something interesting to you and bias towards it, eg I want to develop mobile apps. Use this to guide your career, eg the classes you pick, questions you ask, interview questions you practice, code you push to github, tldr on your resume, meetups you attend, projects you volunteer for etc. This is what’s described as having “passion” for a topic, or “goals” :) You can always tune this focal point, eg I want to develop mobile apps –> I want to develop apps on Android.
Actually being able to do this thing full time for work is also a matter of luck, but you’ll be best prepared when opportunity comes along, eg in an interview: “How would you build an app on Android?”
“T-shaped” focus refers to doing one thing well, but being aware of related skills, eg I build clients, but I know how enough about server development to prototype clients efficiently, or, in terms of curriculum, we teach everything but language-specific classes in Java so students gain expertise in this language as a side-effect.
Sharpening the saw
Unscheduled time is a common occurance. For example, as a project nears release, it may make sense to reduce the number of people involved; in the absence of another priority, people will have free time. (The time spent looking for a job might be described as an extreme example.)
Productive uses of this time include: moving into a support role for those still involved, testing and documenting the product, supporting customers on stackoverflow and github, training in new skills to “sharpen the saw”, hackweek, stretching entrepreneurial muscles, switching from the “productive zone” to the “learning zone”, etc.
This ties into “ownership” too; rather than wait for someone to tell you what to do next, you can use the time to advance toward your goals.
Help opportunities find you by populating a linkedin profile, which recruiters mine for leads, and hosting code on github, which interviewers can use to start establishing rapport. Follow Write/Speak/Code’s example by publishing professional ideas, eg via a github blog, and seeking feedback from trusted peers, eg friends in your CS classes. (Credit @megha for attending and sharing with our team.)
The interview process attempts to approximate the experience of working together such that the interviewer can recommend the interviewee for a job after a brief conversation.
An interviewer’s day-to-day work is usually private to a company and/or difficult to abstract for an interview, so CS basics may be the only thing in common between the interviewer and interviewee. Prepare by reviewing a book like Algorithms for Interviews, Cracking the Coding Interview, etc and practice solving problems on a whiteboard with other people, eg your campus’ ACM chapter. The goal is not to memorize solutions, but to gain experience breaking down problems, solving them collaboratively and producing a solution that’s understandable by other people.
I’ve found interview prep can also motivate academic requirements, ie “When will I ever use this? In an interview.” Students are actively steeped in CS basics; the books mentioned above just summarize and provide interview-specific context.
Two consistently high-performing groups of people I’ve interviewed are Waterloo interns and folks with competitive programming, eg International Olympiad in Informatics, experience. The former has a ton of experience interviewing. The latter has experience using algorithmic thinking and a standard language to solve problems as a team under pressure.
Interviewing is similar to pair programming in that two are involved, but one person is “driving”. The interviewer may look to you for motivation, eg “Is this applicant self-motivated?”, be inexperienced and/or slammed with work, so prepare to humbly take a lead role in identifying the problem, implementing the solution and asserting correctness.
Typically, a hiring team will schedule an initial phone interview using a shared text editor like collabedit, and then invite the applicant onsite for a day of in-person interviews with ~5 engineers and managers. At this point, practice is less important than responsiveness to coordination emails and getting sufficient food and sleep to think clearly under pressure, especially since we often interview with multiple companies in unfamiliar places simultaneously.
Interviews are also intended to give applicants a chance to see if the team seems like a good fit, so prepare questions, eg “What is your development process like?”, “Do you use any externally-available tools I can learn about before I join?”, “Are there any tools/patterns you use you think everyone should know about?”
Some companies are better than others regarding follow-up after an interview. Reach out to the recruiter you’ve been working with if you haven’t heard back after a day or so, and especially if one company extends an offer, but you’d prefer to work at another you haven’t heard back from.
To perform well in an interview and the workplace, we must demonstrate an interest in the role, even if it’s just a connection with a personal interest. ABC: Always Be Coding and The ten principles for growth as an engineer describe this well.
In my experience, this is a great focal point, eg when prioritizing features. A student can be her own customer initially.
Prepare for the experience of having your code read by others by pushing code to github and seeking feedback from classmates. Use a styleguide (example) to get ideas about what to review for, and, ideally, what can be automated (example).
Incremental development and the ability to revert changes is fundamental. Git and github are a great default choice. Use source control individually to ensure your project is always in a working state, and to simplify coordination on team projects.
Philisophically: progress > perfection.
Pragmatically, this refers to reducing risk by keeping changes small and maintaining a working product you can “ship” at any time. Agile development defines this formally, but I see this pattern applied broadly: in test-taking when solving easy problems first; in interviews by describing a solution verbally, then in psuedo-code, then with correct syntax, then with optimizations; in the workplace explicitly when scoping a change to commit to source control; in career planning by defining a goal and then building skills and choosing opportunities to advance toward that goal; etc.
In general, it’s easier to estimate the cost of a small change than a large change, so breaking up large changes into small changes is helpful. I’ve found a one week “cadence” works well for making progress and minimizing coordination effort.
Maker & manager schedules
Paul Graham’s “Maker’s schedule, manager’s schedule” essay persuasively argues wricting code and meeting with people require fundamentally different forms of attention. Both are important, mutually incompatible. Subbu Allamaraju’s essay “Accept | Tentative ✓ | Decline” also addresses this topic. Carve out “no-meeting” blocks on your calendar for focus work.
I first heard this phrase in the context of advancing a tech ladder (example ladder), eg senior engineers reduce chaos from a system, but I think it’s broadly applicable for career (and life) planning: identifying a personal career goal to buffer against corporate goal fluctuation; saving an emergency fund to buffer against employment fluctuation; diversifying investments to avoid single points of failure; etc.
From 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.”