Your Interview Game is Weak: Gamifying Technical Interviews through Role-Playing

Folks, thank you so much for coming to my talk today. Uh, your interview game is week. Gamifying technical interviews through role playing. I've timed this between 38 and 42 minutes, so we'll see where we reach with that. >> Oh, okay. Cool. >> There we go. Cool. I'll stand a little bit closer. Sorry. Um, cool. So, quick agenda. Uh, we're going to talk about who I am. Uh, why am I here? what qualifies me to present. Why you should listen to what I have to say? Uh the metrics on hiring that I found uh based on data from published research as well as my unofficial survey uh that I put together, how I think our industry is failing us

when it comes to interviewing techniques, why gamification works and why I turned to use gamification for this process. Uh we're going to talk about the solution that I created. uh how it began the kit itself that's available right now it's it's live so if you got one of the little stickers if not I I have them in my pocket um so it is available now uh some of the initial feedback that we got as well as additional information uh on the presentation that I'm giving uh and how to contact me so let's jump into it so who am I am I here uh my name is Matt Torbin I'm also known as ghost uh I am

currently the manager of application security at Quinata. Uh I was a former fullstack engineer in a former life. So I did that for a while. Um one of my most proud accomplishments uh is I am a concept creator and co-founder of a conference based out of San Francisco called Day of Security. Um thank you. Um if if you are interested day of security focuses on bringing more opportunities for women into cyber security, I am happy to put you in touch with the fine folks who are running that. I highly recommend that organization. Uh I'm also a former staff volunteer at multiple security cons including packet hacking village at defcon uh day of security as well as besides SF uh public

safety. Um I've authored a couple articles for 2600 on uh physical uh security and privacy techniques. Um I'm a huge fan of VR and XR in the workplace. So this week my uh hackathon team uh back in San Francisco is uh demoing their PC on bringing VR into our workplace. So fingers crossed for them. Uh and of course I'm a proud skateboarding dad. Um you'll notice that there's a big skateboarding theme uh throughout this presentation. It's because the interview kit that we built is based around a startup, a skateboarding startup. Uh so hence the theme. Unfortunately, I guess you can't see it, but in the background, uh, I had a image of Alice in Wonderland popping

an Olly North, which I thought was pretty awesome. Um, so what qualifies me to present? Why should you listen to me? Um, I've been in tech for 26 years and I've had two successful careers. Um, my first career was in development for 18 years. Uh, and it was, uh, the most senior role was a principal software engineer at RSA. I then transitioned into security uh eight years ago and my most senior role is manager of application security at Quinano. Um so I've taken part in countless interview processes. Um some of them I passed and some of them I didn't. I know there are some folks in here I've actually interviewed for. So um yeah, it's it is what it is. Um I've

rewrote and rebuilt multiple interview processes and I've seen what works and what doesn't work. So today this is really about uh what I think works well. So let's take a look at some metrics that I found and this comes from published data. This is as of 2025. 32% of job seekers say that they had a poor candidate experience in the last year. 26% of candidates declined an offer due to poor experience. Now this is down by almost half from the year before. And before we celebrate, think about this though that the job seekers today have lower expectations because of a tougher economic situation. Um, which is the reality. Um, although 91% of candidates say a positive

experience influenced their decision to accept an offer. Now, this isn't rocket science. We all know this, right? A bad experience, people are not going to accept the role. A good experience, people are going to accept the role. But this sets the tone for what I want to present to you today. So, I did my own unofficial survey. Uh, it was anonymous. There was 18 questions at the time that I looked at the data. Uh, there was 35 responses. Um, it was posted on LinkedIn, Discord, and Slack. So, if some of you um did uh submit this res this uh survey, thank you very much. I really appreciate your your support. Um, I did have the data analyzed by

CLUD. Um, and this is what I learned is that the interview to job alignment was just about half. 60% of those uh who filled out this survey cited that arbitrary technical challenges were a top complaint. 70% valued empathy and respect most throughout the entire process. And over 70% of the security engineers themselves were frustrated with these irrelevant challenges. And lastly, over sec 60% wanted their time investment acknowledged, yet there was five plus hours pro uh of process time. So what I've learned from this is that the interview process only about half the time match the actual job. There was arbitrary challenges that had nothing to do with the role. We weren't respecting folks time and uh this was impacting

