Video: Placement Year With Sophos 2027/28 | Duration: 4780s | Summary: Placement Year With Sophos 2027/28 | Chapters: Welcome to Sophos (57.51s), Sophos Products Overview (233.9s), Internship Program Overview (392.295s), Office Culture (629.12s), Team Presentations (749.895s), Sophos Fusion Architecture (787.13s), Windows Endpoint Protection (1457.02s), Linux Endpoint Team (1802.21s), Core Products Team (2438.5s), Platform Engineering (2863.435s), Q&A and Transition (3529.36s), Intern Experiences (3572.565s), Intern Q&A Session (3873.885s), Interview Tips (4065.25s), Choosing Sophos (4484.695s), Closing Q&A (4570.085s), Application Process & Closing (4634.61s)
Transcript for "Placement Year With Sophos 2027/28":
Hello, everybody. Just to let you know, we're letting a few more people join, so we'll start the webinar in a few moments. Hello, everybody, and, welcome to the placement year at Sophos, webinar. My name is Mark Flattery. I'm a director within the engineering team in The UK, and I organize the placement year program. So the agenda for today is I will start off with an overview of Sophos and what we do at Sophos and also an introduction to what the internship program is. Internship is the same as placement year. We use the word intern for our placement year students at Sophos. After my intro, we'll meet the managers of some of the teams, and each manager will talk to you about what their team does and the things that their interns have worked on in the past. And at the end of those presentations by the managers, you'll have a chance to ask them questions. There is a q and a section in the webinar. So if you want to type any questions as we go, we may answer those, in the chat, or we may answer them in the q and a with the managers where they'll come on stage with me. After the managers, you'll have a chance to meet some of our current and former interns. They will tell you a bit about their experiences as an intern, and you'll be able to ask them some questions as well. And finally, I will just briefly explain how the application and selection process works for our internship. So about Sophos. Sophos is a a global leader in cybersecurity. Sophos has been around for forty one years, actually started here in The UK all those years ago, and it's grown to such a large organization that now we have over 625,000 plus customers worldwide. And customers means businesses. Software sells its products and services to businesses. On the top right there, there's a diagram of our global MDR analyst coverage. MDR means managed detection and response. So it's a service where people and AI protect our customers. And you can see on the left that we have the world's largest agentic SOC, and the SOC is a security operations center. I'd like to draw your attention to the the text in the bottom left there. So we have over 1,400 engineers at Sophos, 1,400 people who write software and do testing. And over a 170 of those engineers are based in The UK teams. And of those a 170, over 50 of those engineers began their careers with Sophos with a placement year like this. This slide shows all of the Sophos products and services and how those products and services work together to form a a unified solution that protects customers in-depth. And we call this sort of unified system Sophos Fusion. Around the outside of that circle, you can see many of the Sophos products. And and I won't go into the details of all these products and what all the different acronyms mean. But I will mention the one at the very top there, Sophos endpoint, as that's one of the areas in which our interns will typically work. So within the Sophos engineering groups, there are three major business units. There's the cloud platform business unit, the network security business unit, and the end user security business unit. Each of these is an engineering team with developers and testers. And the team... The group that's most relevant for this webinar is The UK, end user security group, ESG, and you can see in the top right there. Because the UK engineering group looks after endpoint computers, Windows and Linux, servers, and also the cloud management software. And you can see in the bottom there examples of things that they developed in The UK, Sophos Fusion, which is the the web the web front end interfaces for all of our products, Sophos endpoints for Windows endpoints, Linux server protection, and our products, XDR extended detection and and response, managed detection and response, anti ransomware, and exploit prevention. So all of those things in the bottom there, those are the things that are developed here in The UK by the engineering teams for the end user security group. So what is this, Sophos internship? It's a it's a one year industrial placement. It will start in summer twenty twenty seven. Typically, it starts in July and runs for twelve months. Anybody who's studying at a UK university for a bachelor's or master's degree that includes a year in industry is welcome to apply. You'll be working either at home remotely or you can use the headquarters in Upington, Oxfordshire, which is where I am right now. You'll learn more about that in a bit. And during that year, what you'll gain is real world experience, real world software development experience. You'll be you'll be part of a team, working on real software, not sort of toy projects, and with the possibility of a job offer for after you graduate. The number of placement positions that we have this year is still to be finalized, but to give you an idea, it's typically around nine or 10 placements. So what you can expect if you take on this internship is to join one of the engineering teams for the whole year. You don't move around teams and do bits and pieces. You become part of a a smallest team and stay with that whole team for the whole year. Within that team, you get deep understanding of the area that they work in, and you you soon contribute effectively. You work with the QA team and the software engineers. Some of them will be juniors. Some will be very experienced, and you'll have the same opportunities for development and for interesting projects as our permanent staff do. You'll gain experience beyond what you might learn at university. So things like testing and automation may not be covered in-depth at university, but that's very important to us. You'll learn these skills. They can help you in your final year and in your future careers. You'll receive mentoring from your manager and your teammates. We, we pair people up, so you have maybe a a buddy or someone to work with who will show you how things work. You won't be left on your own. You'll focus on technologies that will be new to you. You won't be expected to know all the languages that we use or all the technologies you will be taught them, and you'll be surprised how much you can learn in one year. We have an overriding focus on quality. Quality is incredibly important to Sophos. We have continuous integration, test automation, and root cause analysis. As I mentioned earlier, you'll work on real software, the real software that we deliver to our customers. There are no special intern projects. So I know at some organizations, interns are given made up projects, exercises to do. That's not what happens here. From day one, you'll be making our pro... Our products better, fixing problems in our products, and improving the features. For after graduation, the highest performing interns may receive an offer of permanent employment for the... After the year. So finish your intern year, go back to university for a year, we might offer you a job after you finish at university. You'll be involved in all stages of development from planning right through to implement... Implementation and testing. Many of our previous interns have returned permanent employees. I mentioned over 50 of our current engineers started this way, and many have advanced into senior technical roles and senior managerial roles. And you'll meet some of these people in this webinar. This photograph is our rather fantastic office in Abingdon, our headquarters. It's where I'm speaking to you from right now. And this office is is a wonderful place to work, but we... Our primary way of working is remote working. So we are a remote first company, which means that's what's the default. So for all of our engineers, working from home is the default. It's fully supported, and that's true for our interns as well. However, we do have this office, and, most teams like to come into the office one or two days a week. Some people come in every day of the week, but Wednesdays is a day when lots of people come to the office to to meet up and collaborate face to face. It's your choice as an intern. You can work from home for you remotely, or if you wish, you could move closer to Abingdon and, come to the office as many days as you like. Just some photos of inside our office. The photograph on the left is, is a sort of very pleasant breakout area, which is right next to the area where all the development teams are are working. And the photos on the right, that's our Ground Floor, sort of cafeteria area. We have table tennis, table football, and pool. It's a great place to socialize. So things that our HR team organize include social events, charity events, and volunteering opportunities. So on the left there, you can see some photographs at our office of a a sports day that we had. Also, very recently, a couple of weeks ago, we had an eighties or revival day with, like, video games and all eighties memorabilia. On the right there, on the right hand side, there are photographs of, charity and volunteering events. We have an allowance for people to do volunteering days, which means you can spend a few days each year going to some organization or charity to help to volunteer. Sophos celebrates diversity and, making this... Making Sophos an inclusive workplace is is very important tool so that everybody feels, valued and is able to do their best work. And this is just a a a a grab... Screen grab from our internal HR website. We have some internal groups for things like LGBTQ plus and SOPOS women in technology. Lots of resources, lots of, events going on to sort of promote and and, organize things. Yep. That's diversity. And team presentations then. So we'll move on to, the team presentations from, the central team, which is Ruth, the Windows endpoint team, which is Donna, the Linux endpoint team, which is Ethan, the core products team, which will be me again, and the ESG platform team, which will be Richard. So each manager will come on stage, talk about their teams and what they do. You can type in questions. At the end of these five presentations, we will come on... Or come on stage, and you can ask us questions. Okay. So moving on is the central team. So, Ruth, would you like to come on stage, please? Hi. Thanks, Mark. Hi, everyone. My name is Ruth Canomato. I'm a senior manager, and I have worked at Sophos for nine years. I manage one of the five central teams, that work in endpoint security. In total, we are around 60 people working in in, endpoint security in central. So what is Sophos Fusion? Sophos Fusion is our cloud management portal that consolidates into one single view all the information related to all the next gen products across a customer's organization, and that can be computer, servers, mobiles, emails, firewall, etcetera. From Fusion, customers can configure their security policies and access live data and generate detailed reports across their entire state so that they can report, respond faster to to threats, with a greater confidence, basically. There are more than 25,000,000 endpoints, reporting daily into into central, multiple times a day and sometimes even, every few seconds. And and that numbers continues to to grow. Therefore, central teams are constantly monitoring and adjusting the the platform to ensure that it scales. And and and for that, we need to to always choose technologies that help us to to adjust to the demands of... That that that is actually placed, in the system. What you're seeing in this, screenshot is what central looks like. It's accessible, Fusion is accessible as a web page via browser. What you can see in here is, is our bespoke so far dashboards, and that is made up from the individual widgets. Customers can can choose and make their own widgets and and customize their dashboards as well. You can drill into more detailed information in, some of these widgets. In fact, from one of those, you can access. You can click, drill into it, and that will take you into the device list page, which is being written by my team, both the front end as well as as well as the the back end. It's got some icons to the to the left that allows you to select which which columns you want to see. You can arrange the columns, and and you can you can access the the... A very powerful filtering capabilities to to drill down into into the devices that need more attention, as well as sorting. It does support sorting as well. From from the name of the devices, you can click on it, and it will open a a a fly out with more detailed information for each of the devices. The flyer can also open as a stand alone. And and all of this is being written by by my team. It also allows you to take actions. Like, for instance, you could select the the set of endpoints that you're interested and assign the protective software all in one go, or you could run a scan to make sure that there is any... That that there is no fits, for those devices, etcetera. So the the UI is is very sleek and and is very stylish, but Sophos Fusion is more than just a website. If you were to look under the under the hood, you will see that the back end is very large and has got a very complex architecture. So if I move into the next slide, I can I can explain a little bit about, Fusion architecture? Fusion started, is is more than ten years old, and and it started its journey as a a handful of large monolithic services using as the data store, the non relational, data store, Mongo. Over the last few years, we've been migrating the code into individual microservices. Now we have around 300 microservices across all central teams in in the Sufio... Fusion, platform. Each microservice tends to focus on a specific business capability, and it can be developed, deployed, and scaled independently of each other. Fusion services tend to communicate with each other either via rest APIs or messaging queues such as Kafka or SNS and SQS queues. For example, the UI talks to the backend through a rest API. And we also suppose the public API so that customers can can, use, automated tags or tasks or build their own custom tools or or interfaces on top of the the the back end platform. Each microservice own its own data and and chooses the data store that suits their need. For example, in... For the microservices owned by my team, we tend to we tend to favor Postgres, Elasticsearch cluster, s three buckets. Those are all very popular choices. But CSC is part of a bigger central team that spans across multiple teams in several locations, like like Mark pointed out earlier, UK, America, India, to name a few. Within CSG, we own 26 microservices out of those 300 microservices that I I mentioned earlier. And and those are the... And that's what it makes up the platform. And what that means is that we need to ensure that our designs, features align with broader architectural decisions, from other teams. So we need to actively manage dependencies, coordinate on deliverables, and generally collaborate closely with both central teams as well as with the rest of the endpoint teams, so that we can actually deliver end to end solutions. Our microservices support continuous deployment via our CI, continuous in in... And CD, continuous deployment pipelines, that allow us to push code into any of our environments like QA or production whenever we need to. So in this slide, you can have a a flavor of the fairly broad range of technologies that we use across the team. Most of our development in the back end is done in Java with some Python when it makes sense. For examples, we we tend to use Python when we are writing, helper scripts or tooling. For the user interface, we tend to use, Angular, HTML, and TypeScript. And on the data and cloud side, we work with Postgres, as I mentioned, and Mongo as well, and other AWS technologies such as s three buckets, Lambda, DynamoDB. Our back end is built with a a Spring Boot, and it follows a a microservice architecture. In terms of delivery, we use something what... Called Docker that allow us to package its service and its dependencies into an isolated portable container so that it's easy to deploy it in any environment, including the local environment for testing, which is very handy. And the CI and LCD pipelines that I mentioned earlier help us to build, test, and release those changes consistently in any of these, environments. And, of course, increasingly, AI is becoming part of how we work across all of these areas. We use tools such as Microsoft Copilot, Flowcode, or codex to support all of these activities, planning, development, troubleshooting, and testing. AI is present across all of the areas. This slide can give you a flavor of the kind of work our interns get involved in. This is a real example from our previous intern in Chandra. One thing that is worth highlighting is that developers, work across the full stack. So interns are exposed to the same technologies and areas of the product as the rest of the team. They are not limited to a single component or given a... An isolated task. In Kamchandra's case, he contributed adding several fields to the to the device list that I mentioned earlier. On the data side, he had to update a Postgres data model to support the new information, make sure that it was ingested in the platform. He exposed those fields then in the rest API... Rest API. So, it was available in the public rest API as well. And he worked in the user interface, adding the the new columns for these new, fields alongside support with sorting and filtering for these new columns. So So he gained experience with both back end and front end development. But beyond writing code, he was also involved in, delivery and operational activities as well. Within his first couple of weeks, he was already raising pull requests, and he later worked on library upgrades, Terraform changes and deployments across all of our microservices. And and the reason he was able to to, contribute so quickly is because, like any new engineer joining the team, he also spent time pairing with more experienced developers, particularly particularly when he was working in in the Java service. And that helped him to get speak... Up to speed quickly, build confidence, and understand how we design, maintain production systems. As the the placement, progressed, he became increasingly independent, taking on work with less day to day guidelines, which is what we aim for all of our interns. Overall, our interns are treated, as any other software engineer in the team. They're involved in real projects, use the same technologies and development process as everyone else. Hem Chandra is now back at uni finishing his his, degree, and he will be able to join us next year as as as a permanent employee. And now I hand over to Donna to talk about the Windows endpoint. Over to you, Donna. Thank you, Ruth. Hello, everyone. So my name is Donna Miles, and I'm a director of software development for the Windows endpoint team. So we work on providing protection from hostile actors. There are nine development teams that make up the Windows group, and I manage a couple of those. I've been working at Sophos for thirteen years and actually started as an intern myself. So I started as a software engineer, loving the problem solving aspect of the role, and then as time passed, I took on more responsibility as a dev lead. So this was more about coordinating the team and ensuring delivery of projects. Then I realized I wanted to help others achieve their career goals and to give them the experience I had with growth and opportunities at Sophos. So I transitioned into management, and here we are today. K. So the softwalls endpoint is designed to stop attacks before they run. We build the applications that protect our customers' Windows devices, so our code is running on 20,000,000 computers and 2,000,000 servers. Because of this, we need to ensure that our code is robust, secure, and performant. Here's an example of some of the powerful features we have. There's the sophisticated protection built for the AI era to stop threats launched either by humans or agentic AI tools. This includes over 60 exploit mitigations that also target the techniques in play. We have airtight ransomware protection with our CryptoGuard feature, preventing malicious encryption whether running on the victim's computer or from a compromised network connected device. When an attacker is detected, the endpoint will switch to a more aggressive mode known as adaptive attack protection. This disrupts and contains the attack. So there's lots of interesting features to learn and to help us develop further. It really is rewarding knowing you're making a difference by protecting customers from emerging threats. So as I mentioned previously, we have multiple teams working on the Windows endpoint. So these teams own different components that make up the product. We have components that are responsible for detecting and blocking threats, so providing that protection element. We work closely with Sophos Labs whose data we use to assist with this. Then we have components that are used for gathering data from events happening on the endpoints. So this is sent up to our data lake and can be used for analysis and detecting malicious activity across a customer's estate. Fusion admins then have the ability to look back at older data stored on the endpoint through live discover or remediate using the live response capability. The remaining components are used for installing, updating, managing, and providing supportability. We gather endpoint telemetry from our components, and this helps us monitor our software rollouts and also helps guide development of the product. During the placement, you'll be assigned to one of the teams, but there will be plenty of opportunities for collaboration and knowledge sharing with the wider group. For example, each sprint, we hold a department demo session to keep everyone in the loop of the new features we've been working on. We have a range of technologies in use, and I'm sure this won't come as a surprise that AI is used throughout development. Most of our components are written in c plus plus with the exceptions of user interfaces. They're written in c sharp, and then we have a live response, which uses Rust. We have some rule files for the event processor, which is written in Lua, and then we use Python for our test automation. So during your internship, you'll get the opportunity to work with these technologies firsthand, expand your technical knowledge, and gain practical experience on real projects. So what does an intern do? One of our previous interns was Julia. She joined the team working on the event processor, which is an important component that handles system events and is used to make detection decisions. Julia was responsible for measuring and profiling the flow of events through the system, investigating how this scaled as events increased, and looking for any bottlenecks and performance characteristics. She gained experience writing code which communicated with our low level kernel drivers, which are deep down in the operating system, intercepting and analyzing system activity. She also developed expertise in automated testing, troubleshooting test failures, and implementing improvements to enhance reliability and stability. One of the important skills she gained from this was learning how to analyze crash dumps, you know, to work out which part of the code was causing the issue. And finally, she gave a demo, as mentioned previously, to gain feedback from a wider group of engineers and to highlight progress to stakeholders. As an intern at Sophos, you really are treated as a valued member of the team from day one. It's a great opportunity to kick start your career, gain hands on experience, and make meaningful contributions while learning from experienced engineers. That's it from the Windows endpoint team. I'm gonna pass over to Ethan. Right. Thanks, Donna. Yeah. My name is Ethan. Just like Donna, I was also a former intern many years ago, and now I'm a manager of one of the two Linux teams here at Sophos. So what does the Linux endpoint team do? Well, you just heard a really good summary of what Windows teams are doing. Broadly, we're trying to solve the same problems, but with a different focus. What our customers care about are just slightly different to what Windows customers care about. The technologies that we're able to use are just a little bit different. The priorities are different. It's really interesting trying to maintain this feature parity across different products while having to think creatively about how you solve the same problem a different way. Some of the priorities we have for Linux is that the product needs to be easy to install and manage preferably remotely, preferably via scripting. We have to have the same kind of multiple layers of security. So, you know, you're detecting potentially malicious activity and quarantining the malware. A lot of the same headline features that Windows have and Mac have, but the definitions are different. Like the, on Linux, you have way more of what's called living off the land, which is where a bad actor would instead of kind of using bespoke, tools to to exploit a machine. They're using benign native tools, maliciously. Kind of detecting kind of norm behavior and suspicious behavior is is different. So requires different logic and different rule sets than other products. Centralized management, you heard from Ruth about fusion. We need to connect to surface fusion for administration and centralized reporting. But way more than Windows where a user will be at the laptop. Fusion is almost the only way we design the Linux endpoint product to be interacted with. We don't have a UI. We have some command line capabilities, but that's more of a support role, more of a things have gone wrong, let's investigate. Predominantly, we are designing our features to be maintained and managed and interact with via the eWeb portal of Fusion. Some of the key differences are performance. I'm not saying it's not that we are more performant, in some ways or we're not. But in in in terms of how our customers view success metrics, it is different. They're way more likely to complain about c... Excessive CPU usage, not giving back memory to the system, how we interact on different sized machines. Performance is a huge priority for our customers. That's something we have to think about slightly differently. A wide variety of platforms. What is Linux? With Windows, you've got a set series of versions. We've got Ubuntu 18 o four, 20 o four, 22 o four. I've started way too far in past, but there's also Red Hat, there's CentOS, there's Mint, there's Miracle, there's thousands of distributions. How do we support them? Which ones do we support? How do we support them all? It's an interesting challenge. And how do we communicate that to customers, so to keep them happy and keep up with kind of trends? So move away from CentOS towards things like Rocky and Alma. It's an interesting challenge. And then there's also this idea of cattle versus pet service. This is the idea that, maybe back when I started as an intern around 2015, 2016, most Linux servers were what we're calling pet servers and that they are these big beefy machines in in the backroom. And if something goes wrong with them, you're gonna go and fix it. You need that to stay alive. You love that machine. Get sick, you heal it. We need we need to make tools, to remediate. Whereas now with Cloud computing, we're seeing way more cattle service. These are servers where they're lightweight, they're in the Cloud, something goes wrong with one of them, you kill it, you spin up another one. Remediation tools aren't as prevalent or as necessary, but detecting tools are way more important. That kind of speed of detection is way more important so that someone can can take action kind of wholesale. It's interesting seeing the trends over time. It's never it's never boring in this industry. There's always changes, always new things to deal with. We're running on considerably fewer machines than the Windows and fewer than Mac, about core of a million every single day. Our code must be performant, robust, and secure. And for those paying attention, those are three words that Donna said earlier. They're not in the same order. And, yeah, the order is important. How how we go about it is slightly different. We have a lot of monitoring, a lot of resource limitation in the product, a lot of monitoring and endpoint telemetry so that we can see how the features are operating in the wild. Because we can test all different sorts of combinations of types of servers. There'll always be a Linux server in the world that's running differently to anything you'd imagined. We need to keep on top of how the features are working, how performant they are, how they change over time. You can see here on the top right one, you can see that memory usage spikes on the on the weekend. It doesn't even just what day of the week it is, affects the the, resource usage. It's when, customers tend to schedule the scans for weekends, I think. The endpoint architecture for Linux is broadly the same. It helps, that feature parity if we're approaching the architecture in a similar way. The main difference here is that we also... On the right hand side, we also offer the Linux sensor. This is for specifically like Kubernetes clusters, the world of containers. This is a very Linux problem, and we have a specific product to to fill that gap. Unlike, I think, Donna said there was nine teams, in Windows. I lose track. We're only two, working across many component areas. This means if you're out in one of our teams, you'll develop a wide breadth of experience through knowledge sharing and opportunities for ownership, because we all have to have a working knowledge of all of the components we we deliver. All of those layers of protection do offer many different features to work on. Technologies are again very similar. This allows us to share as much code as possible. For instance, that live response tool that Donna mentioned, that is cross platform code in Rust. Again, most of it's C plus plus main difference being a behavioral engine is written in C and Go and our install scripts are bash. Finally, what does an intern do? As as Mark mentioned earlier, all of our interns are effectively just regular software engineers on the team. The aim is always to kind of help them succeed, help them onboard, learn the product, and eventually gain an area of ownership by the end of the year. We wanna send people away, be my right call. This was my area. I did I did a bit of everything, but this was my area. I owned it. Someone had a problem, they came to me because this was mine. Previous interns, what did they get up to? Ayesh, a couple of years ago, took ownership of our performance testing rig and helped develop new tests and monitoring tools that alert us to performance issues in the product as early as possible. William, he helped plan and led the development of a feature that compartmentalize the product and helps prevent excessive file scanning from blocking behavioral scanning from running properly. So the idea of if our file scanner is absolutely going off, scanning some huge files, you don't want it to use all of the products, some CPU cycles. You want to hold some back. You want to have a lower limit so that the behavioral scanning can continue to function. Peter, he's our current intern. In his first three months, he's not only gotten stuck into future work, but has already pushed a fix back into the open source project, which is very cool. He really... We... He found a bug during our test, during our QA week. He investigated it. He worked out what the root cause was all the way back to the open source, library, open in this in this scene with them, got it fixed. That is now out in the world. So his impact that he's been able to have in his Sophos internship is spread way wider than just at Sophos, which is really cool. And again, as mentioned, like, I'm a former intern. There are three other former interns on my team. We all... Which means we all understand what it's like to be fresh and new at something. We provide a supportive and understanding environment in which hopefully, you can grow and realize your potential. So that's it from me. I'll hand over to Mark. He'll talk to you about core products. Thank you, Ethan. And, Ethan, there were a few questions in the chat. You might wanna take a look. Some of them are for you. Otherwise, we can talk about those when we get to the q and a in in a few moments. So I'm gonna talk about a team now that's called core products. Core products is one of the the longest serving teams. It's been around for many, many years at Sophos because core products looks after some of the most low level antivirus components in our products. So what do we do? We look after something called the antivirus engine, which is a a library. It's written in c. It detects malware in files, and it it's basically embedded in many of our products as we'll see in a moment. It's... It works very closely with Sophos Labs. Sophos Labs is a group within Sophos that really deals with threats and malware and actually understands them really, really well. So we have, we do file analysis within core products. So, analyzes file contents, runs dynamically updatable scripts to identify the malware. The engineering skills that you need in core products where we learn file formats, so we're scanning things like Microsoft Office documents, archive types, archive files, PDF documents. We have to learn a bit about all of these different file formats because we have to be able to scan them. A lot of the work we do is very low level programming. We're applying algorithms to solve problems and learning how to debug some quite tricky try... Quite tricky issues. I mentioned we work with Sophos Labs. They they know about malware. We... So you learn a bit about how malware malware works, and the vulnerabilities that it uses, and we get to work closely with Sophos Labs to improve detection. And a very interesting thing about core products is that we're a cross platform team. So you've heard about the the Linux team and the Windows team. We also have a Mac team, which is in... Mostly based in Canada. But the core products team develop libraries that run on each of those platforms. So we have a Windows engine, Linux version, a Mac version, an Android version, a free PSD version, and it's used in many of our products. We also sell the engines to other companies. So there are some famous names that I can't tell you, but there are other cybersecurity companies that also use the Sophos antivirus engine in their products. Other things that we do in core products, we have, within the Windows endpoint, specifically, we own a component called the Sophos file scanner, which combines the the engine also with our machine learning libraries and our reputation lookups to give an an overall file scanner on our Windows endpoint. Also, on the Windows endpoint, we have a cleanup tool, which removes the malware after it's been detected. On the Windows endpoint, we use modern c plus plus, and we work on a very large codes... Code base, which gives you great experience in fixing issues. So just a bit more detail about the Windows endpoint. So Donna's talked about the Windows endpoint product, some of the things there on the left that the product does. And I just wanted to highlight how core products are involved in in that Windows endpoint. So as I mentioned, the Sophos file scanner wraps up the AB engine. And, also, we have a content analysis library, which was also used to find, you know, data leakage. At the bottom there, we have this cleanup tool. So the Sophos file scanner is used to scan files, to flag them when they're malicious. And then when they're flagged as malicious, the cleanup tool is invoked, and the cleanup tool will remove the files. But, also, anything that the file's done, if the file's already been active and executed, it may have created lots of other files. It may have written things into the registry. The Cleanup tool finds everything that the malware did and cleans it all up. So, yeah, just again, where is this engine? So I've got the old gear or cog, icon to represent the engine, and we can see sort of things flow from the Internet through the gateways. So gateway products include the Sophos firewall and the Sophos email product. These are gateway products that scan things as they enter the the the organization, and the antivirus engine runs in both those those gateway products. So Sophos firewall is a Linux based product, so it's a Linux version of the engine. Same for Sophos email. That's a Linux based version of the engine. The engine runs on servers, so Windows servers, Linux servers. Basically, we have server protection. The engine runs there, again, in various platforms. And on the sort of... On more on the endpoint on the right hand side, our Windows endpoint, a Mac OS endpoint, a mobile endpoint, and the Linux Linux endpoint. So, again, the AB engine is built cross platform. It's used in many places. So in many ways, it's some of the code that is used most widely in any product worldwide. All of these Sophos products plus lots of OEM partner products are running this code all the time. So some of the things that our interns have worked on in the past, so interns learn c plus plus or sometimes c from scratch, and they become very proficient by the end of their placement year. So Julia is currently in our engine team. She started in in just this July. And just this July, by coincidence, Sophos joined the Anthropic Glasswing project. If you might have heard of that. So this is the project that allows organizations access to the Mythos five, AI tool for finding vulnerabilities. So we've been examining our own software with the Mythos AI tool. We found vulnerabilities in our engine, and, Julie has been working on fixing those vulnerabilities that the AI tools have found. Greg was a previous installer. He... Installer. In turn, he worked on the installer for the wind... The SFS in in the Windows endpoint. So let me say that again. The softwares file scanner install and the Windows endpoint is what Greg worked on. And he fixed bugs. He added additional logging. He helped investigate many issues. He also worked on fixes in our in our cleanup tool. Robert is also currently, you know, permanent employee, was an intern. He improved the performance of the file scanner and its resilience and the reputation analyzes logging. The investigation and fix many bugs. So, so Greg and Robert are currently permanent employees moving towards senior grades now. Julia, yeah, the current intern, doing really, really well. It's a very friendly team in core products. All the teams are friendly. It's just that core products is a bit more friendly, with opportunities to collaborate with other ESG teams and and. And finally, I'm gonna hand over to to Richard who'll talk to you about the ESG platform team. Hello, and thank you very much for listening so far. So I'm gonna talk to you about what my team does, and it's a little bit different from what everyone else has, been talking about so far. Mostly, you've been hearing from people that write customer facing, software. So the things that they write will run on people's, machines or in their web browsers, provide them with access to software services. What I do is I do something slightly different. I am a platform team runner, and I focus on something completely different. So I'm gonna read you the Wiki page entry for what platform engineering is, and then I'll go through a few more slides. So platform engineering is a software engineering discipline focused on the development of self-service tool chains, services, and processes to create an internal developer platform. This shared internal developer platform can be utilized by software development teams enabling them to innovate. Platform engineering uses components like configuration management, infrastructure orchestration, and role based access control to improve liability. The discipline is associated with DevOps and platform as a service practices. There you go. That's the long description as we read on the Wiki page. And if you feel so inclined, you can go and have a look at the Wiki page yourself. But what does that actually mean? Well, the idea is we do lots of hard work so that the people who are writing endpoint software and web browser software can go and focus on their core discipline. They don't wanna worry about, like, test agents running. They don't wanna worry about worry about, like, spinning up manual test agents to do testing things on. They don't wanna worry about how a thing gets built. They just wanna really work on that solid central piece of their expertise. So we take care of a lot of other things around the outside of it from the point of view of, making sure that, you know, software gets delivered to customers, that gets delivered in secure and safe way, and also make sure that things are configured in the right way so things are working and get there. So in terms of, the thing I just talked about, more specifically... Again, excuse me. I'm just gonna zoom this in a little bit because I can't read it. So I talked about, what we do. So it's a platform engineering, it's a software engineering discipline for tool chains and self-service workflows. We provide things to our internal customers, so all the engineers in the other teams to make sure they can do what they need to do. It's a shared platform, so lots of people use it. We provide lots of different tools from looking at the results of tests to, being able to publish things. We're there to be as reliable as possible. So, you know, we don't wanna be slowing people down when they're waiting for their builds or their test results. We wanna make sure that system is up as much as possible. So we've got lots of monitoring to make sure it is there. And we follow, DevOps practice as to make sure that what we actually do is done in a secure and safe way. So what does the ESG platform actually look like? Well, what I've shown here is a is a diagram of the things we do. And the arrows, if you notice, are going from red, which I consider danger, all the way through to blue, which I consider safety and happiness. So what you start off with is some code that exists in, GitHub repository. And you wanna build that code and you wanna make sure it's good, so you write some code development stuff and you write some unit test to make sure that code's in a good place. And we build things that run on Windows platforms, on Mac platforms, and Linux platforms, and on Android platforms. And we provide templates, so that people can pull down that code, build it in a reproducible, reliable way, in a secure environment. We don't actually people be able to pull things into those builds that we don't want to deliver to customers. All these things are in an isolated network. And once they've gone through this process and it's built and it's in a good place, it's in a slightly better place. Now we're gonna take those assets that come out there. So we've got to store all these assets and make sure they're still reliable. We also have to worry about the life cycle of those assets. The last thing you wanna do is have lots of build assets left hanging around, costing lots of money. You really want to just keep the stuff that you really care about. But you also want to make sure they're good. We provide an automated test rig. This means that the build come up... The assets come out of your build, you want to make sure that you go through a slightly higher level. Unit tests are kind of very small, low level. You wanna do some integration tests. You wanna make sure your product works in a sensible way. So you can spin up some test agents. Test agents slightly different from build agents. They can talk to anywhere in the world. So you can pull anything off the Internet to test against your test agent, or you may even want to test your agents against real live viruses, and we provide a a safe, secure network in which you can actually put your software in there and then actually do test detections against real viruses for a kind of a VQA rig. There's also an element of testing where, you know, automated tests are great. It's good to make sure that things behave the way they did before you change your software, but you also want to be able to do exploratory tests around that software as well. So you wanna be able to spin up a a Windows agent, for instance, install the endpoint and go and click all the interfaces and click in places that people might not normally click or might not be covered in your automated test just to make sure you've actually harden that software as much as possible. We also provide a manual test agent system where you can spin up a choice of about 30 different templates and lots of different platforms from Linux to Windows, even back to Windows seven. Install the software and actually have a play around with it and make sure it works the way you want it to. All this is basically hardening that software to get into a decent state so it's ready for delivery to customers. Once you've gone through the test, you got everything else? Your product is getting safer. Now we have to make sure there's lots of checks and balances. Supply chain attacks are a real thing. And the last thing any security company wants to be responsible for is a supply chain attack that goes out to their customers. So we are very, very tight in making sure that we, make sure all our infrastructure is secure as possible. We, you know, secures... Security by design all the way from the very beginning. We also make sure that only the right people are allowed to do the right sort of actions so things don't end up getting software. They don't... Software doesn't end up going into customers' boxes, which could be dodgy. So we'd all sorts of really important things around that and, maintain the security. It's also important that somebody looks after that. Right? And you've got all these engineering teams that might have different specialties. It's important that we... That you've got one sort of central place looks after it. So that's what happens. So we make sure that only things that can be published to customers have come from specific place. We make sure they've been scanned in the right way. We make sure those assets are linked directly to some source code. If anything does go wrong, we can go back and find exactly where that code came from. We make sure we audit everything we do so that anything that ever leaves or is built inside that bill system, we can find out exactly who pressed the button that made that bill happen. We can find out exactly who created that, and we can find out exactly when it was signed and all these other things. These are really important to make sure you keep that good solid security life going on. But all that takes effort and time. And, you know, you need to you need to look after all this stuff. And and the way we do is we use a bunch of microservices, of course, in AWS. We use all sorts of technologies like Docker, Kubernetes. We we... We're we're interested because we we not only deploy services, so we have to worry about infrastructure as code and controlling those services being spun up. But we also actually build the services that have been deployed as well. So we're basically full stack developers working all the way from the bottom of databases all the way up to the front end software. Working in my team, you probably could do some front end development, you might do some back end development, you might deploy database, you might be involved in also switches and things like that. We talked about the life cycle of pushing things through the software chain. You've done your build, gets better, you do your test, it gets even better. It's good enough to be published. We've done all the checks and balances. It goes out to the customer. How you need to know, is it doing what you think it should be doing? Are we breaking customers? How do we do this? Well, as a telemetry process, so endpoints typically send back some information, once a day. Some endpoints sent in information back hourly. By monitoring what information tells you, you can tell sort of things like how many customers do we have? Is the software where can we expect it to? Is it updating and all that sort of thing? We help provide the telemetry systems we look after, you know, ingesting all that data from customers' endpoints and putting it into a platform that other people can look at. And we also help manage that platform to make it look... Make sure that people can actually make diagrams all the rest of itself, and that's the end point. So you go from from source code all the way for the life cycle through to actually monitoring what's happening on endpoints. And my team has its fingers in every little piece of this somewhere along the lines. What can somebody working on the SD platform be expected to be looking at and doing? So, you know, DevOps and software development. So we we look after the CICD pipelines. We have multiple environments. We test things in a in a a copy of the live environment multiple times to make sure the things that we release to people isn't broken before it gets there. That's important. Uptime is really important to our customers, our internal customers. And because they're internal customers, they know me on a first name basis and will come and pat me on the shoulder when things go wrong. So it's important I keep them happy because I don't need any bruises on my shoulder. We use infrastructure as code and secured by design practices. We follow a similar sort of development cycles of sprints and demos and retrospective, make sure we're keeping getting better, make sure we know what's going on in the team every day. There's an opportunity to learn from experts. There's pair program opportunities. Generally, my team people will get together on a problem, work out what they need to do, go and split and come back and discuss it further and further. The newer you're in your gear... Career, the more time you'll probably spare a pair program. The later you are, the more you might actually be helping other people and supporting them. My team does the service team experience. So, yeah, we got people coming asking us for things. So there's always tickets coming in every day of things we need to get moved through fairly quickly. You've also keep keep an eye on what the system is doing when things break and go down. You gotta be there to kinda get it up and going again. And, you know, you'd be involved in triaging and looking at what we're doing with the daily request every day. As I said before, we're full stack microservices, so it's docking containers, Kubernetes. We use async Python backends. We've got some Rust in there. We use Node. Js and React for front ends. Obviously, there's databases. We have lots of rest APIs, and most of the stuff we actually do is based in AWS, so there'll be a lot of experience with using cloud based services. And, of course, we follow quality focus practice. So, you know, there'll be pull requests. You'd be expected to unit test, integration test, deployment test since linting, and all sorts of things like that. So by the time you get to the end of it, you really know... Will know what good code actually looks like. And in terms of what the interns have done in my team in previous years, they've done all sorts. They come in. They spend a small amount of time at the start doing small tickets, getting to learn about the various different piece of architecture. And, generally, by the time they get to the end of the year, we try and get them to create a new service to be put out to customers. So last year, our intern, Tom, created an MCP server for accessing the results from our, build and test system so people could go and point their AI, bots at it and ask you questions. And he worried about things like making sure that's authenticated, making sure we don't expose any data that we shouldn't be exposing. A year before, we had an, an intern that basically built a durable cache, which was a way of caching signed assets, which could be pulled back later in the build process. That helped to make it much easier to release software because the stuff that we were putting out the end of the system stayed the same unless something really did fundamentally change underneath it independent of how long the asset had been built for. So that's pretty much what it is in the SD platform team. We're an internal facing. We touch lots of things that are cool in the cloud, and it's kind of full stack development stuff. Okay. Thank you very much for my time. I'll pass you back to Mark. One hopes. Yeah. Anyway, thanks, Richard. So, yeah, let's move on. So, yeah, so that's... Those are the teams. So, we'll just pause for a few moments to see if, if anybody has any questions and if they're specific to a team we can bring back on, the managers to answer those. Just see if we've got any. Okay. We... We've answered quite a lot of questions in the chat. I hope that's been been helpful. If there are any more, we can we can come back. And for now, it looks like we're we're a bit quiet on the questions. So I'm gonna move on to to meet some of our current and previous interns. So so Ida, Felix, Zach, and Tara, would you like to come on stage, please? Cool. Thank you. So, Ida and Felix are current intern Zach and Tara are previous interns, now, permanent employees. So, Tara, would you like to go first? As you've done this before a few times, you're kind of the veteran of this. Yeah. Sure. Would you like to ask about what you've done and your experiences? So hello, everyone. I'm Tara. I am an engineer on the Sophos central team, which is the team that works on the Sophos fusion product as it's now called. So I'm a full stack web developer, basically, and I absolutely love it here. The best thing about Sophos is the culture of learning. You can start at the beginning and not know anything, and, usually, it's met with great. Let's go find out how we do that. And you're given given a buddy, somebody to ask all your questions to. And, yeah, by the end of the year, I was like, what's the point in going back to uni? I feel like I'm ready to to just keep going. So... Yeah. Thank you, Tara. Let's go up up the slide. So so, Zach, would you like to go next? Yes. Hi, everyone. I'm Zach. I have a very similar experience to Tara and worked in a very similar team, also in the central endpoint team. To my internship, I worked on two or three main projects, and I was treated as any other engineer on the team. So we took full reign of the project working on both the back end APIs and the front end development. And what was really awesome was I got the freedom to pick up any tickets that were specifically interesting to me. And I had the liberty to work independently on these at my own pace. But, also, if I did get stuck, I'd have plenty of help as almost all my team were former interns. So I could go to any of them for help, and they'd be more than willing to help. And like Tara said, I also was very reluctant going back to uni after it. Okay. Thank you, Zach. Felix, how about you? Hi. So I'm Felix. I'm on the Windows engineering team. I've been bodied up with a previous intern as well, from only two years ago, so that's very nice. There's a lot of recent knowledge and, yeah, it's just been great. Any any silly questions, anything really you can go to, life advice, everything. So we have a catch up every few days, and that just helps to, touch base and just ensure I'm... You know, I know what I'm doing and I'm happy here as well. Yeah. I I, sort of co own a nano service with my buddy as well. So it's nice when he's off, people come to me. I feel very responsible. You know, any failing tests, any questions, you know, you do feel like a part of a team very early, and that is what is great about software is there is no... There is a small cooling off period where you're learning, but then it's just straight into responsibilities. And you do feel like a real member of the team, not just an intern. I know, I also do not wanna go back to uni as well, so I share that sentiment. Cool. Thank you, Felix. And, Ida, Hey, everyone. I'm on the Windows endpoint team as well. I'm with team Donna. And, yeah, I've been working on a real variety of things since joining. I didn't have any c plus plus experience, so it took me a week or two to sort of adjust to not only, like, the bigger code base, but also pick up some of the principles. But the team has been very welcoming, and the biggest thing is just asking questions, getting used to taking part in stand ups every day. I also have a mentor, and, it's been it's been great to sort of catch up and touch base on what I'm learning and regularly look back as well because every few days, you make you make huge progress, because most of the stuff I'm doing is different tickets. And it's really cool that you can decide what you wanna work on one day. It can be a small addition when you're starting out to owning your complete, as Felix said, as a nano service or working on a tool that you make. So the real... The variety has been exciting, and, it... It's it's a completely different pace from working at university where there's somebody, telling you exactly what you need to do. It's more proactive as well. So that's been a bit about what I've been doing. Thank you, Aida. So just for a moment, does anybody have any questions for our current and previous interns? If not, there are a few questions I can I can dive into anyway here? So one of the questions that's in the in the q and a that's not been answered yet is, as Sophos mostly does full stack development, what type of skills does Sophos usually prefer from the interns? So I have the interns here. I think I would say that we don't really care too much about the skills, specific skills that you've learned in center technologies. People know different things. But we do care about things like, problem solving skills, so general problem solving skills. Generally being an enthusiastic learner, we're looking for that. We're looking for good good team working, good collaboration, good communication skills. Communication skills are very important, especially as we're working remotely. So written communication and online sort of meeting communication are very important. So the main thing is, you know, everybody who's applying is generally a very bright person. You're all very bright. You're all doing, you know, really good courses. We're looking for that bit bit extra problem solving, teamwork, collaboration, and just enthusiasm to really get stuck in and to to be a willing learner. I think that also answers the question, what quality stand out in a candidate from either their CV or the assessment maybe. So, again, those those are the qualities that we're looking for. So it's it's great to see on CVs if if people have done lots of projects, done lots of things, but, evidence of things that people have achieved. Again, you're all doing fantastic courses. So look... Looking for sort of examples of things that you've done, things that you've achieved in life. Another question here, how complex of projects can I be assigned or based on ability will be assigned to suitable tasks? So I think the the the question there is, like, how complex will the projects be? Because we ask our interns to just join in with the teams, the projects can be quite complex, but that's okay. You get lots of support, and you get lots of help with those projects. There's no such thing as saying that prod... Problem is too complex. You know? People... We work together as part of a team on complex problems. There's a question about in terms of learning technologies, how is that structured? Are you provided with resources to use in the first couple of weeks? So the the the training is very much on the job. So there are resources. There are online resources. There are internal resources, for learning technologies and languages. But there isn't a kind of, like, you spend your first two weeks training. It's really straight in from day one and learning all the skills on the job. So we learn the technologies as you need to use them. And, we heavily use AI tools now, so they are a great help in understanding technologies. I think that's all the questions I have I think there's a couple in the just general chat. It's the the chat area. the usual ones, like, what's remote working like and what's what's. the day to day like. So, I work completely remotely. It's great. It means I get to still live with my parents, save up a bit of money. I don't have to pay for, Oxford rents, which can be quite expensive. What about others? Yeah. So I I live around an hour away from the office, but I try to go in most weeks on the Wednesday most of my team are in, and it just means it's a nice social environment for a day. While it's nice to go into the office, I do also appreciate being able to work from home. There's certainly luxuries you can take advantage of from that, such as, free rent living at the parents. Yeah. I I also live at home. I would advise going into the office, especially on Wednesdays. Some teams seem to go in more than others. So for example, my team, I think only one or two people going on Wednesdays. I've heard other teams where everyone's in on a Wednesday. So I guess it depends. But, yeah, working remote is... Sorry. Working remote is great, money wise, time wise as well. You can really... You really have freedom to, you know, use your time as wisely as you can. And... Yeah. Yeah. It is great. Yep. I also work remote, and I think the biggest factor to consider is staying connected with your team. I think that's usually why, you might wanna go into the office. So, remote, it looks like Teams calls, daily stand ups, and reaching out when you have a question. The smallest things that you just approach somebody at their desk for, that sort of translates into you having to send the message, and, it's always, met with, you know, enthusiastic responses. So, yeah, that's how I managed to keep connected to the team. Yeah. I think, my first six months of being an intern, I I had, like, a six month lease on a house share. So, I found that really helpful spending the first six months going into the office, because this was a few years ago, so there was more people in the office then. But, yeah, it meant that asking a question was just spinning around in my chair and asking somebody behind me. But, yeah, these days, it's just as easy to ping someone a message on Teams, and people are more than more than happy to help. Yeah. There's a question about what the first month is like. I think I should mention we do have a a sort of an induction day. So when the interns do start in July, we have one day where everybody's invited, you know, travel expenses paid to come to to Abingdon to meet their teams face to face. Even if you're going to work remotely a long way away for the rest of the year, there's that opportunity. You might have to start to meet people face to face, which is which is a good opportunity. And, I don't know if anybody wants to talk about the first sort of week because I know it it must be quite nerve wracking to to start that first week and your memories of that first week and that first month. Yeah. My first week... So the first few days you'll spend doing the compliance training, which can be a bit of a pain, but I guess it's just a nice time to settle in. But, apart from that, I was just introduced to my team, introduced to the service I'll be working on. So I think it was pretty much planned what I was gonna spend the first few months on from the start, which was nice. So there's already works out for me to do in the first few days, and that really helped settle me in. Small tickets, nothing too crazy, just understanding c plus plus and the services because there is so much to learn. Like, I learn something new about product every day, still, you know, still to this day, three months later. So, it's not it's not too fast paced, but it's also just straight in as an employee, which is great. Yeah. I can attest to that. It was mostly compliance. Also, the code base is huge. So even just getting access to that, was me asking a lot of questions, talking to AI to understand, certain components, picking different files apart, and reading the Wiki, just sort of exploring. You kind of get free rein, to to go and look into different documents and, kind of stalk the the people who wrote it in their pages and, through that, just, yeah, getting integrated into, what it's like to be in a big company. Okay. Thank you. I think we've answered most of the questions. So I'm looking back in the chat section now. Interview tips. So there's a... You know, we guess that we we get asked this every year. So the the interview tip would be, just be prepared to to speak. So when given a problem to solve, it's really good to talk through your thinking if you're in a sort of face to face interview. It can be tempting just to sort of, like, try and think about the problem for a long time and maybe you'd be stuck. But if you talk about what you're thinking and what your ideas are, that will help you to explain to the interviewer what you're thinking, and they will be able to help you with things. And show off the things that you've achieved. That's important. Look look for, you know, things that you've done in the past that that really show off what you can do. The question about personal projects with value from a candidate, for example, complexity size. Again, it's just it's just often showing that enthusiasm. So people who've done personal projects have maybe had a passion for something, that that could come through. So that's really good to see. We're also taking into account, you know, what you've done at university and what you've done, you know, that's non non computer science related as well. Yeah. I would I would say it's it's not necessarily that you absolutely need to have done a personal project either because I certainly hadn't, Yeah. just did my interview. It was literally like... I don't know if it's the same now, but it was literally like solving a problem in a text editor. Just talking through it, and that's that's the main thing. It's just meeting. I think it's actually... My current manager was the one that interviewed me, and just just seeing what you're like as a person. Yeah. Exactly. We're we're we're thinking about, when we're interviewing, is this a person that we think could be successful at Sophos for many years? It's not just about could they solve this problem in c plus plus next week. We're looking much longer term than that. There's a question about what, made you choose Sophos over other companies. I think that's quite a good question. For me, it was mostly location. Abingdon is a lovely place. A lot of the other places I was looking at, involved commuting into London, which I really didn't wanna do. What about the others? Mine was much more about what the company does. I was always interested in both software development and cybersecurity. So Sophos was kind of a perfect company, for both worlds. For myself, I just really liked the technologies that that, softwares use. So I was quite drawn in by the webinar with the use of c plus plus Rust Go as well. You don't hear much about Rust and Go in other companies. And I and I was quite interested at the time in those. So, yeah. For me as well, cybersecurity, was the big aspect because in school, I've done a few competitions like that, and, learning more about, those vulnerabilities, especially in this, like, AI era. I felt like I had... It it was very exciting to work on, as as threats are constantly increasing. So I wanted to see what it's like to work hands on on that. Thanks. There's a question. What's been the best perk of working at Sophos that you didn't know about before you joined or applied? What surprised you that's been good? I just really like the culture here and the people. It's it's really lovely not to have. There isn't any kind of, like, pressure, huge deadlines, or anything like that. It's, very much a team team culture. We will work together on things. We're all learning things together as well. And, yeah, anytime you don't know something is just kind of met with this attitude of, like, great. Let's let's figure it out together. Learning new things is is seen as a a good thing rather than it being a bad thing that you don't already know it. And it's always, like, factored into estimates of how long things would take as well. So... Yeah. And, like, you're always learning. Cool. Thanks, Tara. Okay. I think you've answered most of those questions then from our current and previous interns, so thank you very much, everyone, for for that. I'm gonna move on to the next slide, which is about how to apply. Hopefully, that's become clear now. I did post to one of the questions the link to the sort of the job description and a link to how to apply. But we will also send out an email to everybody who's attended the webinar to to make sure they have that link if they're not or... Not already applied, and you can apply from that link. Now we will be closing the applications at the end of Monday, so Monday the nineteenth. So if you do want to apply and you haven't done so yet, then that would be the deadline for that, please. Then we will review all the CVs and, you know, there'll be a lot of applications, I'm sure, and we'll select those that we'd like to complete an online exercise. So you might be asked to do an online exercise. If that goes well, you may then be selected for, an interview. We'll select 24 candidates in total, and we'll have two, recruitment days, we call them, on the November 3, a Tuesday, and the November 5 with 12 candidates being interviewed each day. This is all... This will all be online, in Teams. You'll... And, also, we use Codility for our interview platform. So candidates will be invited to one of the days. So you have one day where you're expected to join for a a small group activity. It takes about forty five minutes. So it's a group of four candidates solving a problem together discussing... It's not a technical problem. It's more a real world sort of problem just to see how people interact. I mentioned I'm lucky for that communication and team working, so that's what that's about. Then there's a one hour interview with, with two managers. So two managers will be there, and they'll be asking you questions about your experience, things that you've done, things you've achieved. And about half that interview will also be a sort of technical problem to discuss and talk through and see how you'd approach solving that problem. And then there'll be another chance to to meet some of our current and previous interns on that day. Because not everybody will have attended this webinar, so we'll have a chance to do that again. And and that's the process. So, yeah, we we look forward to to receiving your applications. So, yeah, I think there's nothing else to say today. I do look forward to hearing from you. Thank you so much for joining. I hope that, you know, if you do apply and you're successful, look forward to meeting you. Otherwise, I hope you, you know, enjoyed meeting Sophos and learning about what we do. So, yeah, have a great evening, everybody. Thank you.