This transcript has been edited for clarity and checked against the available source transcript and recording. Filler, false starts, and obvious transcription errors have been corrected without changing the speaker’s meaning.
Introduction#
James: Hello, and welcome to Graduate Theory. Today’s episode is a little different from normal. Usually, I sit down with one person and hear about the things they have achieved. When I first started recording the podcast, however, I interviewed three friends about their careers: Cooper Harrod, Oscar Harper and Alex von der Borch.
I’ve split the episode into three sections and selected the best parts of those interviews. Not every section will resonate with everyone, so use the timestamps in the episode description if you would like to move between them.
The first section is with Cooper Harrod, a graduate at Macquarie Group who moved from Adelaide to Sydney for work. I wanted to hear how he handled moving interstate and what he learned from it. Many graduates now move between cities and states, so his perspective is valuable.
The second section is with Oscar Harper, a software engineer at Atlassian who also moved to Sydney. We discuss the software-engineering interview: how he prepared, what the process involved and what he would recommend to somebody doing it now. These interviews are unusually demanding and can require considerable preparation, especially at highly competitive companies.
The third section is with Alex von der Borch, a graduate analyst at Deloitte in Adelaide and a former president of 180 Degrees Consulting. Alex shares what he learned about the qualities of a strong consultant and how to build a good career.
I’ve combined those conversations into one episode. Please skip around if you prefer, and enjoy.
Cooper Harrod on Moving Interstate for Work#
James: Cooper moved from Adelaide to Sydney to begin work. In this part of the interview, we discuss that move and his experience of relocating interstate for a job.
You’re from Adelaide, but you moved to Sydney to work at Macquarie. What led you to apply for interstate roles? Was moving something you had always wanted to do, or did the opportunity emerge during your job search?
Cooper: I wouldn’t say I had always been keen to move interstate for work. When I applied for internships and graduate programs, though, I noticed there weren’t many opportunities in Adelaide that interested me. The financial industry doesn’t have as large a presence there, so looking in Sydney or Melbourne was more a matter of necessity.
Before COVID, I had big plans to work in different places and experience living in other countries. Working in New York or London would be amazing, and it is still something I would like to do one day. The environment is different at the moment, particularly after a three-month lockdown, but moving interstate was an opportunity that happened to work out.
James: That was my experience as well. Almost none of my top choices were in Adelaide. Apart from consulting firms such as the Big Four, nearly every place I applied to was interstate. I had also studied overseas during university, which made me more confident about moving.
Were you nervous? Moving out of home, relocating interstate and starting a new job at the same time is a major change. What was that experience like?
Cooper: It was definitely a nervous and difficult time. I moved in February, and it helped enormously that I was starting a graduate program. Many other people were going through the same experience and also knew nobody in Sydney, so we could connect and understand what each other was dealing with.
It was also exciting because Sydney has a different atmosphere from Adelaide. Some of the other graduates thought I came from a country town in the Australian outback. The move was challenging, especially during lockdown, but it helped to have people around me in the same situation. That is a definite benefit of joining a graduate program.
James: You’ve now been there for more than six months. Would you recommend moving interstate for work to somebody who is still at university?
Cooper: It depends on the person’s circumstances, but I have grown through the experience. I had to become more independent because I lived alone and didn’t know anyone outside work. That forced me to grow as a person.
I would recommend it, provided you understand there will be hard times and sacrifices. Overall, it has been worthwhile.
James: Before the interview, I also asked for your favourite quote. What did you choose?
Cooper: In my family home, we had a poster of Michael Jordan taking a shot. It said, “You miss 100 per cent of the shots you never take.” As a child, I looked at it and thought it made no sense: if you don’t shoot, you cannot miss.
My dad explained that it means much more than that. If you don’t give yourself the opportunity to succeed, you are destined to fail. That idea applies in many situations. I considered it when deciding whether to move to Sydney for work. If I hadn’t done it, I would always have wondered what might have happened and whether I could have succeeded.
James: It was great to hear Cooper’s experience because it closely aligned with mine. Like Cooper, I moved out of home, began work and relocated interstate simultaneously. That is daunting, particularly after two years of a pandemic and lockdowns, but it is also character-building. I’m glad I did it, and I know Cooper is too.
Moving interstate may be easier now because remote work gives us more flexibility, while also making relocation less necessary. It will be interesting to see where that leads. My lesson is not to hold yourself back from opportunities simply because they aren’t where you currently live. Exploring what is available and experiencing another place can be an excellent opportunity while you are young and able to move.
Oscar Harper on Software-Engineering Interviews#
James: Oscar is a software engineer at Atlassian. In this section, we discuss his interview process and what he recommends to people preparing for software-engineering interviews.
These interviews have become quite standardised across many companies. Candidates are asked common programming and problem-solving questions, and the preparation can be significant. There are entire websites and books devoted to these interviews. We discuss both the technical questions and the behavioural or soft-skill component of Oscar’s Atlassian interview.
When you applied for internships at the end of your third year, how did you prepare, and what was that year like?
Oscar: I first interviewed with Atlassian at the end of my second year, before I completed another internship. I reached the final round but didn’t receive an offer. I was underprepared, and the process then required candidates to present a project. After only two years at university, I didn’t have much to present beyond small university projects. I didn’t yet have enough experience or a substantial enough project to show that I was worth hiring.
When they rejected me, I understood. The interviewers gave me good feedback, and I felt they had seen through the weaknesses in my presentation. I took another internship, gained much more experience and spent roughly eight hours each week working on a project.
After being rejected for the internship, I applied again for a graduate role. This time, I understood the process and knew what to prepare for. Companies don’t usually spring a major presentation on you without warning; they give some guidance unless the assessment is simply a set of quiz or coding questions. When they do provide guidance, prepare as thoroughly as you can.
My university work suffered while I prepared because I completed so many coding questions and created a detailed PowerPoint presentation for my project. I included code snippets, diagrams and anything else that might help, even though they hadn’t required that level of work. I was determined not to let the opportunity pass again. I had already been fortunate enough to reach the final stage once, so I used that experience. The questions were different, of course, but I did everything I could to prepare.
James: Software-engineering interviews are extensively studied. There are countless questions, websites and other resources. What strategy did you use?
Oscar: People often think of software interviewing as Google interviewing. Google has extremely difficult interviews because so many people apply and it wants to hire the best people it can. I never even received a first interview from Google, including after my internship.
The best approach is to understand the company and the kinds of interviews it runs. You can often find an alumnus or somebody at that company on LinkedIn and ask for an overview of the process. That gives you more preparation time. Otherwise, you may submit your résumé knowing nothing, receive an interview and discover that the entire process will finish in two weeks.
Most people enjoy talking about their work, so you can usually find somebody willing to explain what is coming: perhaps a behavioural phone interview, followed by a whiteboard interview and another technical stage. There are also many books and articles that explain these processes.
For the coding component, practise questions on sites such as LeetCode, HackerRank or Topcoder. You can never be too prepared.
You also need to prepare for behavioural questions. In some ways, I find them harder than coding questions. With a coding problem, you either know how to solve it or you don’t, although you can still have a bad day. With a behavioural question, you can always give an answer, but it may not be a good one.
Learn a structure such as STAR—situation, task, action and result—and prepare a range of genuine examples. Interviewers are trained to recognise that structure. If every answer returns to the same group project, it doesn’t look good.
Interviewers have often heard hundreds of answers and understand almost every university group-project dynamic. There is no reason to exaggerate. Your résumé may describe impressive work, but the interviewer wants to know what you actually achieved and what the outcome was.
Candidates often describe a project and conflict resolution, then forget the result. The interviewer has to ask, “How did it turn out?” The outcome doesn’t have to be positive. What matters is showing that you evaluated it, learned from it and could make a better decision next time. That is the behavioural learning interviewers want to see.
James: When you practised on HackerRank, LeetCode or another platform, did you build a curriculum, or did you simply complete as many questions as possible?
Oscar: I was fortunate because one of my university courses required us to complete about three Topcoder problems each week. We chose from a set of questions with different difficulty levels. Across ten or 12 weeks, I completed at least 30 and deliberately selected the harder ones to get more value from the course.
That gave me a strong foundation and exposure to common algorithms. You don’t need to memorise everything immediately, but it helps to recognise ideas such as shortest-path algorithms.
Without that course, I would plan around the data structures and techniques I needed to learn: maps, sets, strings, arrays, graphs and trees, as well as approaches such as dynamic programming. Sites such as HackerRank categorise problems by data structure or algorithm, so you can select an area and work through relevant questions. That gives you experience developing solutions with each tool.
James: You’ve completed several interviews, and your colleagues have been through similar processes. What common mistakes do candidates make in either the technical or behavioural stages, and how can they avoid them?
Oscar: For coding interviews, expectations depend on the company. An interviewer doesn’t only want the final answer because that reveals little about how you work in a team, interpret requirements or approach a task. In real work, code merely functioning doesn’t mean it is the best solution.
Ask what the interviewer cares about. For example, do meaningful variable names matter in this exercise? If they don’t, you can move quickly. If they do, avoid names such as a and b. Meaningful names cost almost no time, help you understand your own work and make the code easier for the interviewer to follow. They are also good practice for a real codebase, where meaningless names quickly become a problem.
The best approach also depends on the format. If the interviewer plans several rapid-fire questions, speed may matter. If there is one question with extensions added over time, pause before writing code. Think about the broad solution, the data structures you will use and its likely performance.
Interviewers value seeing that foresight and hearing you evaluate alternatives. Candidates often choose the first solution that comes to mind and immediately implement it. The interviewer then cannot tell whether they evaluated three options or simply got lucky.
Talk through your reasoning: “I could solve it this way, but it would be inefficient. I could use this other approach, but it may fail under these conditions. I think this third option is best.” Decision-making is a valuable software-development skill. The goal isn’t merely to make the code work.
James: Oscar’s experience shows how much preparation can go into a programming interview. His university grades fell while he concentrated on the coding stage, which illustrates the effort sometimes required to reach a company such as Atlassian.
I also found his focus on softer skills interesting. Programmers may focus mainly on technical ability, but communication, structured behavioural answers and explaining decisions are equally important.
Alex von der Borch on the Traits of Great Consultants#
James: Alex is a friend from Adelaide and a former president of 180 Degrees Consulting. The organisation brings university students together to provide pro bono consulting for charities and not-for-profits. It gives students exposure to consulting while helping community organisations, creating value for both sides.
I met Alex through 180. He was involved for several years and met many people through the organisation, which taught him what it takes to become a strong consultant. He is now a graduate analyst at Deloitte in Adelaide. We discuss the attributes and characteristics he believes matter in consulting and how people can develop them.
For listeners who don’t know 180 Degrees Consulting, can you explain what it does?
Alex: 180 Degrees Consulting is a global, student-led volunteer consulting organisation run through universities. It brings together strong student talent: our branch had an acceptance rate of about 20 per cent, while only around 25 per cent of proposed branches were accepted.
It connects students who want hands-on client experience with not-for-profits that need inexpensive or pro bono advice to become more efficient and effective. Students gain experience by helping charities and develop social-impact leadership, so they enter the workforce conscious of their impact on the community rather than simply turning up to a job.
James: Through university and 180, you’ve worked with many graduates. Which traits distinguish people who succeed in that environment from those who struggle?
Alex: It depends on how you define success. Google defines it as accomplishing an aim or purpose, while Cambridge describes it as achieving desired results. Those are broad definitions. We often attach money and socioeconomic status to success—the classic example is becoming a partner at a Big Four firm—but the real definition depends on each person’s aim.
That affects whether somebody appears to be a strong or weak consultant. Their personal definition of success may not be becoming an excellent consultant; it may be spending more time with family or earning better grades. Somebody who wasn’t a high performer at 180 may simply have focused on something else. They were not necessarily bad at what they did; they may not have had enough time to give 180.
Graduates have to decide, using the best information available, where to spend their time. Parkinson’s law says that work expands to fill the time available for its completion. If you give yourself a week for an assignment, it will take a week. If you allocate only an hour to 180, the quality of what you achieve in that hour may vary.
The strong performers who did apply themselves wanted to learn. Rather than stagnating, they asked questions and requested feedback about how to improve, which tools to use and what to research in their spare time. We could then guide them towards useful organisations and resources.
They also worked effectively with people from different backgrounds. A law student and a business student may think differently, while an arts student and an engineering student may have almost opposite balances of technical and interpersonal skills. Working productively across those differences sets people apart.
If you cannot work in a team, it is difficult to progress into leadership. This is particularly true in a volunteer organisation, where everybody contributes in their spare time. You cannot manage everything yourself. As president, I was fortunate to have a good team supporting me. Everybody had different responsibilities, and my job was to help them perform better rather than trying to do everything myself.
Professionalism also matters. Dress appropriately while retaining your personal style. Many organisations are removing rigid dress codes, and Deloitte has introduced flexible working hours. Provided your work is completed and you don’t leave too much for the rest of your team, you can choose hours that suit you. Some people begin at six and finish at three to spend time with their children after school. Others don’t function well in the morning, so they begin at ten and finish later.
You should still be well presented and understand the context. Don’t arrive in a T-shirt unless your client normally wears T-shirts. Finally, strong consultants enjoy working with clients and solving problems. It returns to the familiar idea that if you do what you love, you will never work a day in your life.
James: You’ve achieved a great deal. What single piece of advice would you give somebody starting university next year?
Alex: You and I both spent about five years at university. One of the biggest things I’ve learned is that a career may involve 40, 50 or even 60 years of work, but discussions about success often leave that out. There is considerable pressure to achieve conventional markers such as status and wealth at a very young age.
I’m 24 and only three months into my graduate role. I still feel young in the context of an entire career and have so much left to learn.
My advice is to take your time. There is no rush. If you find a good role, workplace or organisation that suits you before you turn 30, that is still a major achievement. Some people never find work they truly enjoy. Take the time to develop skills and be easy on yourself, because you have another 40 or 50 years to work. Enjoy your twenties while you can.
Outro#
James: Thank you for listening to episode 13 of Graduate Theory. I hope you enjoyed this different format and the lessons from Cooper, Oscar and Alex. Next week, we’ll return to the normal format with another interview.
If you would like Graduate Theory episodes and my takeaways delivered to your inbox, please consider subscribing to the newsletter. Thanks again for listening, and I look forward to seeing you next week.