security engineers quite significantly. and we're looking at five plus hours of interview time, which is not good. That's not the experience that we want to give our candidates. So, how much of this resonated with you? And these are some of the things that I've noticed over the course of my career that the job wreck required one skill, but when you get there for the interview, there was a completely other skill that was tested. Um, the interview process required over eight collective hours. I personally have had interviews that have lasted 11. Um there was a book on interviewing techniques that was needed to pass the interview. Not necessarily on the content of the interview, but just the

techniques themselves. Critical skills not listed in the job wreck were not were ignored. So basically, you might have come from another industry or another role and you had this really great skill that would have been valuable to the team except they didn't interview on it because that wasn't written into the job record. It was blindly based on another org's process as gold standard. Um I'm not naming company names but you know we all have had this experience where company A has taken company B's process and without even really thinking about it said oh it works for them so therefore it's going to work for us. Um and that doesn't typically work out. Uh the tech

challenge was all or nothing approach or worse it was purely academic and unrelated to the role. Um my personal favorite uh is focused on terms and definition memorization. Um, I personally do not have the OAS top 10 ready to read to you right now. Um, I am well aware of it and none of my folks that uh report to me need to recite that on a daily basis. So, not necessarily something that we hire for. So, I found two articles and I found these really interesting and I do have links to these articles. I highly recommend you read them if and you if you haven't already read them. This particular article was written a couple

months ago. A student used AI to beat Amazon's brutal technical interview. He got an offer and then someone ratted to him on his from his university. So the quote that I pulled from this is that Lee is a software at Colombia. He'd graduate in 2026 if he stuck around. He planned to get a degree from college and use it to get a job in big tech. Training for the technical interview killed his passion for the job. Now for the hiring managers in this room, that's the last thing that any of us want. We don't want to be killing the passion for anybody. My response to that is that if your process is so complex that it requires

this kind of fix, the problem is not the candidate. The problem is the interview. This is another article that I absolutely love. It's written by Eric Lou from Capwing. I highly recommend you read this article and it talks about using AI. So Eric writes, "For prospective job candidates, my advice is still the truth will set you free. Even if you do get the job offer in the end after misleading the interviewer, your experience at the company may be short-lived if your work doesn't meet expectations. Now, my feedback uh on this uh I just want to be very clear has nothing to do with capwing or their interview process. I know nothing about it. Um but my thought process is if you

if your process does not allow for the use of tools that are otherwise acceptable in the role, you're creating a hypocritical interview experience and your candidates will lie to you. I will tell you for our interview process we tell people you can use AI. You have to let us know but you can use AI. We don't do that. So we turned to gamification. Uh also I don't own that hat. Uh I own the other one but not that one. Um gamification has existed for years. Humans love games. This whole week is filled with games. It's shown to influence people's behavior. So 90% of employees are more productive at work with gamification. 83% of employees with gamified training

feel more motivated. This is a huge thank you to Adam Showstack's website who uh collected all of these these uh games, but I wanted to put this here so folks can see. Um this is a list of a ton of infosc games. Two of which are my favorite which are on the right, which is Elevation of Privilege and Back Doors and Breaches. Um, just completely aside unrelated to interviewing, um, I highly recommend getting involved in these games with your teams. It is fun, it's enjoyable, and it just nothing but good comes from it. So, how did our solution begin? Um, well, it started with a team building exercise that we were tasked to do to

teach our team how to do threat modeling with elevation of privilege. And I created a company called See It Printed GPT or SIPY GPT. and mostly because sippy gbt is fun to say. Um, so here's the company idea and I wanted to create something ridiculous. So a user will create an object in 3D using VR and then they put it up into a public repository and someone else buys it and then you get paid in crypto and oh yeah, AI is involved in there somewhere. And so it was this humorous company with lots of security vulnerabilities. And we used this idea to teach the team how to do threat modeling. So what were the results of this?

The team learned elevation of privilege through threat modeling. Everybody had fun. And then one of the first embers that we saw that we had a pretty good idea was this is that it was more engaging when you were inspecting a fake company. when you had something that wasn't a former developer piece of work or something the company did or somebody something that somebody has a a personal tie to, it was much easier to have fun and be engaged and poke at this fake company. And so this is how we started thinking about maybe we do this. So if gamification works so well in things like training and team building and collaborative development, then could it work for interviewing?

