Leidos

I work as a software engineer at Leidos, which builds and maintains digital systems used by customers to solve real-world problems. My area of responsibility is designing, building, and improving software features that are reliable, secure, and easy for people to use.

On a day-to-day basis, my job involves turning ideas and requirements into working software. A typical day might start with a team catch-up to discuss priorities and progress, followed by selecting tasks from our shared work board and planning how to approach them. I write code, test it and review other engineers’ work to make sure everything meets quality standards and follows best practices.

I also take part in meetings with customers and stakeholders to understand their needs, discuss progress, and help shape timelines and solutions. This means translating non-technical ideas into technical tasks, and explaining technical concepts in a clear, simple way. Over the course of a week or project, I might work on new features, improve existing functionality, fix bugs or help refine how our systems are designed.

Beyond coding, collaboration is a big part of my role. We regularly share knowledge, learn from each other, and occasionally come together socially to build strong team connections. In simple terms, my job is about problem-solving, teamwork, and building things that make technology work better for people.

What’s your background?

I was born and raised in Melbourne. I graduated high school in 2015 and went on to study a Bachelor of Pharmacy at Monash University, completing my degree in 2019. During my studies, I worked as a student pharmacist, which allowed me to gain early, hands-on experience in healthcare while applying what I was learning in real-world settings.

In 2020, I began my professional career as an intern pharmacist at Monash Health and later that year became a registered pharmacist. I worked across all Monash Health hospitals as a ward pharmacist, rotating through a wide range of specialties including COVID-19 wards during the pandemic, oncology and chemotherapy, neurology, general medicine, and surgery. Throughout this time, I experienced countless crazy moments and built many memorable experiences working closely alongside multidisciplinary medical teams. The environment was incredibly fast-paced and often volatile, but that intensity was also what made the work exciting. It demanded constant problem-solving, adaptability, and clear communication, particularly in high-pressure situations where decisions truly mattered.

In 2022, I decided to pursue a different career pathway and began working towards becoming a software engineer, while continuing to work as a pharmacist until the end of 2024. I had always had a strong interest in technology and realised that I genuinely enjoyed solving complex problems and building practical solutions. While I loved helping people through healthcare, the idea of helping people through scalable technology solutions felt equally meaningful and deeply motivating.

While working full-time as a pharmacist, I completed a Master of Computer Science specialising in Software Engineering. Balancing full-time work and postgraduate study was one of the most challenging periods of my life, but it ultimately strengthened my resilience and work ethic. Toward the end of my degree, I applied for graduate programs and was fortunate to secure a graduate software engineer role in 2025. I successfully completed my graduate year and was promoted to software engineer toward the end of 2025, a role I continue in today.

Could someone with a different background do your job?

Yes! A software engineering career is absolutely possible with a different background. I am a good example of this myself, having transitioned from healthcare into technology. What matters most is not where you start, but your willingness to learn, adapt, and consistently build your skills.

Key characteristics for this role include strong problem-solving ability, curiosity, resilience, and the discipline to keep learning as technology evolves. Good communication skills are equally important, as the role involves working closely with teammates and stakeholders with different technical backgrounds. Being comfortable with ambiguity, open to feedback, and able to break down complex problems into manageable steps are essential traits for success in this job.

What’s the coolest thing about your job?

The coolest part of my job is tackling complex problems and watching them turn into clear, working solutions. I especially enjoy picking up challenging tickets that push me to learn, knowing I have a strong support system around me to ask questions, get feedback, and improve quickly. Moments that confirm I’m in the right role are when a difficult piece of work finally clicks, or when feedback highlights how my solution helped the wider team or customer.

Beyond the work itself, we regularly share knowledge through internal “tech talks” over pizza and celebrate milestones with team events, which reinforces a culture of learning, growth, and collaboration.

What are the limitations of your job?

