Did This Mid Level Developer NAIL Their Resume? Let's Review It!

Hi, and welcome to the réé review series where I review your rsumés that you've submitted. My name is Nick Cosantino and I'm a principal software engineering manager at Microsoft. In these videos, what I'll be doing is reviewing the résumés, trying to give constructive criticism, calling out things that I think are done really well, and other opportunities for improvement. Now, I do want to mention before I dive into any ré reviews that my goal is to help the person that submitted this. But that means from my perspective that I need to be able to try and offer constructive criticism. So, my intention is not to put anyone down at any point. I don't want to try and make it seem like I'm making fun of anyone because I don't think that that's helpful and I think that there's always room for improvement. So, my goal with this is to make sure that we can highlight the good stuff. We can talk about maybe where there's some confusion and of course look for some improvements. If you're interested in having your resume reviewed, please submit it to résuméser.ca. Thanks, and let's jump over to this resume. All right, this resume comes from an individual with four years of experience and they are searching for a new job. I just want to mention that my camera is obscuring the resume, so you'll often see me glancing over to the side to try and read things that are otherwise behind the camera. But let's start by going over things that I think are done well. So the top we do have education, which is great. So um I wanted to mention that, you know, some people think about this a lot where it's like, hey, do I need college? Do I need university? Is a boot camp enough? I think whatever path you're going on, making sure that it's called out and what that is is great. In this case, this person has gone for a bachelor of science and computer science and electrical engineering. Very similar to what I did. I went for computer engineering. So, it's pretty cool. They have their work experience called out. I'm going to be going through the structure of this. Then, we'll dive into some more details. The work experience is good uh in terms of how how it's laid out at the top because that's often where I want to spend most of my time to try and gather an understanding of what someone has spent time on like professionally. In this person's case, because they have four years of experience, I would expect the work experience part to be sort of beefier, right? But if you're a more junior engineer, say you haven't got a job yet, then I would expect the work experience part to probably be pretty light. And then I would hope that your project section is something that you could spend some more time on. In this person's case, they also have a project section which I think is great. Um, and then below that, technical skills. Uh, I wanted to mention that I personally like having technical skills listed out. I think that it's good to ensure that you have keywords and stuff, not in a way that is overwhelming the entire resume. So, if I go to read this and every sentence is just like, you know, keyword vomit, then I'm like, I don't even know what this person's saying. It just looks like keyword or SEO optimization where you're just like keyword stuffing everything. Humans don't read it, but maybe it's good for a bot. I don't know. In this case, I think it's great that it's called out at the bottom. And when we go into each of these sections, we will see that they try to mention periodically where they're using some type of technology. The reason that I think that this is good is when we're considering how résumés are going to be filtered and reviewed. We may have situations where there's automation, right? So, I should also have this disclaimer. I feel like I always need to do it. I'm not necessarily saying that this is a good or bad thing, but I think the reality is that there are many places that will have some level of automation. And if that is the case, then being able to have some keywords can help. At some level, there might be some automation somewhere looking for particular keywords. You don't got them. they move on. The same thing could be said about different recruiters or hiring managers. Maybe more often with recruiters if they're not as technical and they're faced with many resumes that they have to go through, an optimization that they might be looking for is, "Hey, I was told I should look for these types of technologies, these keywords, and they're focused on doing that as a first pass." If they don't see those things, and they have a thousand other resumes to go through, odds are they're probably going to move pretty quick. So, I do think that it's helpful to have. I don't think that it's a deal breakaker if you don't. I just think that it's an opportunity for increased surface area of success. And then the final thing at the bottom, having some certifications. I'm not personally huge on certifications. Like that wouldn't be a deal breaker for me, but I think it's nice to have. If you have them, list them. But I wouldn't try to tailor your entire resume in terms of just saying like, hey, like I have 50 certifications because that to me doesn't tell me a whole lot about what you're going to be doing on the job. just tells me that you spend time doing those things and I think that that could be a nice addition. Let's go back up to the top and start walking through some work experience in the projects. Again, we're going to be focused on in my opinion the things that are done well here. We will come back and go look at things that I think could be improved. But the first part I think um is a really good example. Like I really love how this one's framed and it's because there's some quantitative pieces and I can understand the impact. One sort of theme you'll notice is when I talk about résumés and my perspective is that I try to frame it in a way that's uh I think it might seem a little bit general but I think that might be the point right so if you are submitting a resume to a company and that company doesn't know anything about you the reality is that you might understand the things that you wrote about very well but if someone on the other end of that that's going through your resume does not understand you know the domain that you were working in and that could be the technology or sort of just the product space. If they don't understand those things, you don't want to put a mental burden on them to try and figure it out. You have to put yourself in this position where you're assuming people don't know anything about you and that can be really challenging to write. But I think this person did a great job with their first call out here. So they say contributed to the development and improvement of an automated patient intake system. So again, at a high level, I could understand what that's going to be. So, you know, it's not like super technical jargon or anything like that, but then they say increased patient satisfaction scores by 15%. Again, like I don't have to know extreme amount of detail about that, but satisfaction score is going up 15%. They've obviously improved something from a a user perspective, so that's great. Reduce Hospital Network's manual data entry by 70%. Again, I can understand the impact of that without having to know all of the nitty-gritty details. I think this is an awesome way to call it out. And then save thousands of billable hours annually. So again, some financial aspect to that. This single sentence is loaded with impact. I absolutely love this. I realize that can be very hard to do, especially when you're trying to talk about the impact and make it in a way that's generic enough for other people to understand, not like super technical jargon and then improve something by like 13.21% in this specific use case. the person on the other end of that might be like dude I just don't know what that means but it sounds cool right in this case it seems very obvious to me that there was a lot of impact in this particular space I think a great call out here as well if we go to the third bullet point collaborated with crossf functional functional teams to design efficient restful APIs streamline backend processes and make database optimizations one thing I like about this and this is good to call out um it's trickier to do if you're more junior but if you've had some work experience being able to talk about some level of collaboration and what that looks like I think can be really valuable a lot of the time and I can understand why people do this there's a lot of focus on technical right but making sure that you can address like some type of leadership things collaboration opportunities things like that these are realworld experiences I think that that's helpful to include some amount of it if you are more junior like I said this person has four years of experience at least which is great if you're more junior and you're like hey I don't really have any examples that are like you know in the workplace collaborating like well what about school projects what about anything that you volunteered on what about did you go to participate in a hackathon where you built stuff in a team like if you can think about any examples where you worked in a team and collaborated I think it's a good opportunity to highlight that another final point in this top section engage in debugging and optimizing automation processes resulting in an increase in job success rates and significantly reducing the workload on internal operations team by hundreds of billable hours per Again, there's some amount of quantifiable data here and at a high level, I can understand some of that impact. So, again, I think this one is called out pretty well. What I like about this is that I understand where they were working. They had impact. This can be hard to convey, but I think that they did a pretty good job of that. Next up at Charles Schwab, and you might have noticed I didn't blank this one out just because it's a larger company and I figured I don't need to do that. uh sometimes because people are interested in seeing like hey look if people have big tech companies or larger organizations on their resume does that really make a huge difference? I don't think personally for me it's not a huge deal but I have made videos on this before. If you've watched my code commute YouTube channel this has come up where people are curious like hey if I have Microsoft Facebook or Charles Schwab if I have some big company is that going to make a huge difference? I think that for some people there is this bias. So if you have it, great, include it. If you don't have it, my personal opinion is that seeing Charles Schwab versus some other company, I try my best to remove that bias because I don't think that there is something inherently magically better of Charles Schwab versus some other company that I haven't necessarily heard of. So I try my best to remove that bias, but I don't think that that's something that is uh easy to do for everyone. I'm certainly not perfect either, but long story short there, if you have it, include it. If you don't, I don't think that that's a dealbreaker. I wouldn't be panicking if you haven't worked at a huge company or something. So, that's my point. In their first point where they say solo architected and developed an application used for gathering, you know, blah blah. I think what's interesting about this part is that in the top section, they mentioned collaborating in a crossf functional team. And in this part, they're saying they solo architected something. What's interesting is that we have a bit of a dichotomy here and I think that this can be used in a positive way. The reason I'm mentioning this specifically is when we talk about collaboration and then we get into some of the details. Sometimes what can happen depending on how people write their resume is that it can make it tricky for the reader to understand like well what part did you do? Because if you say I collaborated and then you follow up with the things that were done, do you mean that you did those things or are you saying like I was on a team and those things happened? Because I'm not hiring the team, I'm hiring you and I want to understand what you did. I think it's good to call out collaboration and in this case they're explicitly saying like this is something that I did like I had responsibility over. Something to be careful about too is when you're saying like solo architected and talking about what you did, you don't want to make it sound like you specifically avoided other people. So if you use words like I led, you know, led the architecture on this or something that could imply that you owned the responsibility of it, but you didn't necessarily like, you know, remove other people from trying to help. But I think it's good to call out something like this where it's like, hey, this person really had the ownership of that. Then they say that they ensure the reliability and efficiency of an internal application. So I think you know that's helpful. Uh we'll come back to some of these where I think we could have some improvements. So I'll park that for now and keep going. Next up they say create an end toend puppeteer scripts. So this is where we can start to see a little bit of keywords coming into here, right? Like puppeteer. Great. Okay. Um again if you read this sentence it's not like it was 50 keywords and we're like well what are they actually doing? but they talk about what they're doing and mention the keyword within it. So I think that can be really helpful when it's done tastefully. And then the third point reduced employee performance analysis and optimization time by 60%. Awesome. I think this is really good. We have something quantifiable. This demonstrates some type of impact. Right? So employee performance analysis and optimization time. So this is some process that took time and we have 60%. I will come back to this point again and see if we can improve it a little bit more. But overall, I love seeing quantifiable impact. Next up, they call out an internship. And I think for this one, we're going to revisit this in the area for improvement. So, I'm going to move on to the project section. Now, again, I love seeing extra projects that are on the side of work. I totally understand that not everyone has extra time for extra projects. I get it. But the reason that I always bring this up, especially on code commute, when I'm trying to talk a little bit more sort of organically about how to approach these things, a little bit more outspoken, if you will, I try to remind people that the reality is that other people are making time for projects. So, if you're finding yourself in a situation where you're saying, "Nick, I just I simply do not have time for that." The challenge that I'm putting in front of you is saying, "Look, like it's not really about what's fair to you, and it's hard to hear that, right?" But if other people are like getting the time to do it, making the time to do it, they will have that advantage over you in terms of putting that kind of stuff on a resume. It might feel unfair, but that's sort of the reality of what's happening. I would strongly encourage you if you're saying, "I don't have any time for it." Please try to look at your current priorities and see, are there things that you could give up in the shorter term to be able to spend time building some projects? Again, I'm not trying to minimize the complexity of people's lives. I know some people are in school. They have part-time jobs, maybe two part-time jobs. They could have families. They could have children. I'm not trying to minimize the amount of time and effort that goes into those things. All that I am saying is that there are many people who will say, "I have no time." And they truly haven't sat down and tried to depprioritize other things that they might be able to give up even in the short term. Just wanted to mention that because like I said, other people will be doing this. Here's an individual who has three projects that they've sort of been building on the side. Again, just to briefly mention across all their projects, I love that they've called out the technology that they're playing with. This is something that, you know, even beyond getting your application through. If I were a hiring manager interviewing this person after this resume has come in, what I would love to be able to do is have a conversation with this person about the technology choices that they made and like you know which ones were like a learning experience for you. What did you learn about them? Why did you pick that technology? Because it's not about quizzing them on it and saying like oh well you better have learned you know this most important thing about Postgress like no I would just be like hey like tell me why you picked Postgress like I'm curious was it to go learn about it did you know that it was going to be a better fit in this project and that's why you opted for it. So I just want to see how they're thinking and approaching their learning at a high level for this first project we can see uh roughly what they're doing. So I think an brief understanding of what the project is is super helpful. Then they talk about they're ensuring scalable, efficient and consistent deployments. Um and then they talk about Terraform again. So we see some keyword in there and then infrastructure as code. So this again couple of keywords that they could add in here and that could help if there's some type of automation or if they're applying to a job and a recruiter is looking for things like Terraform, infrastructure as code, right? The next line they have continuous integration, continuous delivery, GitHub actions, right? Builds, testing, deployments. So these things are items that could stand out if someone was scanning through and this individual was applying for specific jobs like that. I might bring this up again as we're going through this resume together, but something I wanted to mention before I forget is that when people put their resume together and they're applying for jobs, something to consider is like the type of job you're applying for. So, I understand that these days a lot of people are sending out a lot of volume of job applications. It's going to be completely overwhelming to try and write a custom resume for every job you're applying to. But something to think about just as an example, this person has a bunch of things where they're talking about puppeteer scripts. They're talking about automation builds, deployments, things like that. If you were applying to something that was maybe a little bit more geared toward DevOps or more geared towards automation, deployment, like that type of work, what you could do is have a flavor of this resume that really tries to call those things out specifically. And if you're applying to other jobs that really don't focus on that as much. So, for example, you're applying to a job that's like an ASP.NET Core web developer or maybe you want to move into front-end development or something else. What you might try to do instead is look across your experiences. So your work experience or your projects and really try to focus on those pieces, right? Maybe you say less about the continuous integration, the Terraform, the deployment pipelines and things like that. Not that they're not valuable, but you might be able to put in other more valuable things instead. So just something to think about as we continue to go through this. This next one reads, "Developed a dynamic, responsive website for a law firm." So, when I read this, again, I have to kind of put this hat on. If I'm a recruiter reading this resume or I'm the hiring manager, I don't know anything about this person. To me, it seems like they had a bit of a a side thing going on where they were able to deliver a website for a company. Now, maybe that's not the case. Maybe they built this for a hypothetical situation, but I think the way that they frame this at least is I would be curious like, hey, that sounds interesting. Seems like you might have some other experience kind of layered in here, like building things for people. When I come back to this later, we can talk about maybe some potential improvements there. And then they talk about integrated SEO best practices and performance optimization. So improving the visibility and then faster reliable uh user experience. So to me this is interesting. Um again depending on what type of job you're applying for the relevance and what you focus on here may change. And then finally we have some React and Express, Node, Firebase and Python. So design and develop the mobile application. Okay. So what you might have noticed across some of their experiences that it's it's nice that we have some breadth here, right? They're talking about like infrastructure pieces with Terraform and build automation and things like that. They're talking about um like front-end stuff or SEO optimization. We're seeing here mobile application, right? We see restful APIs on the next line. We see database work. So truly in my opinion this person is painting a pretty good picture of being able to touch all areas like truly full stack. I like seeing that in terms of how that's expressed in their resume. If you are not going for such a position I mean you would tailor your resume differently but I think from my understanding with this individual that is their goal. They want to be able to call that out and that is the impression I get given the technologies listed and the projects and stuff that they've been working on. Overall, I think there's a lot of great things that they've done in their resume. So, I would like to acknowledge that. I think now we can go back through and try to see if there's areas for improvement. So, uh again, disclaimer as I do that, everything that I will be trying to offer up here is my opinion. You will have different recruiters. You'll have different uh hiring managers or just people with opinions on the internet. I'm simply one person with one set of opinions and perspectives. Here are the things that I would recommend. And of course, this is meant to be helpful. I want this person very much to succeed in their job search. None of this is meant to be a criticism that they should feel bad about. This is purely to help. So, let's go back through and see what we can identify. In the first bullet point, like I said, this is one of my favorite points on the whole resume when they say save thousands of billable hours annually. If they had some metric around that, I know it says thousands of billable hours annually. I personally on the outside of this have no concept of like is thousands of billable hours annually is that actually a lot? It sounds like a lot to me because as an individual I'm like I would love to save thousands of billable hours but the reality is that in the grand scheme of things that might be kind of hard to gauge. So if they have some numbers to slap on that I think that could be extra helpful in conveying the impact of that. But like I said overall that's my like my favorite line in the whole resume. This next line to me doesn't offer a whole lot of value and it's because if I'm reading this I don't really understand the impact that they were having. So what I get when I read this is that they worked on a web application, they made new features and then they talk about you know kind of like who the users are of that or who uh would be using it. But I don't I don't really know like what impact that had. Like the only thing I'm getting is web application features. I think that there's a way to probably enhance this one to talk about like just add a little bit more sort of understanding for the consumer of the resume. Like the way that I frame this and it sounds a little harsh is like why why should I care about this? I think this is a question that you can exercise like on every point that you're putting on your resume is like why should someone care about this? And to me when I read this I don't really have that answer. I don't know why I should care about this. I kind of mentioned like two times already that like I think that okay this part like new web application features okay but what what value was that? I don't really know what technology you use. By the way um in this top part I think this is one that could benefit from a little bit more keywords or technology cuz I think they do such a good job of that like gracefully putting that in in other places where I'm like oh that's what they use. I don't really know up at the top so that could help. Yeah, this line I don't really get an understanding of like why I should care. So, just something to mention. That might just be me, but as one reader of this, that's my feedback there. The collaborated with cross functional uh teams part. Again, I think that this is good, but make database optimizations for example, streamline backend processes. Like, tell me more. Like, I don't understand. Number one, I kind of called this out a little bit earlier when you say collaborated with the other teams and then mention stuff. I don't know what parts you did. So, that's a bit of a a tradeoff, but also these seem kind of generic to me, and I don't know what that means. Like, what kind of success did you have with that? Is does all of that roll up to this part up here? If so, maybe what you could do, cuz I said this is such a strong point to make, like maybe these things have to be kind of spread across. I'm not sure the best way to do that if that is the case. But again, these uh kind of points to me seem a little bit generic, a little bit fluffy, but I do get the idea. Backend work, databases, and crossf functional teams. So, it's not that there's no value here. I think this is good, but I think we can enhance it. So, I would look for like again tell me why I should care about these uh the streamlining backend process and database optimizations. Like what significance was that? The individual that wrote this may have a very clear idea. I am personally not getting exactly why just from reading that. On this last part, uh resulting in increased job success rates and significantly reducing workload on the internal operations team. Increase in job success rates. How was that measured? Like did you have a you know.1% increase and now you're claiming it or like what did that look like? Quantify things wherever you can. I think that's super helpful. But then yeah, this point here, the hundreds of billable hours a month. Um, if we think about the first uh bullet point up here, I had the same kind of comment, right? Seems awesome. I think it's great when I read this, but if could we make it better? Yeah. Like tell me in the grand scheme of things like how much of an impact that has. Just to give you an example, there are things at Microsoft if I said, "Hey, like I saved, you know, $100,000 in a year. I saved a million dollar in a year." It's like, hey, like a million dollars in a year, that's a lot of money. And then if I told you, yeah, but like that's on a budget of like a billion dollars. you'd be like, "Uh, okay." Like, yeah, uh, million dollars is still a lot, but when you put it into perspective, it seems different. So, the reason I'm saying that is that I think it's helpful to understand that kind of thing. If you find, just to call it out, if you find that when you add more context, and this seems like less of an impressive point, it might be something that isn't worth mentioning. And the reason I say that is because number one, it might help you if it's able to get a recruiter to go, hey, like they saved hundreds of billable hours. And then if you get into the conversation and you're talking to someone about this point and then you're like, yeah, but that was actually like not really a lot of money in the grand scheme of things and it's like, well, why did you include that? It's not really that impactful. So different ways to think about these things, but personally, I like having an understanding of like what's going on. It's less cognitive load for me as a resume reader if I just have that in front of me. So that's how I would, you know, suggest some improvements for the top one. When I read this Charles Schwab one, I think, like I mentioned, I like this part here that they have this called out. I like that they call out some solo architected pieces here. I think I mentioned a little bit earlier, I would probably frame this like led the architecture and development. I mean, if you truly like tried to build something and purposefully not include people, that to me is not really a green flag. I don't suspect that's the case here. I think when they're saying solo architected, they mean like they really had the responsibility. So, I would frame it that way because that doesn't rule out collaboration. It's a small detail. That's what I would recommend there. But otherwise, aside from like this part here, I think that I am struggling a little bit to understand what this person actually did at Charles Schwab. I can get a really high level. I can see puppeteer scripts and then I can see some impact. Those are overall like the right ingredients into something like this. But I feel like when I'm reading this, I would just have a lot of questions like, well, how how did you do this? What was going on here? And I I'm just not really getting that sense. whereas up top it felt like I understood that a little bit better. I think some of this is maybe a little bit too vague and maybe that's why my general feedback is like right ingredients at a high level but if I compare that to the one up top uh I have less of an understanding what's going on here. So maybe that's some opportunity. Again the person who wrote this may be very clear about like oh man I killed it at Charles Schwab. I did all these awesome things. This performance alyses an optimization time by 60%. Like that's a huge feat, but like I don't really know from reading this some of the details there and I think that would help me a little bit more. And then finally in the work experience section, electrical engineering intern, great. You had an internship. I have no extra value from reading this. Again, I don't mean that to be to be rude to hurt this person's feelings, but I think there's a huge opportunity here. Like, what did you do? Interned in the substations operations and uh relaying department for New York's utility supplier. I mean, yeah, I get that from from this line. Okay. So, I don't um I just don't know what you did, what you learned, what impact you had. And I think that there's a great opportunity to try and do that because this one bullet point to me is basically the exact same as a line above. I think some opportunity there. Okay. Overall though, you know, I think that this work experience part's done pretty well and I think a couple things to improve. If we go to the projects part, again, love the tech that's called out. I think that maybe something that could be improved on this top one. Again, I think this is done pretty well to be honest, but they say insured scalable, efficient, and consistent deployments. I guess something I would be curious about is like how it's a minor detail. I don't I don't mean for this to be like I don't believe the person. That's a a good clarification, I guess, is like I don't ask that or suggest that to say, well, prove it to me, pal. Like, I don't believe you at all. But like, I think there's an opportunity here. If you say that you ensured scalable, efficient and consistent deployments, how like you said the technology, right? But like how did you actually ensure it? Like I could probably go spin up something in Terraform and it's not going to be scalable and it's not going to be efficient and probably not consistent. So how did you ensure that? And I think that there's an opportunity there for you to call out some extra detail that's like here's here's how I accomplish that and the impact of it. So, I know it's a side project, but the reason I say this is because I'm getting the impression this person, they they believe this, right? Like, you know, this was the right choice. Infrastructure is code. Great. But like, I'm not getting the sense that I understand it to the same level that you might. So, I think there's an opportunity for for more detail here. This part I would uh on the second one, I would I kind of called this out earlier. If there's an opportunity to say like, hey, I built this for a company, like call that out. I think that's cool because maybe something else you could layer into this one if that's truly the case. Is like I don't tell developers that are like aspiring to get into software engineering. I don't say hey like go focus and get customers and you have to sell an app for like you know for money and get millions of users. I don't encourage that because I think it distracts them from learning some fundamental things. But if you are in a position where you have been able to go build things for a client, there's a ton of extra things that you would have had experience doing. So like how did you work with the stakeholders? Like I think being able to call that out specifically could be really cool. Draw more attention to some other skills that you might have. So I think that's great. And then here integrate SEO best practices. Like cool like let's get back to quantifiable things, right? Like can you tell me about how you improve the search engine visibility? like what? You did a great job in the top. Like let's see that down here as well. I know it's a side project, but like even more so for your side projects where you're probably more passionate about these things. They're more interesting. Like you probably know the impact you had really well. Like tell us about it. I'd love to hear it. Right? This is the kind of stuff that if I saw it as a hiring manager in the interview, I would be like, man, like that sounds so cool. like, you know, you got an extra, you know, you got search engine visibility, you got 200% more uh visitors per month. Like, awesome. Like, what was your strategy for that? How did you even come up with that plan? Like, how did you know to go do that? How did you identify the gaps? Like, there's so many interesting questions that could come out of that. And I think that you when you call that kind of stuff out, it helps. And finally, this last one's pretty lightweight. Um, I think it's an interesting project. I see like, you know, web scraping script that sends relevant data to the database. this just as a quick example here. This one seems like kind of like a fluffy statement. So I see web scraping the database part. I see that we have Firebase up here. So like I'm assuming that's the database store. I want to understand a little bit more about why this is important or what you learned from it. So overall this project section I think it's great. I'll say it one more time. I love that they've called out some of the technologies. I think just understanding a little bit more about what they learned, how they built things could be kind of interesting. So overall for this individual, I just want to say I think that they've done a great job on getting this all put together. I think they have all the right ingredients. As I mentioned, there's some areas for improvement. One of the biggest pieces of feedback, I think, is that I really assume that this person knows and understands the value of the work they've done. They understand the impact. They know that they're a good engineer. And that's great. That's a good spot to be in. So the advice is like try to pretend you're someone else. like I was someone else as I was going through this. That's why I tried to give honest feedback. If I can't tell the impact or um you know like why should I care about this, I think that there's opportunity for you to go reframe some of those things and really explain why I should care. Try going through that on your own resume and answering that question for all the bullet points. Why should someone care? So, huge thanks to this person for sending it in. Like I said at the beginning of this video, if you would like your resume reviewed in this same type of fashion, please submit it to résumé[email protected]. I hope you found this helpful and I'll see you next time.