And this is how it began. Now these are the actual materials that I provided to my team to learn how to do elevation of privilege um for CIP GPT. We have a data flow diagram on the left and we have logic uh flows on the right. Uh if you are getting heart palpitations by looking at that data flow diagram good that was done on purpose. It is terrible. Um but it was good for them to learn how to find vulnerabilities. Um ironically and I put this picture up this because for me this was humorous. Um, you know, I remember back in the day when uh you had uh, you know, James Bond movies and you'd see the movie and

they'd have some like crazy tech out there and you couldn't buy it and then it went to James Bond films and a month later you could buy it. And then the last video that I just saw of the trailer, the car is out before the movie is even out. So, I bring this up because I came up with Sippy GPT as a as a joke. And I think like there was no way you could ever recreate that. Um, until I found a way to recreate that. Uh, so essentially with Tinkercad, Toy Box, Coinbased Discord all wrapped up and immersed, I basically created Sippy GPT. So there you go. Um, so the interview kit that we built,

the first version, and the version that's available today is the second version. So the first version we started with a fake company that had some relevance to our industry and then we created challenges that directly applied to the role and this was this was key. The interviewers had a persona to play with motivations and I'll break that down as we want to do the walkthrough. The interviewees got the interview kit 24 hours in advance and the entire process was fun and engaging for all. I will tell you that we have people in my uh company who are lining up to be part of our interview process because of this. So, some of you might be thinking, well, wait a second,

you're giving the kit to them 24 hours in advance. Aren't they just going to cheat? And the answer is no. Because of the EQ aspect and the randomization that you'll see, it's almost impossible for them to cheat. Um, this is also the reason that we say please use AI because AI will slow you down. So the company that we created was called board to hack B2. Um it's a San Francisco Espace startup. The idea is it's on demand access to information security services uh through skateboarding and longboarding uh because why not? And uh the people that provide that are called skate enable hackers or this is one of the core pieces of the uh rule book that you'll see. It's called

the NPI. And the NPI is the non-playing interviewer. And each NPI uh comes with a backstory. So in this case uh and forgive me, I don't have my glasses on, so I'll try and get this right. Um you were the current head of development efforts at P2. You're initially brought on as one of the original scrappy developers to help get the product's first version off the ground. Now you are leading the cloud platforms team and the software engineering teams, both of which would have some security related tasks as an independent security team has not yet been established. The goal of this is to really breathe life into these characters and to give some the interviewers something to to work with.

They also have a motivation and the motivation is how you play the character. So in this particular character, your one and only goal is to make sure that the executive team is happy. However, this includes not blowing the team's yearly budget out of the water. You're open to any suggestions or remediation efforts that are proposed. However, you're keenly aware that the budget is a concern. Therefore, you're looking for solutions that impact the budget the least and also resolving the concerns of the executive team. Now, what I will tell you before we move on is if you're going to try and employ this, the expectation is not that you rebuild this. It's that you understand what my thought process

was when I built this and employ the thought process. You're you're welcome to kind of rewrite your own uh book version of this, but it will take you way more time than necessary. Um, the other thing that I added is something called alliances, favors, and against. The alliances uh are which other NPIs this NPI tends to align with. So, as an example, during the interview, if the head of development isn't really feeling how the interviewee is answering the questions, but the product manager really is, there's a chance that there could be that alignment that those two could say, you know what, I'm really the product manager is happy, I'm going to be happy as well. Uh the favors and

against are really the things that this particular character is looking for. Things like uh solutions that are easy to on board, can be measured uh and players who are show a willingness to work with others uh and satisfactory. >> So we also built challenges. Now the challenges are directly from the uh the job wreck. So typically we start about four challenges. Uh and we rotate these often. Every time somebody is hired, we go through back through them and say, is this the challenge that we want to do? Did it work the way that we expected? Did the interviewe answer the way we wanted them to answer? Um we determine this based on seniority of the role. There's times

I've done three, there's times I've done four. Uh and approximately about 45 minutes per challenge, right? So if you're doing the math, we're already with two challenges, we're down to 90 minutes of interview time. What we make sure is that this covers areas of the role being hired for. So things like threat modeling, code review, documentation, cross team project negotiation, and offensive security testing. Uh and this is how we actually test because we very much want to make this a realworld experience. The solution that's available today in the git uh in the gitlab will have what's looks like a rulebook and the player guide. The player guide is essentially what you would give uh to