One limitation of my role is the mental challenge that comes with solving complex problems. Imposter syndrome is very real in software engineering, especially when working on unfamiliar or technically difficult tasks. There are times when solutions are not obvious, progress feels slow, or you reach temporary dead ends, which can be mentally draining. The role also requires sustained focus and comfort with ambiguity rather than immediate answers.

That said, these challenges come with the job and are balanced by strong team support and learning opportunities. Over time, working through these moments builds confidence, resilience, and stronger problem-solving skills.

3 pieces of advice for yourself when you were a student…

1. You are not locked into one path. Don’t feel like choosing a degree or career means you’re stuck there forever. People change, pivot, and grow. With determination and persistence, you can always create a new direction, everything will be okay.
2. No experience is wasted. Even if something doesn’t resonate long-term, it still shapes you. Every experience builds skills, perspective, and resilience that will guide better decisions in the future.
3. Back yourself more. You are more capable than you think. Don’t let self-doubt stop you from trying. Growth often starts before you feel ready.

Leidos is working to solve the world’s toughest challenges in government, intelligence, defence, aviation, border protection and health markets. As a software engineer, I help develop and maintain software for one of our customers. My team works on three separate projects, two of which are in sustainment and the other being in development. Due to the range of projects, we have a vast tech stack including React, Typescript, Rust, Java, Kotlin and more.

A common theme to our projects is that they all improve our customer’s workflow, helping them achieve their tasks in a more productive and organised manner. The projects I work on are either to replace outdated systems or manual processes.

A typical day for me includes looking at our scrum/work board to find a ticket/task to work on. This could include accomplishing the ticket/task myself or reviewing someone else’s work. The tickets range in size and can involve developing new features, patching bugs, addressing tech debt, working on research investigations or addressing user feedback.

My team also has different kinds of meetings throughout the week. This includes refinement, where we refine the tickets/tasks we have in the backlog to flesh out what exactly the task incorporates and any ideas on how to achieve it. As well as sprint review, where we demonstrate to our customer all the work we have achieved in the last two weeks.

What’s your background?

I grew up in the western suburbs of Victoria where I still live today. I struggled a bit trying to figure out what I wanted to pursue as a career. As a teenager, my interests were in film and psychology. I initially went to university to study psychology but decided to stop to pursue something more creative. After self-studying creative writing for a while, I realised that I wanted to keep my creativity side for myself instead of monetising it. So, I ended up a bit lost. That was until my cousin told me all about her life as a software engineer. She let me borrow her HTML/CSS book, which I read and enjoyed very much! I had heard of coding before but seemed too low-level for me. But after reading this book, my perspective changed. Not only was it easier than I thought, but also very creative!

I ended up applying to Deakin University again and completing a Bachelor of Information Technology. Near the end of my degree, there was encouragement from staff to apply for graduate programs. I found out about Leidos’ graduate program and applied after reading about the important work they do for our society.

I was fortunate enough to be offered a role and started in 2024 as a graduate software engineer. I am currently at the end of my second year at Leidos and I am very happy!

Could someone with a different background do your job?

I believe so. When it comes to coding, people often think of a specific type of person. However, there is really no limit to what you can create with code. I often compare programming languages to a paint brush or a tool. It really depends on the individual to decide what they want to create with it. And one of Leidos’ values is innovation. In order to achieve this, and seek out the best solutions and ideas, you need a diverse group of people who come from a range of different backgrounds with life experiences.

So, I would say not only could you do my job if you had a different background, but your uniqueness would be very valuable!

What’s the coolest thing about your job?

I love the constant opportunities to learn. With each new ticket comes new experiences that improve my skills, making me feel like I am constantly improving and becoming a better developer. I never feel bored or stagnant at work, there is always a new challenge around the corner to keep my brain stimulated. I’ve gotten to learn a lot about myself and how software is created and maintained.

What are the limitations of your job?

