Getting That Grad/Intern Role

For many students studying computer science, software engineering, IT, or other technical fields, securing an internship or a graduate position at a large, well respected software company is one of their driving goals and their success or failure can be a key factor in setting the direction for their early career. Unfortunately, navigating the hiring process and securing one of these positions (the demand for which always outstrips supply, sometimes by orders of magnitude) isn't particularly easy or straightforward. That's where this guide comes in, it sums up the process from beginning to end, in the hope that when the time comes for you to throw your hat (or résumé) in the ring, you'll be more prepared and have the greatest possible chance of making your big tech dreams come true.

Contents

Standing Out

Remember how I mentioned these positions were oversubscribed? When I interned at Canva I was part of cohort of 32 interns. I was quite surprised to learn, talking to members of the recruitment team, that this batch had been whittled down from over 2000 applicants (a success rate of less than 1.6%). For bigger, more well known companies like Google and Microsoft that rate tends to shrink even further as the number of applications skyrockets.

I'm not a stats guy but even I know those odds aren't great. So how do you make it into that tiny fraction? How do you stand out from the crowd (of potentially thousands)? The answer, thankfully for us all, is flexible.

The Four Axes

There are an almost infinite number of possible things that could make you stick out, but I've limited this advice to the four areas that are usually within the power of undergraduate students. The relative value placed on these by recruiters (your audience) will likely differ from company to company, but in roughly decreasing order of "impressiveness," the four categories, or axes, are:

• Work Experience
• Personal Projects & Open Source
• Club Involvement
• Academic Performance

The good news is that you don't have to excel on every axis, which means that you can play to your strengths (or even develop new ones). Focussing on two axes (or at most three) and particularly excelling in one is usually enough to put you in the "worth paying attention to" pile. For example, I was a (very) mediocre student academically and until my first internship at Canva my work experience wasn't overly technical. I compensated for this by getting quite involved in my university's computing society, UQCS, first as a member of the general committee, then as president in the 2019 academic year. I also put some time into one of my club's open source projects and eventually  ended up developing one of my own. What follows are some tips on how you can make each of the four axes work for you, too.

Work Experience

(Relevant) Work experience before your penultimate year is the holy grail of impressing recruiters at most companies. If you can show that you've already been writing code in an industry environment, you can check off one whole axis. So what counts as relevant? It pretty much runs the gamut from working part time at a software company (or government department) all the way through to technical support. Unfortunately, a large swathe of big technology companies in Australia have adopted a very shortsighted view of hiring out of universities and as a result typically limit their intern hiring pool to students in their second last, or penultimate, year (that way they maximise the chance that you'll return as a graduate because they're the last place you intern).