the interviewe. Um it's simply the rule book without a lot of notes in it. And you'll see that. So some of the initial feedback that we got is that the vast majority of our interviewees thoroughly enjoyed this process. The testing process surfaced both uh technical and interpersonal skills which in today's world with the way that we do our meetings and our cross team collaboration is critical. The interviewees who were hired were some of the best I've ever worked with. I've had them on my team now for over a year and uh they are amazing folks. Some of them are actually giving presentations at uh at Defcon. So, we're going to quickly jump into the walking tour. And I love this image. Uh,

this image is exemplifies what I want you all to take away from this, which is this interview kit is like IKEA. Now, I'm assuming everybody is familiar with the concept of IKEA. Uh, when you go to IKEA, we don't look at the the mock rooms and go, I want that room in my house. You know, you go there and you say, okay, that table will look good in my in my bedroom. That painting looks good in my living room. Right? The idea is take the pieces from this kit and make them work for you. So, let's just jump over to that right now. Okay, hopefully that fits on the screen. Um, I have the player guide over here as

well. Now, I'm going to walk through what is in this document. It is a 30-page document. I'm not going to read it all to you right now. I wouldn't have time. Um, but there's some things I do want to point out, and this is all available today. Um, so there's an introduction which I just gave you. Uh, there's a summary that talks about what the company is about. Um, and then the scenario for the company. By the way, those stickers are available on that table over there and I have them on me if you haven't gotten them. Um, the big things is to take some time and build out the organization that you want to

use for your process. The more creativity and character and depth that you put into this, the more it's going to pay off for the people participating. Um, I talk about preparing for the interview. Uh, when you have folks come in to do this interview, this requires people to be comfortable getting into a character. Um, we're not asking anyone to do anything silly or embarrassing, but they need to be comfortable that for 90 minutes they are representing board the hack. They are an employee of that organization. Uh, some terms and definitions, uh, breakdowns of the NPIs. uh we talk about sending out the materials and this these three bullets really wrap up exactly what I was talking about which is when

any of us do threat models or we do code reviews we don't just hop in and do a code review. We're given time to process the material, review the material. It's the same thing for the interview. Um nothing is lost in transparency. Um all you're gaining is a little bit of trust. And the last one to me is the biggest one of the biggest gems of all. Uh we've had interviewees come in and say, "Hey, I took the code and I ran it through this scanner and I ran it through that scanner and I created a fake jurro ticket." And like those are the people that you want to double down on because they took the time to really show you

what they can do. Um the rhythm of play. Uh this is a conversation. Um we've had folks come in and just read to us. That's not how this works. Um you want people to be having a conversation with your team, engaging in those conversations. And you'll see that as we go through the challenges. Um I recommend if this is new to people to have what I call a day zero meeting, not a zero day. Um and that's simply to make sure everybody understands what role they're going to be playing, where the caveats are in the challenges, what they plan on uh bringing to the table. Uh this whole thing I call the campaign and then each one has a chapter. So,

I've included four here uh that we have used in the past and I'm going to walk through some of them now. Now, um also there's my my skate enable hacker. Um so, uh before we jump into that, um you will see all of the NPI descriptions here. And again, um in order to use this effectively, I'm not suggesting that people go recreate this document, right? The idea is this shows you the level of depth that you really want to present uh your team with and what they should consider. One of the things that I am most proud of and one of the the first NPIs that I created was this uh senior cloud platforms engineer and the piece

that I have here is if you find yourself having to prompt the player to ask questions, you'll begin to lose faith in the player and their ability to accomplish the task at hand. As this continues, you become less willing to entertain their suggestions. This is not a trap. This is real life. If I were to go in and do a threat model for a for a development team and tell them, "Okay, this is what you all are going to do. You need to fix this. You need to fix this. You need to fix this." Not only are they going to get pushed back on their heels, they're not going to be interested in working with me because I

didn't take the time to ask them questions about why they chose the things that they chose. Bear with me. I'm doing a lot of talking.

You'll also see um in here that for each one we have the alliances, the favors and against. Um I've written about five of these. Uh so it gives you an idea of how broad you can do this. Um the thing that I want you to take away from with this is for technical interviews you absolutely should be bringing in the other folks in the organization who are interfacing with this person like the QA like the pro the project managers because at the end of the day those are the customers and the stakeholders of your security team and having them as part of the the interview process is going to only elevate uh the entire enrichment of the this the process.