Unlike other graduate programs, there aren’t any rotations. Leidos will find a team/project for you to be on. Sometimes this can take a bit of time depending on current state and logistics of the team/projects. I was lucky and got on a team straight away, but some of my fellow grads/interns had to wait a bit. Leidos does try their very best to put you on a project that matches your skills and interests though.

It can also be a bit overwhelming starting as there is a lot to learn, but eventually you will get the hang of things.

Three pieces of advice for yourself when you were a student…

1. Remember to be kind to yourself and celebrate the small wins. The only person you should compare yourself to is your past self!
2. Try to get out the house more and be a part of more communities.
3. Learn about testing, Docker, Helm and Kubernetes!

Leidos Australia is a technology company that supplies specialist solutions to the Australian Government and other clients. I am a Cyber Security Analyst undertaking work in a full-scale cyber security project for Defence across multiple environments. I have exposure to GRC (Governance, Risk and Compliance), vulnerability management, cyber engineering, and cyber threat intelligence and threat hunt teams. I am thankful for the opportunity to work across all areas of the project and have used this time to plan which areas of cyber security I want to continue and specialize in.

The work is diverse and uses both my technical and soft skills. Knowing the cyber security landscape and threat vectors is vital. To stay on top of all things cyber, my mornings consist of reading cyber security news and reports. One task I am proud of is the development of a proof-of-concept dashboard for the internal and external stakeholders. I was able to learn a new skill set and supply new capabilities to my team.

What’s your background?

I grew up in Melbourne, Australia and have been in Melbourne through primary, high school and university; however, the dream was always to move to Canberra for a graduate role.

My love for technology began at an early age, sneakily playing computer games with my twin sister instead of going to bed like we were told. The idea of working in technology was always my end goal.

While at uni, I had the opportunity to sit the e-council ethical hacking and digital forensics exams and the Information Systems Audit and Control Association (ISACA) Cyber Security Fundamentals exam.

In my final year of university, I landed a six-month internship at Victoria’s Big Build Rail Project Victoria (RPV) project office. Working with a wonderful and supportive team, I was exposed to Microsoft Azure and M365, third-party management, and the Victorian Protective Data Security Framework (VPDSF) attestation and audits. I continued learning and completed two Microsoft fundamental exams and an RMIT micro-credential in public-sector risk management. After the internship, I was asked to stay on as a Security Administrator, incorporating and managing compliance with the VPDSF.

At the beginning of my final year, I began applying for graduate roles. The purple of Leidos stood out to me and the option to work in Canberra appealed to me. I applied for and started my role in January 2023 and have enjoyed the Graduate Development Program and the meaningful work of my project. My Canberra graduate cohort has been so supportive and has been the highlight of my first year at Leidos!

Could someone with a different background do your job?

Yes, however, knowing all about technology helps! This role values and requires a passion for learning and building strong relationships—just as much as technical skills. There are plenty of courses and certificates that can help build technical skills. If you are doing rotations across cyber security domains, it is important to be willing to learn computer networking, security tooling, as well as governance and policy frameworks.

What’s the coolest thing about your job?

The coolest thing is that I know there is always someone to talk to and ask for feedback without fear. I have access to a buddy, mentor, People Leader, a talented team of colleagues, and a wonderful graduate cohort. Leidos and the Early Careers team have built an environment that values both your well-being and career growth. I feel so supported in this role.

What are the limitations of your job?

There is a lot of responsibility in this role, and in my experience, I have been very self-driven. The work can have high stakes and challenging time constraints/deadlines. Those coming straight out of university may struggle to adapt to the self-driven nature of the role and tasks. Cyber security as an industry faces an elevated level of burnout due to stress, and this role is no different. The hours will change depending on the requirements of the task or the team, and you must adapt.

What are three pieces of advice you would give to other students?

• There is always something new to learn in cyber security. Continuous learning is vital in this environment.
• Find people who will keep you motivated, supported, and curious. Being around the right people will inspire you to be the best version of yourself.
• Remember to take time for yourself. Burnout is common. Building and sticking to good self-care habits and routines will help you overall.