Outside of Google's STEP program and token programs run by big consulting firms, the pickings for pre-penultimate programs are slim. That's when you have to start thinking outside the box. Casual programming jobs (usually in web development), university summer/winter research programs, running your own web development contracting business (you might start out building sites for friends and family with small businesses and move up from there), or even getting involved in a startup (just don't work for free unless you own it) all fit this bill. Even if you can't get relevant work experience, your non-technical work experience is still worth putting down on your résumé until you have something more relevant to replace it with. Non-technical work, particularly as part of team, goes a long way towards demonstrating your work ethic.

Personal Projects & Open Source

While the ability to get technical work while a student relies on many factors outside of your control, those limitations don't apply to your ability to build up a portfolio of your own projects, contributions to open source projects, or ideally, some combination of both.

These projects can take almost any form, but when it comes to using them as a way to show off your skills and prove yourself to a prospective employer nothing beats being able to show off some source code. Closed-source projects (including coursework) typically don't have as much impact unless they're undertaken in an industry or research context. Regardless, if you can't show off the code you're on the hook to provide a much better explanation of what the project involved. Before I explain how to sell the project though, I think it's worth providing some suggestions for what these projects might involve.

• Personal Projects: you really can build anything you want, but my advice here is to pick something small(ish) in scope that has the capacity to be extended later. For most student developers, the first port of call is developing and hosting their own web site. Something reasonably static, set up with Hugo or Gatsby might be the way to go, but there is certainly value to be found in starting with raw HTML/CSS (even if you find during that process that writing HTML by hand isn't fit for humans and graduate straight to React). Another fantastic personal project with scope to grow is writing and publishing your own Python package. Don't let my imagination limit you though, I've seen people implementing old games (Tetris) in even older languages (FORTRAN), writing their own ray-tracers and even developing their own games from scratch, the world really is your oyster.
• Open Source Projects: ideally (being a good internet citizen) all of your own personal projects would be open source by default, but what I mean by this category is large-scale existing open source projects. All of those technologies you rely on for other projects, from React, to NGINX, and even the Linux Kernel would love to have you helping out. If you're looking for a very beginner friendly project to get started with, I highly recommend checking out your student club's projects, or the Python BeeWare project. There is also a directory of beginner-friendly open source projects maintained here, as an open source project (meta, hey).  When you talk about these projects on your résumé, make sure you're focussed on your contribution, which doesn't have to be huge to be worth including. Concentrating your efforts on one or two projects helps with being able to concisely communicate them, but isn't hugely important.

• Hackathon Projects: getting involved in hackathons is a great way to learn new technical abilities, develop your teamwork skills and, if you're lucky, walk away with some pretty sweet prizes. More importantly than any of these (at least in this context) however is that you now have a shiny project (again, ideally open source) to show off on your résumé. If you made it to the podium or won a special mention (e.g. "Best Newcomers Project"), this also makes for a great addition to any résumé.
• Research Projects: harder to get into, and often not open source (though they all should be, when funded by public money), if you do manage to get involved in a programming-based research project, make sure you include these (particularly if you can link to the source code). My first programming job was in research and I was able to encourage the project lead to make it all open source (which took a fair bit of negotiating with the university lawyers on his part), but this meant that I had a large-scale project I could show off to potential future employers. When selling these, briefly describe what the project is/does, but spend most of the time talking about your specific contributions.
• University Capstone/Team Projects: if you've yet to put the time into developing your own projects, projects completed for university courses will do in a pinch. If it was a team effort, the same rules apply, focus on your contributions and don't forget to clean up the code (if it needs it), and include a README as detailed below. On the off chance a recruiter does look at the code you don't want to be left explaining why it's so poorly written/documented (or more likely not getting the chance to explain at all).

While I hope you're whipping up projects left and right for fun and profit, when it comes to their value to your job application, it's all about the sales pitch. You might have the world's most fantastic project, but unless you can sell it effectively to a technical recruiter in a single glance, it's not worth much of anything.

There are a couple of mandatory steps to making your projects "ready to sell." I'm going to assume for the sake of this exercise that we're talking about a personal project of your own that's already publicly available on GitHub (or something like it). The first non-negotiable line item is a top-quality, thorough README.md file in the root of your project. This readme should cover, at minimum:

1. What the project is, what it does, why you made it.
2. What dependencies it has.
3. How to get it running, locally or otherwise.
4. The licence information (can people use this code freely?).

If you want to step up your README game (which I strongly suggest) you can also include:

• Screenshots or GIFs of the project in operation (or links to videos).
• Metadata Badges, which communicate features like which language versions they support, or even usage statistics like number of downloads.
• A logo for the project (you don't have to be artistically inclined, just use Canva. I made a logo for a recent demo project in less than five minutes).

Once you've got your project running, well-documented, and have written some tests, there are a bunch of other things you can do make your project stand out. My first suggestion would be to implement continuous integration and or continuous deployment (CI/CD) for your project. Using tools like GitHub Actions and Travis CI, you can easily configure your project so that every time someone commits to the project (or opens a pull request) it runs the tests and tells you whether everything still works. Your CI/CD pipeline can also be extended to encompass things like type-checking, test coverage calculation, publishing of any artefacts (Docker images, library packages, websites etc.). CI/CD is near-universal in industry and being able to show recruiters that you understand this tooling can be a very impressive feather in your cap.

These suggestions are just the very tip of the iceberg when it comes to the possibilities for your projects, but hopefully this gives you some idea of where to start, and once you have, where to go from there.

Club Involvement

Getting more involved in club life is the most under-appreciated of the four axes, but in my humble opinion it's a) the most rewarding, b) the most fun, c) the best way to develop a new and valuable set of skills, d) the best way to keep abreast of opportunities in the field, and e) the greatest way to build a network of peers who you can learn from (and possibly even be referred by, more on this later).

The key with club involvement is to start early, ideally in your first year of undergraduate studies. Starting later doesn't count you out, by any means, but there's typically a hierarchy of roles to navigate if you're looking to make it the top. At UQCS this meant starting out as a general committee member for a year before moving up to the three executive roles, treasurer, secretary, and president. At CSESoc there are more roles and opportunities, you might start out in any of the many subcoms, moving your way up through a directorship and then on to the executive. It's rarely ever that simple and there are many factors that can affect the "hiring" or election process, depending on the role, but being truly involved is an experience like no other and can massively enhance your university experience, not to mention show employers that you're a team player.

Academic Performance

In my personal experience, companies whose primary product is software don't (thankfully) tend to mind if your grades are mediocre, as long as you've excelled along some of the other axes. That said, high marks can be extremely important for three software-adjacent career paths: management consulting, high-frequency trading (IMC, Optiver, Jane Street), and academia, who all prize high academic performers when assessing applicants. If you do happen to have put the hard work in and been rewarded with amazing grades, make sure to let the recruiters know. Include your weighted average mark (WAM) or grade point average (GPA) on your résumé and list any academic awards you've racked up.

Selling Yourself Effectively

The Résumé

How to put together an effective technical résumé could take up an entire blog post of its own (and it may in the future) but for now I'll limit this to the broadest of guidance. The most important point to make here is that the résumé is a document designed to be concise, and at this stage in your career there is no reason why it should exceed a single page. (Note: I deliberately and with great malice use CV and résumé interchangeably here despite knowing quite well that they're different things).

Content

What goes on this document is effectively a summary of your achievements along the axes that made up the preceding section. These should appear in roughly the following order (having Education and Work Experience at the top, in that order, is the most important), with few exceptions:

• Contact Info: this should include your name (reasonably large), email (consider getting your own domain), phone number, personal website, GitHub and LinkedIn (optional). Every one of these should be hyperlinked, preferably as rich text, but for those that are URLs, remove the "https://" and "www" at the start, where possible.
• Education: as a potential grad/intern this is the most relevant aspect of your profile to employers, particularly your graduation date and the program you're enrolled in. If you've been on exchange, include a line item for it, but list it as exchange studies, don't make it (inadvertently or otherwise) look like another degree. Unless academics are your focus and you've topped subjects, including courses you've taken is strongly advised against - trust me, recruiters know what courses make up CS/SWE/etc. degrees.
• Work experience: prioritise "tech-relevant" experience, but include less relevant experience if you don't yet have the relevant variety. Use dot points, and remember to describe the role and responsibilities more than the technologies you're using (that's more relevant to the projects section).
• Skills: for this section I normally recommend two lists, one for languages you're comfortable working in (in decreasing order of familiarity) and one for "Tools," which is a grab bag of frameworks, technologies and anything that doesn't quality as a "language." DO NOT under any circumstances give yourself skill rankings for anything in either category, they're worse than meaningless to the recruiters evaluating your résumé. Don't claim to know more than you do. Don't list "AWS" as a skill, be more specific, which of the 200+ services on there have you actually used?
• Projects: After relevant work experience this is probably the next most important item on your résumé in terms of impact factor. I've spoken a lot already about what these projects could be and what to include, but I'll focus here on how to describe them. You should aim to have between three and five projects, any more than that and you risk not having enough space to explain them well enough. For each, include a succinct title for the project (if it doesn't have one yet, make one up), a link to the source code hosted on GitHub (or similar) if possible, or indicate that it's closed source. Include a brief description of what it does, what technologies it was built with and, if developed as a group, what your responsibilities/contributions were.
• Awards, Prizes & Grants: if you've won a scholarship, grant or prize through university or anywhere else, make sure to include it. Prioritise the most important/impressive of these, unless academic performance is the primary (or only) targeted axis it's hard to justify more than six entries here. Keep in mind that this doesn't have to be purely academic, if you've secured a patent or even a government business grant this is the place for those, too.

One of the most convenient developments of the digital age (and the near total monopoly of the Adobe PDF for résumé distribution) is the ease with which you can connect your CV to more information for the interested, or make their lives easier with a shortcut. Your résumé should be a wealth of rich text and embedded links. If you're talking about a program you took part in, a scholarship you won, or an institution you attended, make sure the text with its name is a link to the web page for it. If there's a chance of the link expiring or being moved (universities tend to do this with scholarship pages etc.), take a snapshot with the Wayback Machine and link to that.

Style

Unless you're a graphic design wizard, keep it simple. Amongst my cohort at the University of Queensland it was common to rely on a typesetting system like LaTeX and a template. This ensures consistency throughout the document (harder than it sounds) and outsources the "design" aspect to someone who knows what they're doing.

A great place to find both of these is latexresu.me, though the selection of templates leaves something to be desired and you may want to customise yours a little (or a lot).

A Living Document

Your résumé should be undergoing constant iteration at all times. Every time you start a project, compete in a hackathon, and start or finish a job, you should be thinking: "how do I reflect this in my résumé?" As a result, I highly recommend treating your résumé like a software project and keeping it in version control, along with any cover letters you write (which should match the visual style of your résumé).

In addition to constant updates, you should always be actively seeking feedback on your CV. CSESoc and UQCS both encourage members to share their résumés for "roasts" in the careers-focussed channel of their respective communication platforms (just make sure to remove your contact/identifying details). While it might sound scary (and you will get a lot of personal opinions along with genuine advice), this is a great forum to hear how your CV can be improved (if you're not sure about whether your local club supports this practice, ask). The most valuable advice tends to come from final year students who've actually completed internships and/or received graduate offers as well as the ever-present, lurking alumni who also managed to wrangle themselves meaningful employment. This process proved so valuable to me personally that my résumé has gone through six or seven roasts by this point. If you're not comfortable with doing this publicly, reach out to a few individuals and get their feedback privately.

The Art of the Referral

There's one aspect of the recruitment process that isn't widely advertised, and for good reason. A referral is when someone who already works at a company places an application for a role on your behalf with human resources. The actual mechanics of this differs from company to company, but the process is normally managed through the company's HR application portal (e.g. Lever). Most big tech companies, and even some startups, also incentivise their staff to refer talented people they know with sizeable cash bonuses. These "referral applications" are typically treated differently to applications made directly. Again, it varies from company to company, but getting a referral might mean that you skip an automated processing step by which résumés are evaluated and culled en masse, which effectively means that you make it to the first stage of the interview process (e.g. a phone screen). You still have to prove to the company that you're qualified by making it through the interview process, but you might just have skipped the most volatile stage of the process where you power to prove your worth is at its lowest point. Referrals are extremely valuable to applicants, referees ($$$), and even to HR, whose job is made easier by referees' more in depth knowledge of applicants' skill levels, it's effectively a kind of pre-vetting. And it works, I've personally heard from people in recruitment of intern cohorts being made of up to 40% referred candidates.

What you have to understand about referrals though is that generally the person making the referral is putting their reputation on the line, to some extent, in referring you. What this means is that the referee will typically want to know you reasonably well, to have seen proof that you can program through your projects, or preferably, have worked with you in the past. If you're not close with the person you may have to demonstrate that you know what you're doing.

All of this is to say that there are appropriate and inappropriate ways to go about getting a referral, and if you don't know someone inside the company you may have to accept that this isn't an approach you can take. Some examples:

• Hitting someone from the company you don't know up on LinkedIn for a referral: inappropriate.
• Asking a speaker from the company you just met at a club event for a referral: inappropriate.
• Asking an alumnus who still hangs out in the CSESoc Discord and tutored you that one time when they were still at uni about the company before asking for a referral: probably OK.

Applying Strategically

Because of the hiring arms race that's developed due to the lack of talented applicants in Australia, some companies (looking at you high frequency trading) have pushed their hiring period earlier and earlier each year and now have applications for intern and grad positions opening in December of the year before.

Keep an eye out on the job listings maintained by the companies you're interested in and on job boards maintained by your university computing society. Applying early is generally in your best interests, though this depends a little on how the companies process their applications.

There is a tendency amongst a certain type of student to put off applying because "they're not ready" or they "just want to finish one more project for the résumé." This is typically the result of unfounded anxiety about their level of skill and is actually a mistake that leads to them missing out on opportunities. Prepare early (i.e. pre-December), have your CV and associated projects ready, and make sure you've already started practicing for interviews.

I've been asked several times in the past how many applications someone should make in each hiring season and I still don't have a solid answer for this. I've seen people apply to only their dream job, be knocked back and have no recourse, but I've also seen people apply at over a dozen places, burn themselves out, only to fail the interview for their dream internship because they were so worn out juggling all of their applications.

So I'll say this: always have a backup, and preferably more than one, but make sure you're not taking a shotgun approach and applying to every job that opens up. Make a list of potential companies and rank them based on how much you envisage you would enjoy working there, and if you can, talk to some existing employees about what working there is actually like. I will say bluntly that financial compensation and "company prestige" are terrible reasons to choose somewhere to work and I would advise against factoring them into your decision. Whether a company develops a product your can relate to, solves challenges you find interesting, or has a mission you can get behind are far better indicators for what makes a good place to work.

The Pre-Interview Process

If you've sold yourself well enough and the stars have aligned in your favour you'll get an email back from the recruitment team at your chosen company advising you of the next steps in the process. At this point there's still a long way to go, so don't get too excited, but you're in the pipeline, so congrats.

Code Screen

Most big tech companies are overwhelmed each year with applications and a lot of these applicants aren't even capable of putting together a solution to FizzBuzz. To separate the wheat from the chaff, so to speak, one of the first things most companies will do is send out a programming assessment, usually facilitated by a platform like HackerRank. Typically these are sent out via an automated process to every applicant, so don't read too much into it at this stage. These assessments vary in content and scope, but usually involve multiple questions and are time limited. It's normal for these assessments to be too long and too difficult to fully solve in the allotted time, it's likely to be deliberate so that the recruiters can better differentiate between candidates. The good news is that when there are multiple questions you might not be expected to answer them all fully. For example, I've interviewed at companies who asked five questions, but the threshold for progression in the interview process was completely solving two of these.

The secret to doing well at this type of assessment is practice. The questions you'll be faced with are typically custom-written by the company, but exposure to similar styles of question and being forced to think about how to solve them make tackling the actual questions so much easier. They also expose you to tools and libraries designed for solving these types of problems. While some companies mandate a particular language, or provide a choice of several, the vast majority allow for the use of any popular language, but typically restrict the packages or libraries you have access to. It's in your best interest to choose a language that you're comfortable working in, but equally important is the power of that language's standard library. In my experience, this make Python the clear winner, but you have to balance those two requirements with your own preferences. Python's itertools and collections libraries in particular are incredibly useful for the sorts of questions commonly being asked in this type of assessment. Once you've chosen a language it's time to practice. The three most commonly recommended platforms for this are Leetcode, HackerRank, and TopCoder. I personally did my grinding on HackerRank, which had handy language-based problem sets to get you acquainted with the features of your language whilst practicing your problem-solving skills. You'll also find sets based on common interview topics like data structures and algorithms.

Phone Screen

It's very common for companies first post-application contact to be an email congratulating you on entering the process and asking to arrange a time for a short phone call (normally no more than 20-30 minutes). These calls are usually with a technical recruiter, not an engineer, and typically involve talking about your projects or other items of interest from your résumé. They'll also typically ask a few open-ended questions to gauge your ready knowledge of technical topics. For example, you might be asked to explain the difference between threading and multiprocessing and give examples of when one might be more appropriate than the other. Or you might be asked about particular data structures and their relative advantages or limitations. When answering it's worth remembering that the person asking the question isn't an engineer themselves and they're usually just looking to tick off boxes involving your having hit on key topics in your answer. Stick to the question being asked, don't ramble or go off on tangents. Be honest when you don't know the answer, you can only "wing it" to a very limited extent before the gaps in your knowledge start to show. Normally the recruiter will have a number of questions to pick from in case the candidate hasn't covered that material, so don't stress if you haven't taken higher level concurrency or networking courses (that said, core CS courses like data structures and algorithms and basic object-oriented programming are typically considered assumed knowledge for applicants).

The Final Interview(s)

The mechanics of the final interview process (like practically everything else thus far) differs from company to company, often wildly. From which types of assessment are involved to the order in which they're administered, you're unlikely to find two perfectly alike. There are trends between them though, and it typically boils down to some combination of the following assessment varieties:

• Classical Programming Interviews
• System Design Interviews
• Behavioural (a.k.a Culture Fit/Values) Interviews
• Take Home Programming Assessments

One company might require multiple programming interviews, while others might go for more of a "one of each" approach. It's worth finding out what the company's process is before applying (either from their website, attending the company's events with the clubs they sponsor on campus, asking alumni/current employees on the club's Discord, or even reaching out to the recruiters - though they'll normally make this information known early in the process) so you can work out how best to spend your time preparing.

Programming Interview

If you've passed the screen your friendly recruiter will be in touch to schedule a "final" interview. This has increasingly come to mean a final series of interviews, typically three or four consecutive interviews. With some companies, like Google, this means between two and four actual programming interviews, but companies like Atlassian and Canva tend to provide a mix of programming interviews and the other varieties described below.

Programming interviews however, represent the deepest, darkest fear of many a CS (or whatever) student but unfortunately are key to proving your competence. No well-run company will hire you if you can't do at least a reasonable job on them. As always, the exact mechanics will differ between employers, but the basic setup is this: you will meet (increasingly remotely/online, given COVID) with one or two of the company's engineers (one might be learning the ropes of interviewing) who will verbally describe a problem they want you to solve using some platform (I've seen everything from a Google doc, to dedicated platforms like HackerRank's CodePair and even just using your own IDE and sharing your screen over Zoom. In the pre-COVID days you might also just get a whiteboard to write out your answer on). Resist the urge to start programming immediately when you get the problem, this is a mistake (and will be noted by the recruiter). Your first first five to ten minutes should consist solely clarifying the problem and developing (at least the basis of) some test cases you can use to check your solution as you go. The secret to these interviews is, somewhat ironically, not programming but talking. Your goal (the whole time) while you tackle the problem, both before and during the programming portion, is to articulate your thought patterns so the interviewer knows what's going through your head and can more quickly redirect you if you misunderstand the problem or go astray.

Once you get to a working solution, one of two things will happen, you'll either move on to another question (increasingly less common) or at companies with a more sophisticated approach, you'll move into "extension" territory. Most questions will be asked in stages of increasing difficulty. For example, you might be given the classic "Two Sum" problem and decide to solve it the "easy way," which, depending on your implementation, might perform with O(n²) time complexity. The obvious extension is to ask you to improve upon this performance, either with a specific target (e.g. O(n)) or just an ambiguous request for improvement (space complexity is also low hanging fruit - though less common - for interviewers). As an aside, Stanford has a great breakdown of the Two Sum problem including questions you should ask and the possible solutions available here - I'd highly recommend checking it out. What's very common, particularly if time or space complexity wasn't a part of the question or extensions, is for interviewers to ask you to evaluate the time and space complexity of your solution in the closing phase of the interview. Your answer is an important part of the assessment, even if not quite to the same extent as the actual programming. This is a skill in and of itself that needs active attention and practice as well (particularly if you find yourself often coming up with particularly convoluted answers).

Preparing for these interviews is very similar to preparing for the code screen, as described above, with one important distinction, and that's the need to practice the "talking" aspect of the interview. So while you should be crunching Leetcode and HackerRank on your own (Leetcode has a paid feature by which you can access lists of questions known to be asked by certain companies, if you're into that sort of thing), you should also find someone who's also applying for internships or grad positions and arrange meet up regularly (somewhere with a whiteboard) and take turns being the interviewer and interviewee. Joining your university's competitive programming club (or starting it if they don't have one) is also a fantastic way to get a feel for interview-style questions in a more exciting context (it's also another thing to whack on that résumé 😉).

System Design Interview

Not nearly as common as straight programming or behavioural interviews, but (at least in my opinion) far more exciting, are system design interviews. I've seen these take two formats, both of which take place using a whiteboard (virtual or otherwise), not a terminal.

In the first and by far the most common format, the interviewer will ask you to choose a project that you've worked on (they may specify with other people) and ask you to describe it and its architecture. They'll dig into the details and ask you about architectural decisions you made during development. The objective here is threefold, first they want to assess that you have actually worked on a substantial software project, the second is to assess your ability to communicate effectively about something you've built, which is an incredibly important and frequently used skill on the job. The third aim is to assess your ability to recognise mistakes you've made in the project's implementation and suggest improvements, which is why they always tend to as "is there anything you would improve, in retrospect?" or some variant of that. Being aware of your mistakes, humble enough to admit to them, and talented enough to see where improvements could be made, is the trifecta of skills for an effective engineer. Preparing for this type of interview is reasonably straightforward: pick one of your projects and sit down in advance and think about how you'd describe it to a (technically adept) stranger (you'll probably be permitted to use diagrams for this), as well as how you'd justify the architectural decisions you made and what you'd improve. Having a back up project prepared in the same never hurt anyone, either.

The second format, and by far my favourite, involves being asked to architect a system from scratch. In my personal experience, that involved demonstrating that I understood the infrastructure required (at least in broad strokes) to build a "Reddit-like" site, the scope of which expanded as I went along. To start with, I described in rough terms the components of the back end API, the technologies I might use on the front end and how that would connect to a database (as well as what type of database to use). Then I was asked what changes I would need to make to support an obscene amount of user traffic, which involved discussing things like load balancers, database sharding and failover, and the associated challenges that crop up from using these more advanced systems. While this might sound intimidating, I should mention that I've only ever been asked this type of question when interviewing for a niche site reliability engineering (SRE) role, which specifically deals with these types of challenges. If you're looking to prepare for this type of thing, it's worth playing around inside AWS (or Google Cloud), watching talks from conferences like re:Invent about architecting large-scale systems and, if you can, reading Designing Data-Intensive Applications, the SRE book, or tagging along in person to conferences like YOW!.  It's difficult to find a use case for these kinds of technologies as an individual, and particularly as a student, but you don't really have to have used them in order to understand what they're for or how they work at a high level.

Behavioural (Values / Culture) Interview

It turns out that programming isn't all that's required in a software development role. Regardless of how talented you are, or how much you'd prefer to work alone, part of being a member of an organisation is participating in meetings (often Scrum/Agile rituals) as well as working together with team members to solve larger problems and organise work. As such, organisations want to ensure that you're going to be able to work as part of a team. For employers, gauging this is probably the hardest step in the interview process as it's an incredibly subjective area. This makes it somewhat hard to prepare for, but there are a common set of questions that tend to pop up, which include examples like:

• Tell me about a time you disagreed with a colleague, how did you resolve this?
• What's your process for tackling large problems?
• Tell me about a time you failed.
• Tell me about a time you had to lead a team.

These questions are deliberately open-ended and designed to spark a conversation that will, hopefully, give the interviewer (often a manager) some insight into your likelihood of fitting in well with the company's culture and teams. There are various strategies for how to answer these types of questions, but by far the most common is the STAR method. What the various methods don't tell you though, I imagine because it's assumed to be pretty obvious, is that a lack of humility in these situations can be the difference between success and failure. I've had several obscenely talented engineer friends from university pass all of the programming tests, only to be knocked back for "culture fit." Sell yourself well, but don't overdo it, don't criticise past colleagues/employers, don't evangelise your favourite programming language and don't act like or claim to be an expert in anything (this is particularly unbecoming in university students, who know next to nothing about software development).

All of that aside, the most important thing though is to be prepared. If the company has publicly shared its values, like Atlassian or Canva, it's worth reviewing these and coming up with an example or two of how you've exemplified that value in the past. You'll probably be asked about them as both a way to start a conversation and to test whether you care enough (or are prepared enough) to have researched the company.

Take Home Programming Tasks

Some companies take a slightly different approach to interviewing, recognising that people probably aren't at peak performance under the pressure of a time-boxed interview. Instead they give you a "take home" task to complete over the course of one or more days. These tasks are normally quite straightforward and are designed to test how you code. They shouldn't take more than a few hours of concerted effort. Examples I've seen include:

• Set up a basic web server to serve a predefined API.
• Craft an interface for a music player in React.
• Write a program in <language> to convert a numerical representation of a number to words (like you'd see on a cheque).

In my experience this form of interview is most common for front-end position interviews, but is by no means exclusive to them. When you're applying for front end it's a little hard to put together a UI that shows off your talents inside 45 minutes or an hour. A take home gives you the chance to use your own tools (IDE) and process to produce your best work.

You'll normally have some constraints placed on you as to what you can use in your solution (e.g. only the language's standard library), but if you do have the freedom to use libraries, do it. No employer (or at least very few) wants their engineers reinventing the wheel when there's actual business logic to implement. Also make good use your chosen (or predefined) language's standard library, this is a chance to show the company that you know your stuff.

What you hand back to the company should, at minimum, include the following components (much like a personal project):

• README: well thought out instructions on how to run your solution and describing your rationale for any major architectural decisions.
• Solution: high quality code (that if it's Python, has types). Your code should also be reasonably well commented with docstrings and inline comments where the meaning of the code isn't immediately obvious.
• Tests: mandatory, even if they weren't mentioned in the spec. These should be thorough and provide adequate coverage of any edge cases. Your README should also include instructions on how to run these.

The company is forced to trust that you'll stick to the parameters of the task and not get any outside help, but to be honest it's incredibly easy to detect cheating in these tasks because you're normally asked to discuss your solution in a follow-up interview.

The Wait

One of the least pleasant parts of the whole application process are the waiting periods between stages, first between making your application and hearing back about an interview, and finally between sitting the interview(s) and hearing back about whether you've been successful or not. Because of the ever-extending nature of the yearly hiring window and the high number of applicants, these waiting periods can go on for months. There's very little to gain, and a lot to lose, from spending the time harassing your recruiters for updates. If you're following the advice from the Applying Strategically section above, you should be too busy for that anyway.

The Offer

All your dreams have come true, you've finally got an offer! Typically these will come via a phone call arranged over email but as with everything else in this process some companies may do things differently. If the offer being made is for an internship at your first choice company: congrats, your work here is done, advance directly to GO, collect (hopefully more than) $200. It's polite to let the other companies you've applied to know that you've accepted another offer so they don't waste time and effort progressing your application. If the offer is for a graduate position it's time to decide whether you're happy with the compensation and ready to sign on the dotted line.

If you're not just happy the ordeal is over and you want to try and maximise your offer, you still have some work to do. Don't accept the offer just yet, tell them you need to time to consider and they may give you up to a week. You can use this week to reach out to the other companies you've applied to. Let them know that you have another offer with a tight deadline but you'd prefer to work with them. This will typically expedite your interview process with the other company, and if things go well you'll end up with another offer to weigh up before you get back to the first company. This is the same process you'd follow if you had received an offer from a company that wasn't your first choice, you can (normally) use the leverage of another offer to achieve a faster outcome with your first preference.

This isn't universal, depending on the attitude and professionalism of the first company there is a minute chance they're looking for immediate acceptance of the offer and asking for time to consider could lead them to revoke it. It's a chance you have to take if you're looking to thread the needle. The alternative, accepting a role and turning it down after the fact for a position at another company will typically burn bridges with the spurned potential employer. Whether you're willing to do that is a choice you have to make, but I wouldn't recommend it, personally.

The Not Offer

No matter how qualified you are, no matter how good your résumé is, there's a reasonable chance you won't hear back with good news from your first choice (or even any of your other choices). Most companies will reach out to let you know that you haven't been successful, but some might not respond at all.

It's important to understand that this isn't the end of the world. If you were applying for an internship, you can take the summer to revisit your place on each of the axes and work on your offering for grad applications. If you were applying for grad programs, there's still some good news! Many grad programs accept applications for up to a two years after you graduate, so there are plenty of opportunities to take some time to up your game and apply again.

"That's All, Folks!"

If you're still with me at this point, congrats, you made it! Hopefully you've leant something along the way and have some idea of what aspects of your "sales pitch" you need to work on in order to get that bread 🥖.

P.S: If you've made it this far and you still have questions I haven't answered, you're wondering about what interning at Atlassian/Canva is like, or the possibility of a referral to Canva, please get in touch via enq@ndl.im. I'm also reachable on the CSESoc Discord under the handle @noodle.