So we're going to jump into the first one here. Uh this is the threat model and I'll show you how I've built it. Uh what we're asking of the candidates is that you find as many vulnerabilities as you can within the time allowed. For each vulnerability that you find uh you need to give it a severity score. So critical high, medium, low. Uh promo propose a remediation uh effort. Uh so the u the spec sorry specificity of the remediation is really going to depend on what information you give them, right? The more detail you give them, the more they can provide a specificity. And then we want folks to stack rank things uh based on what they find. So they might

say, okay, well, I found a cross-ite scripting issue here. That's a high, but you have a SQL injection over here that is a critical. I would fix this one first. The nice thing about having that conversation is because then the interviewe interviewers can kick back and go, well, hold on a second. That SQL injection is going to take a month to fix. This cross-ite scripting is going to take a week. we can do that one first and then it becomes a negotiation and again say keeping with the theme that's real life. Um there is a page in the rule book that talks about the team goals and the team notes uh some some uh example interactions that your team may

you know if they need uh a little bit of inspiration to ask and then of course a section here on like what does success look like and what does failure look like and I have this for each of the challenges. Now, if we go down to the data flow diagram, I'm going to flip over to the player guide and show you what the difference is. Um, so you'll notice very quickly that the rulebook version has some notes in it. And I've done that on purpose for people who if they're doing this for the first time, they don't know where to to ask. So, the interviewers don't know really what to to focus on. This is a great

opportunity. And so one of the classic examples of things that we've done I think you can see it from over there uh or maybe not um but it'll say uh htt you know the connection between the internal employee and the web server will take http https and ssh this is an great opportunity for that uh interviewe to say hey why did you choose to do that what was your thought process in that and maybe one of our folks would say something like well just the health check is http So then if they're paying attention, they might ask, well, have you checked for protocol downgrade? Have you checked the other things? And now you're getting into this really rich

discussion with your folks with this interviewee, which is really surfacing the EQ uh aspects that we want to focus on. Um, when I typically build these things, I build them very vague and I don't provide any type of guidance as to what people should say. Um, our interview team is really good at riffing off each other. Um, I'll give you an example. We had someone come in and they said, "Well, how do you build your infrastructure?" And again, no notes. This is just off the person's head. She said, she said, "Well, we use Terraform." Great. So, everybody switched their head and now they're starting to think about Terraform. They're like, "Okay, we're going to start focusing on that's how we do

this." Um, that kind of randomization AI can't keep up with, right? Could somebody use AI? Sure. But it's going to lag the communication, right? This is very much what everybody should be doing every day and so it's it's a very low stake kind of interview. Um this is one that we've used uh in the past and I happen to like this one a lot. Uh this is called the addition and what you're asking folks to do is suggest some type of solution that's missing. So we're going to focus on uh secrets management for a second. Um, so they're going to propose a secrets management solution, whatever brand they choose. Um, and the company will only

pay for one tool and the team will only roll one tool out. Now, you have three groups of people uh that you have to contend with. You have the loyalists who will literally take whatever your solution is, no matter how terrible it is, and they're 100% aboard. And then you have the skeptics, and what the skeptics will do is they'll pick an opposite tool. So if the uh interviewe says I want to use AWS secrets, they're the skeptics are going to say I know Hashorb Vault. I I'm friends with the developer. I was around when they printed their first t-shirt. I know this on a molecular level. Convince me why I shouldn't use that tool. And the

dissenters are slightly comical, but it's a group of folks who've basically built their own version of whatever it is in Pearl or Python, and they're they're convinced their solution is better than anything else. Um, and the idea is you have to convince these three groups all to agree that this tool that you're promoting is going to be the tool that was going to go forward. And there's a lot of negotiation that goes into this. And I think of this as um one of those finger puzzles, right? You know, if you if you yank on it, it's going to break. But if you take your time and walk through it, this is a very simple simple exercise.

Uh we've also included uh in here a uh is it the code review. Uh so we've created some some pretty terrible code. Um I will tell you it is much more difficult to write bad code on purpose than it is to write good code. Um it took us quite a while to go through this and just find things that weren't just obviously broken but like semantically broken. Um so highly recommend that. Um the the caveat you'll find with this is if you build it right um when folks have used AI and haven't reviewed what AI has given them, they're going to get it wrong and they're not going to have the right answer. The folks who have used AI