5.30 AM

Snooze and ummmm… snooze again… So here is the thing, I’m just not a morning person. When my alarm starts blaring I will typically indulge my lazy side and snooze it. Once I manage to crawl out of bed, drinking a glass of water helps get the blood flowing (my substitute for the caffeine loaded beverage my partner obsesses over). Lights on, I cover the eyes until they adjust and move on to brushing my teeth, getting dressed and packing my lunch.

6.20 AM

Early bird benefits. By this time, I’m in the car and driving to the train station. Having tried both routines, I can definitely vouch for the idea of being an early bird. Missing the 9.00 AM peak means plenty of parking at the train station, cheaper myki fares and a guaranteed seat on the train. Lately, audiobooks are my jam in the morning, so the earphones go in and I do my best to stay tuned into the book while I fight my forever wandering mind. In case you were wondering, I’m currently listening to “The 7 Habits of Highly Effective People” by Stephen R. Covey.

7.20 AM

Settling in. Just arrived at my desk, greeted the team and signed into my computer. After a quick catch up with the team, it’s time to check my priorities for the day. The development team is made up of approximately 4 seniors, 2 technical leads, a recent graduate and an intern. We are building a data management platform that will be used to store and serve data to millions of Australians – robustness and scalability are imperative. I’ll spend 5 minutes going through my emails, replying to anything urgent. Up next is checking Jira for workflow changes, if I have made a pull request it’s (hopefully) been reviewed and pushed back to me for amendments. I tend to prioritise addressing feedback on a pull request to maintain momentum – a lingering pull request is bad news. After all, comments have been addressed, I push my code and move on to the next ticket – this should keep me busy for a while.

11.30 AM

Stand up. You may be thinking it’s a bit late for a stand-up, well… kind of but not really. Running standups at this time has two benefits, firstly it gives the team flexibility to start when it suits them, secondly, it means people talk faster as it’s strategically close to lunch – works surprisingly well. Sometimes we will walk the board sometimes we will do a round-robin (yesterday, today, blockers), I personally prefer the round-robin but change is always welcome.

12.00 PM

Lunchtime. I love food, so naturally, I love lunchtime. Resisting the temptation to buy lunch in the city is a tough one but eating dumplings every day gets expensive and the housing market isn’t playing nice these days… oh and I guess it’s not very healthy.

12.30 PM

Busy work. Trying to deep-dive technical challenges straight after lunch is usually a struggle. Using this time to reply to emails and take care of any other “busy work” helps ease productivity.

1.30 PM

A collaborative effort. Recently we had a new intern join the team, as part of onboarding we do some pair programming – I found pair programming invaluable when I started my graduate program and it’s something we do often. It gives them a chance to follow along and solidify their technical understanding, asking any questions along the way. Similarly, it forces me to consciously explain my approach in a manner that makes logical sense, an excellent way to weed out pesky knowledge gaps.

3.30 PM

Winding down or ramping up? As the day matures, instead of winding down I try and ramp up to finalise any deliverables before I head off. The sprint review is tomorrow which means it’s all hands on deck to get the work we committed to during sprint planning over the line. After checking Jira, there are a couple of tickets requiring review so I grab one and jump into it.

4.30 PM

That’s a wrap. Times up, I pack my bag, say my goodbyes and jump on a train. The days can be cognitively demanding so I skip listening to an audiobook, instead, I play some chilled music and reflect on the day during my commute home.

6.00 PM

Home sweet home. I walk in the door, greet my partner and give the cat a scratch. I do my best to be useful while we prepare dinner, she is much more skilled than I. We have dinner, I do the dishes and try to mentally prepare for a trip to the gym.

7.30 PM

It could go either way. Depending on how strong my willpower is that day, I may or may not be at the gym. I try to make it there around 4 times a week, exercise is a key ingredient to a healthy work-life balance.

8.30 PM

Lights out. After getting home I jump straight in the shower and prepare for bed. The day is done.

