.png)
SheCanCode's Spilling The T
SheCanCode's Spilling The T
Coding with passion: Emily Middleton on building tech that matters at Viator
Join us as we sit down with Emily Middleton, a Senior Software Engineer at Viator, a part of the Tripadvisor Group. With over four years of experience at Viator, Emily shares her journey from being inspired by her programmer father to becoming a driving force behind impactful projects in the tech world.
Emily's career at Viator has been marked by her passion for coding and problem-solving. Emily discusses the importance of career progression and flexibility for working parents in her decision to join Viator, where she thrives on the opportunity to lead significant projects while maintaining a hands-on technical role.
Tune in as Emily Middleton shares insights into her professional growth, technical expertise, and advice for aspiring professionals looking to carve their path in the dynamic world of software engineering.
SheCanCode is a collaborative community of women in tech working together to tackle the tech gender gap.
Join our community to find a supportive network, opportunities, guidance and jobs, so you can excel in your tech career.
Hello everyone. Thank you for tuning in Again. I am Katie Batesman, the Managing Director, Community and Partnerships at she Can Code, and today we are discussing coding with passion. I've got the incredible Emily Middleton with me today, who will be sharing her journey and building tech that matters at Viator. Emily is a Principal Software Engineer at Viator, a part of the TripAdvisor group. Welcome, emily. Thank you so much for joining us here today. It's a pleasure to have you on Congratulations as well. You just got a promotion, so we're going to start with that Congratulations first. Well, we'd love to hear a little bit about you, if that's okay. To get started, a little bit about who you are. Did you fall into tech? Want to go into tech? Just give us some set the scene for our ladies, if that's okay.
Speaker 2:Yeah, so I've been working in tech for nearly 20 years now. I had a very traditional routine. I studied computer science at university and then have been working in software ever since. I've done a few different roles, mainly engineering. I've done a bit of management. I did a stint in product as well for a while.
Speaker 1:And when you said you studied computer science at uni, what was that like? We hear from a lot of ladies that, yeah, I was the only one. I was the only female on the course. What was your experience and why computer science at the time?
Speaker 2:Yeah, there wasn't very many women women. So I actually started off doing maths and computer science. I always thought I was going to be a mathematician, but I took computer science at A level and really enjoyed it. So I thought when I went to university I'd do both. And in the first year I did not get on very well with the maths at all, but I really enjoyed the computer science. So I switched to that and did really well from there awesome.
Speaker 1:I I am so envious of people that say they wanted to do maths and could do maths, because you tend to do one or the other and I fell into words. But when people say they, they wanted to do maths, or people say I went on to do advanced maths and you're like I just I'd love to be one of those people that their brain worked that way oh, I thought I could do advanced maths until I got to Oxford and realized that no it was.
Speaker 1:Was that something at school, though? Was there a teacher at school that perhaps, if you have a really good maths teacher who kind of would inspire you to think, actually, I could go on and do that. I didn't like my maths teacher, so I didn't go in that direction.
Speaker 2:I had exactly that with science. Uh, they're not going to listen to this podcast, I hope, but, um, I at one point I thought I was going to be an architect because I liked maths and I liked art, um, but I was told that I'd have to study physics to go down that route, and my science teacher at school was not my favorite person and I was like gosh, I can have to study physics to go down that route and my science teacher at school was not my favourite person and I was like gosh, I can't possibly carry on with physics.
Speaker 1:It is amazing, though, how those early years, and who teaches you, can really affect what you're thinking of doing next and can inspire you to go in whichever direction. Yeah, definitely to go in whichever direction. Yeah, definitely. On that note, um, can you share how your early experiences with your father's passion for programming influenced your decision to pursue a career in software engineering? Because it sounds like it come from home rather than school.
Speaker 2:Well, actually my mum was a programmer as well, but before I was born, um, back when it was all punch cards, um, so it definitely runs in the family. And actually my son has just started doing code club at school. He's nine, so maybe there'll be a third generation soon. But yeah, growing up my dad worked at um, ibm, at the Hursley campus in Hampshire and it is just an amazing place. I don't know if you've ever been but um, but IBM has stayed for a very long time.
Speaker 2:Dad was there for 40 years yes, for a living, um, but then later on he'd be like mm. I sold a really good bug today and he'd tell me about it and he was obviously really excited about it and I think I got that same kind of itch for problem solving that he did. And I think coding sometimes has a bit of a reputation as being like quite solitary, like you've got the stereotype of someone hidden away in a dark room tapping away. But I never really got that from dad. Like he was quite sociable, he'd talk a lot about meeting colleagues from around the world, he'd go abroad, sometimes bring back to our house for dinner and um, so yeah, it didn't didn't fit that stereotype as well at all and he also had quite a few female colleagues that he spoke really highly of. There was one woman in particular he thought was fantastic. So again, going against stereotypes, I never felt that it was a kind of gendered thing.
Speaker 1:I absolutely love that because you you're so right. There is this misconception about coding, working on your own, what it will actually be like when you get into tech it. A lot of our communities say something similar, and when you actually see or hear from people that are doing the, do you realize what your day job would actually be like. And you said problem solving that's. That's pretty much what it is. If you're somebody that likes solving problems, a lady recently said to me it's like doing puzzles. I feel like I do puzzles and I have to find like the missing piece to something. And she said I just absolutely love that, but people don't always think of coding and working in tech in that way.
Speaker 2:Yeah, I think fixing bugs is my favourite thing. I think if I had my dream job I would be a consultant just dropping into people's horrible codebases and trying to fix their little bugs. But I think that exists as a career path.
Speaker 1:That must be a very satisfying job. When you fix one, you encourage others to focus on their passions rather than traditional career paths. How has this philosophy shaped your career, and what advice would you give to someone just starting out in tech?
Speaker 2:So I've always been quite willing to kind of try out new things, see what sticks. And when I graduated I worked for a small, quite a small company. And the good thing about the small company was that you've got a lot of opportunity to kind of fit gaps, like, oh we need someone to do this, do you fancy it? So I worked there for kind of six years as an engineer and then I had the opportunity to go out to Sydney for three months and that was kind of a slightly more customer-facing role. I was also helping them build out their kind of tech stuff there, doing some interviewing. So that was an amazing experience. But then when I came back I became a tech lead and again I enjoyed some parts of the role. I enjoyed kind of working out what the team should be working on, but I kind of found that I didn't enjoy managing people on kind of a personal level. But I did it again.
Speaker 2:I went to another company. I dropped out of management. I found myself in another tech lead role with ports and had the same kind of issues I had first time. Um, so I was, and at the time my manager was kind of talking about succession plans and you know, do you want to move up the management chain? And I was kind of conflicted because it feels like that is the expected career path for someone who's got some kind of soft skills, like you're an engineer and then you're a tech lead and then you're a manager and so on. But it didn't feel like that was actually what I would enjoy. But I was just worried that it would be a step back to not do that anymore.
Speaker 2:But then I came across this blog post and it's by a fantastic woman called Charity Majors and it's called the Engineer Management Pendulum. And this blog post talks about how management shouldn't be seen as a promotion. It's a lateral career move and if management isn't a promotion, that means that going back to engineering isn't a demotion. And she actually talks about how it can be really beneficial to swing back and forth between the two. And you know that was so influential to me at the time because it made me think, oh, actually, maybe I'm not stepping back. And when I came to look for, kind of, my next role, it made me think well, you know, let's forget about traditional ladders, and what should I be doing like, what do I want to do? What do I enjoy?
Speaker 1:yes, absolutely. So many people have that point in their career where they have to think do I now have to go into management to manage people? And so many people have that same thought. I really didn't like that. I really don't want to manage people. They're really unpredictable, or?
Speaker 1:maybe I'm at the wrong company to be doing this, and so you're so right you do swing between the decision and then go back and forth.
Speaker 1:And also I find that you you might want to do that at a different stage in your career as well, where, as opposed to when you were first given that chance and that that's okay as well to you know go and learn something else on your own, and then, a few years later, you think I'm slightly more experienced now, but then all of those thoughts come with it as well. So many people in our community have um and especially on our live events, they ask us questions about stepping into leadership and and the thoughts that you have around that that time and and how to deal with that um. And you're right, it's. I love the fact that you just think just just follow your passion and what you want to do, because that's what it comes down to, rather than trying to crowbar yourself into some management position where you've got to look after everyone and you are just not at all comfortable in that and, like yourself, you can still be successful and not have to be that traditional people manager.
Speaker 2:I think I'm picking up on what you just said about doing it at the right time, because you asked about advice. Um, one of the kind of conference talks that I've shared with quite a few people that I've managed now and I've said you really have to go and watch this. Um, it's another fantastic woman, uh, tanya Riley, and the talk is called being blue and you look, have you heard of it?
Speaker 1:yes, yeah absolutely that was amazing.
Speaker 2:Yes, yeah, so it's also um. So it talks about how, um, there's a kind of early career engineer that is still learning the coding a little bit, but they find ways to be helpful, like they maybe they write some documentation that's missing, or they set up a meeting because they realize people are steering off in the wrong direction, but ultimately this person doesn't get promoted because they're told that they did not contribute enough technically. So I think there the advice is it's the key about knowing what your company rewards and what is considered kind of promotable work for the level you're on. So which, for junior level is, is often you know the coding output. So, um, I love blue work.
Speaker 2:That was something else that I kind of found when I was deciding what I wanted to do, like I like, I actually like writing documentation, but it was it the right point of my career to work somewhere where that was expected and rewarded as opposed to just kind of plain coding, I think. I think also, if you do move into um a kind of non-technical role, but you think that you might want to move back again if you haven't built up that technical kind of credentials, that can be very difficult to say, and I think this is where, again, if you've got a traditional background I do you've got a computer science degree, it's much, much easier to go. Oh, actually, I want to do coding again now and have someone that's willing to hire you to do that.
Speaker 1:Yes, and just sort of train back up on the bits that you might have missed. Yeah, you're absolutely right. It does as well depend on the company, on the company, um and I love that idea of glue work, um, and that you almost have to uh, you almost have to, take a moment in your career and think am I doing that, am I only doing that? And then think, well, when I do want to go for that promotion or I'm ready to step forward for something else, how do I move myself from the glue work into a position where I'm going to be recognised for what I want to do next? Because something I'd learnt along the way as well was my employer.
Speaker 1:They're not mind readers. They don't always know that you even want to go for that role or that you're thinking about moving up the ladder, unless you say, unless you start moving into or working on things that could help you to do that. And sometimes your employer might be annoyed that you even thought I know I'm going to have to leave because I'm maybe not doing the right things here, whereas actually perhaps if you said that you were interested, then things might have changed. But I think that's instead of just sitting there waiting for someone to notice you sometimes.
Speaker 2:Oh, definitely, it helps to have a really good relationship with you. My manager now has will tell you that I have told him constantly since I joined four years ago that I don't want to do management yeah and just yeah.
Speaker 1:Make it clear you're absolutely right, what you want to do and and your achievements the year, whatever they are. Yeah, you're absolutely right. Just being clear on that. What motivated you to join Viator and how has the company supported your goals for career progression and work life balance?
Speaker 2:So, as we just mentioned, I had a very good idea of what I didn't want to do and not a lot of companies have got like a really good technical career path for without going into management. So I definitely wanted that to be a focus and, as you said earlier, I've just had a promotion, so that's kind of working out so far. So I don't know if you've seen there's a really nice diagram it's like a venn diagram and about how software engineering comes together and it's got the what, the who and the how. So the what tends to be product. Um, you know, product managers decide what we're going to build, the managers decide who's going to build it and the engineers decide how. And I've been in all three quadrants.
Speaker 2:I spent 18 months as a product manager and I spent a couple of years as a manager and I've spent a really long time as an engineer and I kind of got to the point where I realized that I like the what and I like the how. So it's finding jobs that have that kind of intersection, where you've got some kind of technical influence but you're also kind of deep in doing the coding. That was one motivation I started off working. The company I first worked for wrote financial reporting software and that was desktop software. So I found that there was not much of a feedback loop from our customers, like you'd write your code, you'd make a release, someone would go and install it on a computer somewhere and you'd never hear from them again. Whereas my second job after that was in e-commerce and you could see in real time kind of how customers were using the site. So I much preferred that. I wanted to work for something like a high traffic web application where you can kind of get get in real time data about what's going on. So vital was great from that point of view. You know it's it's a very high traffic website and you know I can push code and an hour later I can see. You know how that's flowing through the system and how it's how it's really affecting the customers. So that was that was the kind of second thing on my list.
Speaker 2:And the third thing you mentioned work-life balance. I'm a working parent. I've got a nine-year-old son. He was five when I started here, so he was just started school. So I really kind of value flexibility. I want to do this. I need to do school runs every now and then, but I want to, you know, go and see him do his school plays or go to sports day, and it was really important for me to work somewhere that trusts you to manage your own schedule effectively, and actually there's lots of other people here as well that manage their day around childcare, so it's nice not to be the outlier there yeah, and I find that some companies say they're flexible and work-life balance and things like I need to go to sports day, um.
Speaker 1:But when actually it comes around, that's not always the case, or you feel like somebody's going to say something because you were missing, or I mean it trust is earned. But you know, companies do tend to say we're very flexible and actually it's. It's not there in the culture when you actually try and you know, go and do that yourself.
Speaker 2:But it works both ways as well, because if you work for a company that is very flexible and lets you, you know, take an hour in the middle of the day to go to sports day, if there's then, um, an outage at weekend, you're more likely to be willing to jump on and help deal with that, whereas if you had a very rigid um employee that said, no, you work nine till five and that's it.
Speaker 1:Something happens out of hours, you go well not my problem, yeah, that you do find yourself working harder or just OK with realize that when they went into tech. That's the kind of thing, that's the day-to-day, where you get to see the impact that your work is actually having on customers and they it's almost like you wish you'd known that before you got into tech, like what that feeling would be like, because you probably would have thought I'm gonna go into that sooner than you know. Previous things you've done in the past but not everybody realizes. You get to see that really, really fast and that must be very satisfying and rewarding when you do see, um, your work actually being used on on a really high traffic website oh, definitely nobody wants to feel like they've spent hours working on something that then just gets thrown away or or not used.
Speaker 1:So exactly, exactly. Um so leading the back-end implementation of vitals reward scheme, that was a really significant accomplishment of yours. Uh, can you walk us through the process and challenges of bringing that project to life?
Speaker 2:Yeah, so first few years I was at Viator I worked on their payment system and that was kind of within quite a large established code base and I found that although I like working on back-end systems, it doesn't always come with like the recognition of rolling out new, shiny, customer facing features. So this was kind of the reward scheme was kind of my first chance of iRT to work on something a bit more prominent that needed to be designed from scratch rather than part of something existing. So it's a loyalty scheme, so it allows customers to earn rewards, like when they make bookings, and we hold those in a virtual wallet and they can then spend those when they make further bookings. So we started with like an experimentation phase where we tried to put something together quite quickly just to gather data about how well the scheme would be received. So one thing about working in the travel industry we have peaks of traffic in the summer industry. We have peaks of traffic in the summer and we have peaks of traffic kind of on public holidays. So we always need to take um season into account when we're prioritizing work and this time it was kind of really important to get something together fairly quickly so we did an initial rollout um, just to a subset of travelers, and that was that was successful. It kind of proved the concept and I said, right, we'll move forward with this now. So then we set about moving kind of to a more scalable architecture, more customers and addressing limitations with the prototype. So multi-currency support, for example.
Speaker 2:We only did US in the first place, but one of the challenges was juggling this need to ship fast with ensuring that we weren't kind of cutting too many corners like technically, and I think one of the benefits of staying at the same company for more than a couple of years is that you actually get to see how those decisions panned out. I'm working on kind of a tangential project at the moment, so I'm kind of seeing now what technical debt was added and the system I designed was like we designed was mostly pretty good, like it's still holding up, but there is definitely some technical debt that I'm now having to deal with I kind of regret introducing. So you don't get that if you move on every couple of years. It's nice. Another tricky part was considering edge cases around kind of amendments, refunds, cancellations, like we had to really make sure that nobody could game the system and earn rewards kind of fortunately it's crazy with Keita that nobody could game the system and earn rewards, kind of fortunately.
Speaker 1:Yeah, that must be so interesting to work on as a team, though. Even to brainstorm that and the kind of things that you're going to need to be mindful of and build that into that system. That must be just so interesting to think about those things for the customer, to make sure that it's obviously their best experience, but also that it works in your favor as well.
Speaker 2:Yeah, I mean just scenarios like okay, the customer made a booking and we gave them rewards, but then they went and there was a problem with transport, so they were given a refund. Like do they get to keep their reward, do they not? It's uh, lots to think about. That maybe isn't clear when you first set the project out yes, yeah, amazing.
Speaker 1:I love that, yes, and the fact that, when you stay at companies as well, um, you get to see the the life of that project and how things change, and then, as you said, revisiting um previous work um, I was at my, the first company I worked for at the university.
Speaker 2:I was there for nine years. Um, I was at the next company for I think four or five and I've been at Vital for four years now. So I I like to stay in one place but I like to do different roles within the same company. I say the nine years I spent at my first company I did about four different jobs.
Speaker 1:Yes, yeah, good companies know how to retain their staff and so you could move around instead of thinking, well, I have one role and it's a bit rubbish, so I decided to leave. But when you start moving around and doing other things or, like yourself, just getting a promotion, then you know that you're you're in the right place. Um, working on a live platform with millions of users, that must be both exciting but also really challenging. Um, what are some key lessons that you've learned from that experience?
Speaker 2:yeah. So it can be a bit scary sometimes. I so my my team now we look after the kind of core bookings database and apis. So if anything were to go wrong with that system we wouldn't be able to take new orders across all of ita but also its partners, like through trip advisor etc. And that can add up to a lot of money like very quickly.
Speaker 2:So we've have put a lot of effort into kind of testing frameworks, uh into our ciacd pipelines and our monitoring, so that if there is an issue we kind of spot it quickly and we can roll it back really quickly.
Speaker 2:So we also make kind of extensive use of feature flags and partial rollouts so that we can test changes against kind of just a small number of customers and only widen the feature when we're really sure that it's going to work.
Speaker 2:So I've definitely learned a lot more about kind of monitoring and alerting and the importance of real-time data to kind of help you identify any issues but also not doing too much, because if you go overboard on the alerting then you get alert fatigue, alerts are going off all the time and you just start ignoring them. So getting that balance right is kind of really tricky. Um, I think the other challenge that we've had recently is scale scalability, like scaling our existing service, because the core code I look after it was written over 10 years ago and it is fine like it works well, but the level of traffic vital gets today is so much more than it was 10 years ago. So it's quite a fun problem to work out how to incrementally improve the system in place without breaking anything in the meantime yes, yeah, and being at a company that is growing so fast, um is exciting as well, and it must be.
Speaker 1:I've been at some companies where you feel like you don't actually achieve much throughout the year and then when you get to the end of the year, it's quite soul-destroying to look back and think well, you know, we went for a year, but what did I actually achieve in my day-to-day and what did we even achieve as a team and as a company? Whereas when you're a really good company that is growing and moving really fast, you look back and you go oh my gosh, I can't believe that we achieved all of that. And you're so excited about the next year that that again helps to retain you because you don't want to be moving around all the time as well that you get to a point in your career where the thought of keep moving is just hell you're like I just don't want to do it.
Speaker 1:I don't want to move jobs again. So landing at that company where you have those opportunities and the year just speeds by, that's just so lucky when that happens, isn't it?
Speaker 2:yeah, and I think it's good to reflect um on what you have achieved quite regularly as well. I've definitely in the past got to the end of year reviews and sat down to write myself review and go what have I done all year? So now I do try and I'm not very good at it, but I do try and you know every couple of months go right if I was writing my review now what have I done and keep a running log of that. Otherwise, my end of year review is everything I've done in the last week, nothing else.
Speaker 1:I think, and you do forget. I had one community member tell me recently about she keeps a brag book. So every time she does something, yes, she writes it down because it's so easy to forget. And she said I just write a little brag about me and then I just sort of flip back and don't remember all the things that I've done. If I need that little boost or I've had that bad day, or sometimes projects don't go to plan. She said, sometimes I just look back and I think you know what I did achieve a lot. And when asked as well, um, when you are ready for your next role, if you're moving on, or if you're, you know, asked about, uh, an end of year review, it's all there because you've written it all down. Um, which was such a good idea, a brag book.
Speaker 2:I have a brag book, but sometimes if someone says something nice about me on slack, I'll take a little screenshot and send it to my partner yes, I love that.
Speaker 1:Yes, just a little, that made my day. Somebody said that, um, with your expertise in java, nodejs and uh typescript, as well as financial reporting and e-commerce, what emerging technologies or trends are you excited about in the software engineering field?
Speaker 2:So I think developer productivity tooling has come on so much since I first learned to code. So back then GitHub didn't exist. Ides were kind of in their early days but I didn't really know about them and I was coding directly into Notepad and compiling it on the command line. So debugging and refactoring was kind of a lot more manual. And today you've got kind of this entire suite of tools that help us code and test and deploy faster. And then you've got kind of debugging tools, profiling tools that make it easier to kind of track down issues in um. You know complex distributed systems like we work on here.
Speaker 2:So you know some people worry that ai is going to replace engineers, but I don't think it will. I'm not too worried about that, but I think the ai tooling will um reshape software engineering. My manager actually demonstrated to us a couple of days ago how we're kind of starting a new kind of code assistance within our internal code bases now and he'd fed it just a few lines of investigation notes from a bug ticket and said this is what we think. Can you find the problem? And it's a big code base. And it found the line and said I think you need to change this here, and I think you know that is going to make us so much more efficient, though I do love tracking down a good bug, so I hope it doesn't run away.
Speaker 1:Could you give me a clue, could you point in the right direction?
Speaker 2:and then, as long as you still get to find it, my hope is that it will have kind of reduced the more routine coding task but leave us more room to kind of focus on the interesting problems. Yeah, and then I'm really excited about improvements to observability. Things like anomaly detection are like really useful in our space, and the tooling around security is so good now as well. I mean, we process a lot of quite sensitive data from our customers, so security is really really important here, and you know, we've got new tooling coming in that's helping us catch potential security flaws in our code. That's helping us scan for vulnerabilities and fix them. So, yeah, I don't think ai is going to have me out of a job just yet. Yeah, I'm really hoping. I'm really excited to kind of see, will it? How can it make me work faster?
Speaker 1:yeah, and just free up that time for you to try other things and things that you just wouldn't have the time to do previously. Um, I think that, even in my role and, and how we use AI for simple things now, and I think, god, how did we find the time previously to do everything? It's just made us so much more efficient. But, you're right, it does still need that person. I don't think people are going to be out of a job. It just still needs that person there to check on things, but it definitely will speed things up and free us up to do other things as well. Um, I'm going to quickly, uh, throw this out to you and put you on the spot, but we always ask it to our ladies on the podcast. Um, if, uh, you were talking to your younger self, is there something that you wish somebody had told you before you went into tech? Anything, any advice that you wish that somebody had told you that you would tell our community members?
Speaker 2:oh my gosh, I think I think the um, the tech landscape is very different now that it was than it was 20 years ago, and I think you know, starting out in tech, it's much harder to get, to get a role now. Yeah, I mean, I think, although I was always going to end up in tech I think you know I did the computer science degree and everything I kind of fell into the particular job I fell into because I wanted to stay in Oxford and and they were the first people that I came across and, um, but yeah, I was there. I was there for a long time and I would say, just say yes to things. Yeah, um, you know, they said, hey, do you fancy going to Sydney for three months? I was like, yeah, why not? Um, I couldn't do that. Now, now that I've got a family, you know that that sort of thing would be very much harder, but on a small scale. You know, don't be afraid to try new things and get outside your comfort zone a little bit yeah, I love that.
Speaker 1:Just say yes to things. You're absolutely right. When you have the opportunity, when you're younger and you, you do have the freedom to do it. You're absolutely right. Just don't overthink it and just say, yes, I'm going to do it, because you will get to a point in your career stage and life where you think actually I, I can't do that anymore. I've got commitments now and I'm so pleased you said yes when I was younger.
Speaker 2:But also, even if you try something out and it's not for you, you've probably learned something. Like I said, I spent some time as a product manager and ultimately I missed coding because I wanted to stay much more deeply technical than I was, but I find out a lot of the skills I picked up from product management around um, you know how to how to run a project and require, um, gather requirements, and you know a lot of that is still very relevant to what I do now.
Speaker 1:Yeah, and just kind of helped you narrow down where you'd actually like to go next and I agree, just trying something to sometimes, uh, figure out what you want to do and what you're good at and also you don't have to be good at it at the start, like you've got 40 years to get good at something right.
Speaker 2:Yeah, why do you do you need to do at 21 the thing that you're good at when you're 21, or can you spend the next 40 years learning to be good at something you enjoy?
Speaker 1:yes, I love that. I love that way of looking at that. You've got 40 years to figure it out, so don't don't get too hung up on it, and I actually one of one of the best people I've worked with, um switched careers in his 40s he was.
Speaker 2:He was um an accountant and spent 20 years in finance and went. You know what I'm gonna? I'm gonna retrain and he did a master's in computing, came and worked for us as an engineer and he was great, so you're not too old to switch.
Speaker 1:Yes, we have a lot of career switches in our community and they ask exactly the same thing Is it too late? Am I too old? And actually you take all of those skills? He must have taken all of those previous work skills, with him retrained and then landed himself at a company that's looking for somebody who, you know, is that type of mindset, who is willing to learn and try new things and kind of like those. Some people like sponges, they just soak up new information and employers want those. You don't have to have 20 years technical background, but some companies know how to grab hold of people like that.
Speaker 2:I suppose that's advice for companies as well. If you're recruiting, don't get too hung up on traditional backgrounds, like I've worked with career switches before. People that were self-taught don't have computer science degree and you know they're fantastic. So companies risk missing out on some really good talent if they narrow their focus too much.
Speaker 1:Exactly that. I couldn't agree more. We have loads of those in our community and I couldn't agree more with what you just said, emily. We're already out of time, it's absolutely flown by. So thank you so much for coming on and chatting to us about what you do at Viator and your journey so far, so it's been an absolute pleasure oh, it's been fun, thank you thank you and to everybody listening, as always, thank you so much for joining us and we hope to see you again next time.