to write this then reviewed it generally will get it get it uh spot on. Um the last thing that we've done uh is we have a threat model. I'm sorry, a uh pen test and we pick any one of a open source uh tool that's out there. Uh we we rotate them and we simply do the same thing we do with threat model where we say okay we want you to find as many vulnerabilities as you can propose a suggested remediation criticality and stack rate them. Um you would be surprised with some of these uh how quickly this surfaces the you know the pros from the Joe's. The other thing that I will point out in

here, um I do have a a scoring and wrapping up. Um but the big thing that I think is very important is identifying suitable candidates. What you're looking for is someone who is both technical and EQ. And so you want people who have conference uh conference experience, meetup experience, volunteer positions, you know, people who have social media presence, people who have written publications, people who have professional experience at conferences. when you start to put that filtering mechanism against your pool of candidates, it goes down real fast. Um, and that's not raising the bar. That's simply looking at people who have a broad range of experience. So, jumping back to our presentation here, doing good on time. Okay. So, to recap,

uh, for interviewers, um, post pandemic, many more meetings are virtual. Uh the interviews can and should be about IQ and EQ. Cross team collaboration is critical. This is what we look for. You want to invest in your interview process. If you take the time upfront, it's going to pay off dividends in the end. And I have numbers to prove that at the end. Be creative. really envision who the person is that you want to hire and then literally filter out the rest for the candidates. Technical skills are only half of the solution here. Um demonstrate your soft skills. This is what's going to rise you above. Volunteer at conferences and industry orgs. Develop presentations for

conference talks. Uh get involved with blogs, videos, code repos. Um, this one is a big one. Um, find a mentor. I can recommend lots of them. Just real quick, show of hands. How many people in this room know of a mentor that they can recommend right now? Okay, cool. There are people in this room who can recommend a mentor if you don't have one. Um, please reach out to me or one of the folks who raised your hand. They can definitely offer this. Um, AI is a tool, not the tool. Uh so make sure that you know when you review what gets put out there. Uh vocalize your curiosity. This is a big one. Uh

ask questions during the interview. This is one of those ones I wish uh more interviewees would do. It's as much of an opportunity for you to interview us as it is for us to interview you. One more thing, and this literally happened last week. I was so excited to be able to show this slide to you. Um, we just finalized our hire last week with version two of the kit that we just had. And I have metrics. Okay. So, what did we accomplish? We reduced our hire time by 2/3. Start to finish. This took us two months instead of six months. We reduced our candidate pool by 5x, which means only about 20 candidates or

less went through this process. And this wasn't uh 20 people that got recommended to us. This was finding that pool down to those 20 folks and working our way through it. We hired an amazing candidate who met all of our needs. Uh we received at least a half a dozen compliments uh from candidates specifically about this uh this process. So if you're doing your math, 6 - 1 is five. So at least five folks who still wrote back to us and said, "Hey, I really enjoyed this process. I really it was comfortable. I learned a lot." Um so for us uh the next stop is to roll this out to other teams. There is a git uh gitlab repo. The QR

code works, the sticker works, the URL works or if you want to go to the straight to the gitlab, you can reach it there. Uh these are the links used in the presentation. Uh I just put them on another slide so you all could see it. Uh and of course one more. There we go. Okay, cool. Uh, most important one, this is how you contact me. Um, so, uh, one last thing I'll offer up, uh, it's been there for a while, but I think it's so fun. Uh, if you happen to be a fan of Zor, uh, and you happen to be a fan of the IT crowd and you happen to like JavaScript, cuz who doesn't? Um, I

created a little game on my website. Uh, when you solve the first challenge, it's going to look like this, and you'll see a little terminal that will pop up. Uh there's going to be a command in there called Elfenheart. For those of you who are IT Crowd fans, yes, it is. And I and I worked real darn hard to make sure it was true to the to the episode. So, uh you will have fun with that. Um last but not least, I need to say this. Thank you so much to all these people who helped make this happen. This was not just my effort. This was, you know, Ricky, Kelly, Tibo, Darius Swain, Ian Young,

Idris Olawash, Silus Ow, Peter Shahu, Peter Segmire, Harrison Richardson, Sosan Win. Uh, thank you all to these people um for helping make this this was months in the works. Uh, so with that, thank you. I appreciate your time.