6.00 AM

I’m awake…just. Don’t bother talking to me; I won’t give you a coherent response. I eat breakfast and drink tea. Tea is good. I spend too long savouring my tea and rush through brushing my teeth and getting dressed to get out of the house on time.

7.00 AM

I drive to the station. As it’s so early, I can usually find parking pretty easily. I get on my train which is 3 minutes late, find the last seat in the carriage, grab my phone and earbuds out of my bag and settle in for the journey to work with some head-banging tunes to get me pumped for the day. I’m looking forward to the day ahead.

8.00 AM

My train is now ten minutes late. I choose to take the stairs rather than the escalators to get out of the station because I like to pretend I’m fit. It’s a brisk walk from the station to the office.

8.10 AM

I walk into my office suite and greet the two guys on my team who beat me in. We like to make use of Leidos’ flexible hours and have more home time in the afternoon. The rest of the floor is very quiet as most people don’t get in until a bit later. I unpack my stuff and log into my computers. I check my email and see the weekly update from the chief executive with updates on the organisation as a whole. This is a good way to find out what’s happening in different parts of the business.

8.30 AM

My team is currently working on a research and development project and we use scrum software development methodology. Today’s the last day of our two week sprint and I need to finish off the story that I’ve been working on before 11 o’clock so I can get the new functionality into the release.

9.30 AM

I’m happy that my code has built successfully, my unit tests have passed, I have a running instance of my new feature in our Dev environment and I’ve documented how to use the new feature. I need to get my story and code reviewed before I can mark it as ‘Done’. I ask one of my team members to review it for me. I give him a demo of the new feature and explain how it works. He reads through my code and picks up on a couple of things that I could have done better. I go back and fix the minor issues, then he re-reviews my code and approves it. My changes then get merged and my story is marked as ‘Done’.

10.30 AM

The Leidos office in Melbourne holds a morning tea every fortnight, and today’s the day. I get to the kitchen just as the food arrives so I can be sure I won’t miss out on a mini chicken curry pie.

11.00 AM

It’s sprint review time! This meeting only happens at the end of the sprint. We each talk through our moods during the sprint, what we think went well, what we think could be improved next sprint and people we’d like to thank.

11.30 AM

My team demos the stories that we’ve worked on over the sprint to each other. Some sprints, our client will come along to see the progress we’ve made, but this week it’s just an internal demo.

12.00 PM

Lunch time! Half of my team go out and buy food, the other half bring stuff from home. I’m in the ‘bring stuff from home’ category because I’m trying to save a deposit for a house. I head to the kitchen to toast my sandwich and then bring it back and eat it by the window while browsing the housing market on my phone and chatting to my colleagues.

12.30 PM

We merge the code in our Dev environment to our Prod environment and check that all tests are passed. We deploy to Prod and ensure that everything still works as expected. We fix any issues that come up.

1.00 PM

It’s sprint planning time. This always feels like the longest part of the sprint, so I make sure I’ve made myself a nice cup of tea to get me through it. My team gathers in a corner and we sit down and go through each new story in our backlog queue. We vote on the number of points we think each story is worth based on how difficult we think they will be to complete. The higher the points, the more difficult the story. If there’s a large discrepancy between our rankings, then the people who voted for the highest and lowest number explain why they thought it was difficult or easy respectively. After hearing their explanations, we then vote again until we reach an agreement. Once all of the stories have points, stories are added to our next sprint based on how many points we think we can achieve over the next two weeks.

3.30 PM

Sprint planning is finished and as I don’t have any story currently assigned to me, I can pick the next one from the top of the backlog queue to work on. It turns out that the next story is to configure and install a new software that I’ve never worked with before, so I spend a bit of time doing some background reading to try and figure out how it works before I start attempting to write configuration and installation scripts.

4.10 PM

Back to work. I think I’ve got enough of an idea to get started on my story, so I start writing some configuration and installation scripts.

