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.

The University of Queensland (which I've attended for an unreasonably long time) recently started focusing on student entrepreneurship in a substantial way, which has led to the creation of IdeaHub, a "pre-accelerator" program and workspace designed to prepare students to engage with the startup ecosystem while still studying. I participated in the six-week program in late 2017 and found it to be enormously valuable. In addition to engaging talks given by Glen Richards (founder of Greencross Vets) and Professor David Wood (then-CTO of web text-editor company Ephox, now rebranded as Tiny), we also engaged in "Design Jams" facilitated by fellow student-entrepreneurs. What we didn't know at the time was how successful the program would be, or the amazing opportunities it would open up in the future.

Since my participation in the pre-accelerator program, Nimrod and his team have launched a series of follow-up programs called "Startup Adventures" based in a variety of tech hubs across the world (Shanghai, Tel Aviv, San Francisco and Singapore).  My first impression was that these trips would be somewhat similar to the Startup Catalyst program run by the Queensland State Government, largely consisting of "tech tourism" (i.e. visits to large tech companies in each destination). However, what Nimrod and IdeaHub provide is something infinitely more valuable. This blog post tells the story of my very own Startup Adventure.

Getting Selected

I'd applied for the Tel Aviv Startup Adventure Program in early 2018, but the program was so popular and received so many applications that I didn't make the cut. When a new destination was announced in late 2018, no less than San Francisco itself, I was determined to apply again. This time, I had a research position and the newly conferred presidency of the UQ Computing Society on my résumé. This it seems, was enough to sway the odds in my favour. The short, efficient application process was followed by an equally quick interview, and before I knew it I was meeting my fellow adventurers and hearing about all the things we'd be getting up to in California. First though, IdeaHub had to find a suitable start-up to place me in. This, as I would come to learn, is not as easy as it sounds.

The first company I was due to be placed with was Linqia, a company that connects established brands (think NBC, or Nestlé) with influencers (i.e. famous instagram personalities). As part of the process, I was asked to sit a technical interview over video link with one of Linqia's engineering managers. There was some initial confusion about the interview: I had been told it would involve algorithms and data structures, and that I would be able to complete it in Python, but the problem I was presented didn't involve any of these topics and could only be completed in Java. Nevertheless, I was able to complete the assigned task (except for one test case that was, in fact, incorrect). My interviewer was satisfied with my performance, but unfortunately word hadn't been passed down to him at that stage about the short nature of the trip. He felt that it would be impossible to provide a proper internship experience in such a short period of time (four working weeks), which I understood. With only four days until we were to fly out, this left me in a spot of bother. Thankfully, a UQ alumni and the company he had founded would step in to save the day.

Patchd

I'd first met Robert Quinn as a speaker during the IdeaHub pre-accelerator program and been inspired by his passion and enthusiasm. He and his co-founder Wei had just been through the muru-D incubator program in Sydney, the closest thing Australia has to Y-Combinator. At the time, their goal had been to build a device capable of detecting sepsis, a common and fatal disease, before doctors were able to diagnose it. Since I'd met Robert that first time, the company had moved to Silicon Valley, made it through the intensive Y-Combinator application process, and raised seed funding. With this new capital, they'd been able to move out of the Valley and into San Francisco's financial district. This is where they were when Nimrod, ever the connector of people, reached out to ask if they'd consider taking myself, and my fellow traveller Tim, on as interns. Rob's quick and efficient handling of the matter, along with a short phone interview with Wei (en route to my brother's wedding) quickly settled the matter: I'd be working at Patchd for the next month.

And We're On Our Way...

Our flights to San Francisco were largely uneventful, despite the somewhat confusing terminal system at LAX, where we met our connecting flight. We got into SFO quite late, around 11PM on a Sunday, and made our way to the hostel in Downtown SF we would call home for the next month.

Before we started work on Tuesday (Monday being Martin Luther King day), Nimrod was determined to show us as much of the city as possible, so we followed him on adventure from downtown, through the heart of the city, down to the wharves including the famous Pier 39 and Fisherman's Wharf, before heading across to the Paradiso and taking San Francisco's famous cable cars to the top of city. As if that 21km epic wasn't enough, we also managed to pick up tickets to visit Alcatraz the following Saturday.

Rather than bore you with a blow-by-blow account of my four weeks in San Francisco, I've picked out some of my favourite moments and events to focus on.

Meeting Patchd

Patchd is located a very handy 12 minute walk from our lodgings, taking me past not only the scenic Union Square, but also one of San Francisco's shiny new two Amazon Go stores (no checkout, just walk out with what you want and get charged to your account). Tim and I were unsure how strict working hours were, so we'd resolved to arrive at 9AM which we did, only to struggle to find the place when we got there. Thankfully, someone was around to let us in and show us where to go.

At that time, Patchd consisted of Rob (CEO), Wei (CTO), Max (Algorithms Engineer) and Jordan (Administrative Assistant) in a brand new office easily capable of fitting a staff of 15-20. In fact, they were so new to the office that they hadn't had a chance to put together the convertible standing desks we'd be using during our stay. This became our first task, somewhat self-assigned as the Patchd staff were mortified that we were happy to do it ourselves. Once that was done, the real work began.

My Work at Patchd

Despite the desk kerfuffle, the Patchd team had gone out of their way to ensure that both Tim and I had well-defined, achievable tasks for our time with the company. For me, that meant working with the core Patchd library. To indulge in some technical speak for a minute, I was specifically tasked with parallelising the training of the recurrent neural network responsible for training the model used to detect sepsis. Breaking this down, training machine learning models is often slow, especially when you have as much data as Patchd does. One way to overcome this is to split up the training data and run it on multiple computers simultaneously before combining the results back together.

The first problem I had to overcome was that I'd never worked with (or learnt about) machine learning, or the specific library (Tensorflow, developed by Google) that Patchd uses to make its models. This is where Max came in. Max was responsible for Tim and I at Patchd, and he's an incredible teacher. In the course of a single week, he was able to get me up to speed on the theory of recurrent neural networks and productive with Tensorflow.

Unfortunately, there was another problem. In the rush to get a working model, the team had taken certain necessary shortcuts, which had resulted in a somewhat messy codebase that was almost impossible to get working across multiple machines. Max and I would spend the next two weeks cleaning up the codebase, implementing an object-oriented structure and centralising state into a few key classes. During this time, I taught Max the basics of software engineering good practice and he continued to teach me (and Tim) how machine learning works.

Our time at Patchd wasn't purely technical. Rob was determined to give Tim and I exposure to the business side of start-ups and venture capital as well. During our time there we sat in on calls with lawyers, VCs, regulatory advisors. Rob also broke down the process of acquiring funding, explaining how the various rounds work and what kind of attitude/approach is needed to seal the deal. This was the kind of knowledge you just can't get from a book or a class and really made my time at Patchd.

Before too long though, it was our last week. I hadn't achieved everything I'd set out to, but I left the company with a much cleaner codebase and a roadmap for achieving parallelised training (not to mention ten freshly built standing desks they didn't have before Tim and I arrived).

Extracurricular Activities

Not only did we get the chance to contribute at incredible companies doing groundbreaking work, we also spent a good deal of time exploring San Francisco and the wider bay area. I've picked out a few of my favourites:

Google

One of the things I was most looking forward to in San Francisco (well, technically Mountain View) was visiting the global headquarters of Google a.k.a. the Googleplex. It seems like every software engineer (at least at some point) wants to work for Google and several friends and associates of mine already do. In particular, David Finster (Systems Engineering) who would give our team the tour, and Daan van Esch (Linguistics) who I'd worked with on the Transcription Acceleration Project. After spending only a couple of hours on the campus, which is really more of a suburb, I could definitely see the appeal.

Alcatraz

Alcatraz was a must-see for most of us, and it didn't disappoint. We all took the audio tour of the island and were transported to a different time. We heard about many of its famous, or rather infamous, inmates and what their lives as prisoners were like. The island (and prison) had its fair share of momentous events during its working life including the Battle of Alcatraz (an inmate uprising necessitating intervention by the army) and an occupation by Native Americans during the 1960s. The island is well worth the exorbitant cost of entry, but make sure to take the "free" audio tour to get your money's worth.

The University of California - Berkeley

No trip to San Francisco would be complete without visiting the greatest of the University of California campuses at Berkley. Our primary focus was Berkeley's "Skydeck", their in-house incubator and co-working space - somewhat like UQ's iLab, but on a far grander scale. We'd been invited for a tour by the founders of Humm, another Aussie startup focussed on enhancing brain performance. Little did we know, this would also include a tour of the Berkley campus, which involved T-Rex bones, the world's largest eucalyptus trees and a carpark devoted entirely to recipients of Nobel prizes. Before we left, we were also lucky enough to sit in on a Q&A session with Stephanie Zhan of Sequoia Capital, the valley's most prestigious venture capital firm.

The Aussie Founders Network

One of our first events on the ground after arriving in San Francisco was a fireside chat hosted by the Aussie Founders Network with Ash Fontana, an Aussie start-up founder who had transitioned into venture capital after a successful exit. This chat was particularly enlightening as Ash wasn't the type to mince words or oversell. The main takeaway from his talk was that we needed to "network like Americans," which basically boiled down to overcoming the distinctly Australian urge to undersell ourselves and our ideas. What was even more valuable though was getting our first glimpse of how networking really worked in SF. There is nothing more valuable there than being able to connect people, and the only way to do that is to overcome any distaste or fear of meeting new people and dive right in. This was made so much easier because AFN members were so eager to help you succeed. Because of the vast array of original ideas and industries on display, the likelihood of being in competition with anyone else was almost non-existent.

Twitter

Our last "Big Tech" stop was Twitter, where we were shown around by Timothy Marks, another UQ grad we'd met at the Alumni event in our first week. Again, Nimrod's slick networking skills (and Tim's friendliness) came to our rescue and got as invite to visit the house that Jack Dorsey built in downtown SF. By far the most modern of the HQs we'd visited, Twitter was lush. It was situated in multiple highrises towards the bay end of Market Street connected by an Atlassian-like skywalk between buildings. There were three separate dining areas/kitchens serving different types of food, thankfully we were there around lunchtime and got to partake. We also got to use the Twitter selfie machine, which took photos of all of us and uploaded them to - you guessed it - Twitter.

Muir Woods

While being surrounded by and working in a high-tech environment is the dream of every software engineer, it's nice sometimes to be able to get back to nature - so, one weekend while half of our squad headed down to LA to visit Disneyland, the rest of us made our way over to Muir Woods, on the other side of the Golden Gate bridge. It turned out to be well worth the long bumpy bus ride. California redwoods are absolutely stunning, and Muir Woods is amongst the best the state has to offer. It also helped that our bus, unlike the one back from LA, didn't break down.

Takeaways

That's about it. There's so much more I could have covered, but this blog post is already getting a little long. Four weeks went by incredibly fast, but given the opportunity to do it again, there's very little that I'd change about my time in San Francisco. More than anything else, my startup adventure was an incredible learning experience. Thanks primarily to the wonderful people that I met, the opportunities that arose as part of the trip, not to mention Nimrod's organisational talents, my time there was amongst the busiest and most productive of my life. While I'm glad to be back in Australia, surrounded by friends and family, going back to the valley - possibly even at the head of my own startup - is definitely on the cards. If you're considering applying for a Startup Adventure, just do it - the experience will change your life (for the better) in ways you can't imagine.

- Neil Gaiman

'Murica

Another year has gone by so quickly, but if I can say one thing about the 365 days that made up 2018, it's that I read and travelled quite a bit. At the beginning of the year I set my usual reading target of fifty books knowing full well that despite having the same goal for years, I'd never come close to meeting it. 2018 was different, by New Year's Eve I'd left my job at ADLED and was already in New York on my way to a five month exchange program at the University of Connecticut. This lack of gainful employment (I hadn't been unemployed since the age of ten) and a non-trivial amount of time spent on planes, trains and buses meant I could really focus on reading. I read everywhere, from public streets to coffee houses to my unheated room in the heart of Brooklyn. My favourite (by far) though, was the general research division of the New York Public Library's Steven A. Schwarzman Building on 5th Avenue.

The wonder this room inspired was replicated only once during my time in the United States, at the Library of Congress in Washington D.C. There's something special about spaces devoted to books and learning that affects me on a deep level.

My travels around New York were cut short by a blizzard and before I knew it I was off to Boston, a city caught somewhere between its revolutionary past and its intellectual present. I adored this city and its inherent walkability, I must have crossed the Charles river more than a dozen times during my weeklong stay. Visiting MIT and Harvard - something I'd wanted to do for years - was something of a disappointment as I quickly realised that due to it being the holidays, the campuses were largely deserted and admittedly quite boring. Clearly it's the people that make these places what they are, not the facilities. Walking the HBS campus, which I'd read so much about in Duff McDonald's book, The Golden Passport, was only slightly more fulfilling. The one part of Harvard (proper) that I did fall in love with, was the bookstore. I walked away with armfuls of books, wilfully ignorant of the fact that I would end up having to drag them with me across the entire width of the continental United States.

While I was in Boston I also walked the "Freedom Trail" taking in the incredible revolutionary history of the town, which ended in the most splendid view (pictured below). That, and the cake I eventually tracked down, made this one of my favourite birthdays to date, despite a distinct lack of friends and family to share it with. Boston also had a killer public library, but with a less endearing, post-modern architecture that couldn't quite match NYPL's.

After a week in Boston it was on to the University of Connecticut, where I would spend the next five months immersed in Computer Science, American culture, and despite it being the "spring semester", snow. UConn is lovely place, for all that its primary campus is located in the middle of nowhere. While I was there I undertook studies in:

• Programming Languages
• Operating Systems
• Computer Networks
• Computer Security
• Theory of Computation
• Introductory Quantum Computing

The Quantum course was one of the original reasons I had picked UConn, in addition to its close proximity to New York and Massachusetts. At the time, I was considering Quantum Information Processing as a field for postgraduate research (largely as a result of having read Nicolas Gisin's book Quantum Chance), and was thrilled when Professor Walter Krawec permitted me to audit his course. As it turned out, QC is largely based around linear algebra and this formed the majority of the course. I'm still deeply interesting in QIP, but I think my talents would be best suited to focussing on developing algorithms that leverage QC's unique benefits over classical computing. I'm deeply thankful to Professor Krawec for his patience and for helping me understand so much (despite my frequent tardiness/truancy).

It was incredible to be able to experience that much computer science at one time, but as usually happens I bit off more than I could chew with regards to classwork and this impacted my ability to both socialise with the friends I had made in my dorm and pull off acceptable grades. It also meant that I didn't get to spend nearly enough time enjoying UConn's ridiculously picturesque scenery.

While I was at UConn I also made some friends from Germany and together with another (American/Chinese/Israeli) friend we headed up to Montreal for a weekend. As the only member of the party over 25, I was chosen as the driver of the rental car we took. This meant that my first experience driving on the incorrect side of the road was the six hour drive from Storrs to Quebec, which was only a little terrifying. It turned out to be more than worth it - Quebec is fabulous and has its very own Notre-Dame cathedral in which we saw the most incredible (and surprisingly not sacrilegious) light show.

Before long it was back to campus, with less French, but more computer science and lakes. The sheer variety of content (and small class sizes) I was exposed to during semester more than made up for the lack of academic rigour I was used to from my studies in Australia. The beauty of the grounds (rivalling UQ's own) and on-campus ice rink may have helped a little, too.

During Spring Break (another American cultural phenomenon I didn't completely understand) my new friend Moritz and I travelled to Washington, D.C. via Philadelphia to try and take in as much "freedom" as possible. We saw a great deal in the week we were there, walking the National Gallery, seeing SCOTUS, the Capitol, the White House, the Smithsonian Air & Space Museum, the Library of Congress, and the Newseum (my personal favourite).

As exams rolled around it was time to start saying goodbye to all of the friends I had made and plan the next leg of my journey, something I hadn't put a whole lot of thought into until that point. My post-UConn American experience was largely a tour of potential graduate schools with detours for the US Python Conference, the Rock on the Range music festival in Columbus and a veritable vegan smorgasbord in Portland.

My first stop was Pittsburg, specifically to visit Carnegie Mellon University. Pittsburg (at least the areas that I stayed in and walked through) were quite lovely, though I did get my first taste of the "Rust Belt" neglect (i.e. crumbling infrastructure) there as well.

Next, it was on to Cleveland for PyCon, where Rust Belt Neglect stepped up to the next level. Despite staying only 10 minutes outside the city, I was advised (strongly and repeatedly) not to venture outside my lodgings after dark. A shame, given that walking the streets might have given some insight into why every second house was either foreclosed or condemned. PyCon US is everything I was used to from PyCon AU, just bigger and better. During the conference itself I met Python luminaries including Michael Kennedy, Brian Okken and Kenneth Reitz. I even got to have dinner with Michael, as well as Kevin Markham of dataschool.io, which led to a variety of interesting conversations about building a business around Python.

After the conference it was time for the sprints, where I angled my way straight to Russel Kieth-Magee's Beeware project, the end-goal of which is a truly cross-platform GUI library for Python. Over the course of the 5-day sprints I contributed to one of the Beeware sub-projects known as Batavia (a Python interpreter written in JavaScript), implementing some of the more obscure (read: corner-case) features of the Python built-in functions (like abs, sum and oct). In return for my week of programming, I got not only to work with one of my Python heroes, but also a shiny challenge coin:

After PyCon, I headed down to Columbus for a music festival (Rock on the Range) featuring some of my favourite bands including Avenged Sevenfold and Bullet for My Valentine. Then it was off to Chicago to see a very pretty university, eat some delicious soul food, see one of my favourite works of art (The Picture of Dorian Gray by Ivan Albright) and finally to board a train to Seattle.

American long-distance trains are worth every penny more than the equivalent Greyhound bus, something I wouldn't fully appreciate until after my 17 hour journey from Portland to San Jose. The trip took me through a half-dozen US states and across the Rocky Mountains - truly a sight to behold. Eventually, after two and a half days, I arrived in Seattle. Here, I saw Jeff Bezos' giant glass balls, drank my weight in London Fogs, and had more incredible American pizza. I also scoped out the lush, green University of Washington campus, another pretty place I could see myself spending 3-5 years at for a PhD.

Portland, my next stop, is a city of such glaring economic disparity that it's quite hard to stomach. It was the first, though far from the last, place I saw luxury cars (Lamborghinis, Range Rovers etc.) driving down a block housing thirty or more homeless people on the sidewalk.

It only got worse as I went farther south. In fact, the rest of my American expedition was rather uneventful. I stayed briefly in Mountain View to check out San Fransisco and the Valley, but was largely underwhelmed by it all (Mountain View itself is really just a big office park nestled in suburbia). Stanford, despite being internationally recognised, didn't seem have the same air of classic intellectualism I'd experienced at Chicago and even UW. I would go on to experience much the same thing at UCLA, though exploring the campuses was quite a pleasant adventure.

Los Angeles, my last stop before flying home, was similarly disappointing, being smoggy, crowded and appallingly afflicted with the same kind of disparity I'd experienced in Portland and SF. My host in LA, a recruiter for Netflix, explained that what I saw was the result of a policy in central (read: Republican) states to provide one-way bus tickets for homeless people to west coast cities like LA and San Francisco.

This wasn't the greatest note to leave on, given the overwhelmingly rosy picture I'd had prior to my arrival (and even up until my departure from the east coast). What it did give me was a much greater appreciation for the great land I'd come from, and would soon be returning to.

'Straya

Given that I had originally planned to spend the entire year abroad, first in Connecticut, then in Glasgow, why was I returning in June? An opportunity to contribute research at UQ. I'd been brought on as a Winter Scholar to help with the Indigenous Language Robot project and during the five weeks I worked under Dr Gautier Durantin I produced Hermes, software for turning linguistic resources into learning material for the robots.

The software was well-received by Dr Durantin and his supervisor, Professor Janet Wiles, and I was ultimately extended an offer to continue work on Hermes and other projects as a Research Assistant in the Complex & Intelligent Systems Group. At nearly the same time, I was offered a tutoring position for one of the introductory engineering subjects in the faculty of Engineering, Architecture and IT. I accepted both and quickly went from being unemployed to overwhelmed, just in time for a new semester at UQ.

As has been my way for as long as I can remember, I (again) bit off more than I could chew, signing up for five subjects in addition to my lab and teaching obligations. As the realities of what I'd signed up for slowly dawned, this was quickly pared down to four subjects, then three, until finally I finished the semester with only two subjects: Data Structures & Algorithms and Professional Practice in the Business Environment. My performance in Data Structures was lacklustre throughout the semester (to put it generously) due to a combination of too many work commitments, diminishing effects of my anti-depressant medication and my tendency to put more focus on the group work involved in Professional Practice. For the first time in nearly eight years of tertiary education (all of which took place post-onset), I had to sit a final exam under special conditions (in this case, later in the day due to the side effects of medication).

Despite my own less-than-stellar academic performance, my lab work (due to its flexible nature) and teaching (due to its scheduling) was largely unaffected. I took great pleasure in supervising 25 first year engineering students through the process of researching, designing and building their very own unpowered UAVs. My lab work was equally fulfilling, as I was moved from working on Hermes (My good friend James took over development) to tackling problems in speech recognition with Ben Foley on the Transcription Acceleration Project (TAP), specifically in KaldiHelpers and Elpis (abstraction layers for the Kaldi ASR system). During my short tenure with the lab I've been lucky enough to travel to the Northern Territory to attend the WANALA conference on indigenous languages, secure a summer research scholarship to continue my work in these areas (practically full-time) over the summer break. I also received a scholarship from the ARC Centre of Excellence for the Dynamics of Language (CoEDL) to attend their summer school at the Australian National University in late November. Both conferences were incredible experiences that fundamentally changed my perspective with regards to my work. In particular, they made me realise that technology is only useful in as far as it empowers people to do the work they do. Technology can't save language, it can only facilitate the people already working to do so.

This summer, following on from the CoEDL summer school, I've been working with a talented group of software engineering students (and one similarly talented anthropologist) to develop a web GUI for non-computational linguists to interact with Elpis and Kaldi. The goal was to expose the power of Kaldi to linguists, without requiring them to have a background in computer science. As this project extends into next year, I'll speak more about it in my next summary post, which I hope will come a little sooner than 2020.

One of the first (and only) things I did last time I set up a Ghost-based blog was to enable syntax highlighting in code blocks. At the time, the most popular option was prism.js, a fully featured JavaScript library with "batteries included," a phrase commonly used to describe Python and its comprehensive standard library. In this case, it means cool features like line numbers and "copy to clipboard" buttons. Unfortunately, this time around my dreams for pretty syntax-aware code were interrupted by a rude bug with prism (still very popular). When I finally found the directory on my server to plonk those JS/CSS files into, prism was shrinking the code blocks to fit the internal text, which looked positively awful.

highlight.js (and CDNs) to the rescue!

I'm very much a "path of least resistance" kind of person. If there's a problem with an upstream dependency in your Python module, you'd better believe that I'm already looking at your next-best competitor. This attitude comes from my near-constant, panicked desire to "get things done," as well as too much time spent fighting PyInstaller and dependency trees on the Hermes project. So naturally I went looking for an alternative. That market is sparse, but highlight.js stood out as a clear second choice. Alas, no line numbers, but there's a reason for that (apparently). What it did have was a standard, language-agnostic package common enough to have found a home on the Cloudflare CDN. I'm well aware that I should probably definitely host my own dependencies, but when Ghost has such easy code-injection it was all too easy to just chuck those CDN links in the header. Doing this properly (and probably fixing the prism bug) are on my //TODO list, for sure, but an MVP is a nice place to start.

And just when you thought I was done...

Unfortunately the latest version of Ghost doesn't support adding a language to your code blocks. In their infinite wisdom (or in an attempt to pander to writers over programmers), the developers have made code blocks started by  the ``` ``` syntax stolen lifted borrowed from markdown automatically open a cool code input field. While this is initially quite cool, it allows no way to explicitly specify a programming language for the code inside. It took a bit of internet sleuthing, but eventually I found a (not terrible) solution: use a markdown block! Last time I used Ghost, everything was markdown anyway, but now you can explicitly specify markdown the same way you can with an image or a Youtube video (i.e. with Ghost's fancy pants context menu).

In said markdown block, you can use the traditional ```language ``` syntax for specifying a language. I'm personally hoping that the Ghost developers can find a way to rectify this in the future, but I live in the now and this will have to do for the moment.

And that's it, I promise! As much fun as all of that was, there's only one thing left to do: try it out!

Here, have some pretty colours and a terrible way to screen programmers

for i in range(100):
    if i % 3 == 0 and i % 5 == 0:
        print("fizzbuzz")
    elif: i % 3 == 0:
        print("fizz")
    elif: i % 5 == 0:
        print("buzz")
    else:
        print(i)

Let's try this one more time. After a few failed attempts at this "blogging" thing, I've returned to Ghost.

As it turns out, building your own blogging platform from scratch is a lot of work, and worst of all, most of that work involves front-end development. As much fun as I had learning about structured data, I was tired of compromising on writing experience in exchange for the faux street-cred of being able to call my blog "roll your own." In the end, because the experience was so poor, I ended up writing nothing at all beyond a couple of paragraphs of meandering filler. On the upside though, Ghost seems to have improved substantially over the last few years. There are still many features I will have to implement myself, but for now I'm content to try and accomplish those as plugins using the Ghost API. As a result (at least for the interim) ndl.im will exist as some sort of Frankensteinian montage of my original Node/Express/Mongo stack - handling the index and custom pages - and blog.ndl.im as a space for prose, built on Ghost's Node/Express/MySQL/Ember stack.

I'm also interested in having a play with theming Ghost, as all of the third-party themes available in the official marketplace and through themeforest seem lacklustre at best. Casper isn't terrible, but I'm very particular when it comes to this sort of thing. I'm also toying with the idea of building out a Python client API library, just for shits and giggles. It's unlikely that I'd ever use such a thing, but it appears to be something the developers themselves are aiming for. Potential Google Summer of Code project, perhaps? I guess we'll see.

It's my aim to make this blogging business a weekly endeavour. My next challenge will be setting up code blocks and syntax highlighting (again) using prism.js. It may even end up being worth documenting the process.