4.45 PM

Home time! It was a good day. I pack up my stuff and log out of my computers. I leave the office and walk up to the station to catch a train home.

6.00 PM

I arrive home, eat dinner, walk my dog, have a shower, catch up on some TV and relax.

10.00 PM

Bedtime! I’ve achieved quite a bit today, so now it’s time for a well-earned rest.

7.00 AM

I start my day by waking up to my alarm. I try to aim for 7am but often I end up sleeping in another 15 minutes. I then open my blinds and start to get ready. When getting dressed I like to make sure I’m not in all black, as I like to bring a little style and colour into the office.

I have breakfast, often with my housemate who is also getting ready for their day. After this I pack my bag and sort out my lunch, which is often a pre-made meal from the supermarket. Unfortunately, I am not one for making extravagant lunches.

8.00 AM

I leave to catch the train into the city, which takes me around 40 minutes. Part of this is a 10 minute walk to the station, which is great to give me a little bit of exercise in the morning. On the train I usually listen to some music or read my Kindle to relax a bit before work.

9.00 AM

I get into the office around this time but it can vary, sometimes I start earlier so I can finish up sooner. I walk in and say hi to my friends before getting to my team area and finding a desk. My work is pretty flexible so there is always a range of people working from home as well as in the office.

I set up for the day and get started on what I was working on yesterday afternoon. Although a lot of my work is based in Java I tend to work in many areas of the project, which allows me to code in a variety of languages.

9.30 AM

By this time I have refreshed myself on the work I did yesterday and looked at what still needs to be done to finish the ticket. This includes tasks like writing tests and checking the acceptance criteria for anything that I’ve missed. I often write myself notes before I clock off so that I know what to focus on the next day and it’s these notes that I look over before diving into my work for the day.

My team is made up of a Scrum Master and eight Software Engineers, two of us are part of this year’s intern/graduate intake. A lot of the team have been graduates in the past, which means that there is always a friendly face who is happy to teach me about software I am unfamiliar with.

10.30 AM

I attend stand-up where the team and I share what we have been working on and what we are planning to do for the rest of the day. This keeps us accountable and makes sure that if anyone is encountering a problem, someone else in the team with relevant experience can offer their advice and help either by peer programming or brainstorming solutions.

I update my team on my ticket progress, including when I am likely to finish it. We then discuss some work that I will pick up once I am done, such as reviewing another teammate’s work. This is important to prevent any mistakes that a developer might have missed.

12.00 PM

At this point I might have come across what I think is a bug in the code. When I find something like this, I must confirm a couple of things, like if it is an unwanted behaviour, if I introduced it with my changes or it’s an existing problem. Determining the root cause of a bug can sometimes be tricky in a project with a large codebase like this because there are so many different places that an unwanted behaviour can be introduced.

If I encounter this, I usually ask one of my teammates to help me sort out the bug and we end up spending a fair bit of time analysing and solving. This is one of my favourite parts of my job – working with others and peer programming. I find that it’s the way I learn the fastest and I enjoy a good chat with my teammates.

By this point the bug has usually been fixed and I start to get hungry, which means it’s lunch time. I meet up with some other graduate and interns for lunch. Most days we all bring lunch from home, but I sometimes get something takeaway from some nearby shops.

3.30 PM

I continue working on my ticket. I put on my headphones and listen to some music or a podcast while I’m working to help me focus.

At the end of each sprint we show the client some features we completed as well as conducting a sprint retrospective. This is where we reflect on how the sprint went and look at what we could have done better. This helps us to continually improve and ensure we are meeting client expectations. A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work and made ready for review.

5.00 PM

I finish my workday. Often my partner will also be working in the city where we meet up to run some errands and catch a bite to eat for dinner. I’ll catch the train home and get there around 8pm to allow myself to relax before bed, usually watching a tv show or playing a video game. I’ll head to bed around 10:30pm so I can get some rest before I do this all over again tomorrow.