30 plus behavioral interview questions that you guys have asked about for the QA and as that positions with the three experienced QA Engineers automation engineers and even managers who are going to answer those questions so you would know how to answer them the best way possible my name is Sergey kromchenko I've been rocking the curio world for more than nine years and today I'm delivering a promise you guys previously have asked for more mock-up interviews specifically for Behavioral questions because these types of questions are asked during every single interview because regardless if you are manual or an automation engineer a QA engineer or even fewer Dev everyone wants to know how are you going to behave in a team how are you going to be collaborating with other team anyways let's get directly into it but before we do that if you guys are enjoying this video don't forget to hit the big fat thumb up button and the Subscribe button below and also if you want to learn more about our school or you want to talk to me directly feel free to leave a comment below or to follow the link in the description at kodemified.com let's go [Music] hey everyone welcome back [Music] what's going on guys super positive alrighty well we're seeing Alan Antone here those are our superstars from the YouTube you guys have probably seen their videos and you will possibly see the link right here or maybe right there or somewhere there uh to see their previous videos and also we're going to add it to the description of this video anyways um Ella you wanna since it's a March 8th and you're the lady you want to go ahead and introduce yourselves to uh to everyone sure sure um yeah I'm at love um I'm actually leaving La um I took your course surgey uh more than a year ago and um I'm actually working right now as a QA at the company calling go Guardian pretty happy where I'm at pretty happy with QA um yeah so Coolio thank you and Anton well well my name is Anton I think some of you who have been watching this channel already know me but I'm also an ex student of Surgis and I've been working as a QA as well so I think you can probably watch some other videos you'll get you know the same Spiel uh but yeah that's pretty much it about me awesome awesome all right well since we've already met everyone let's probably get started this is going to be a behavioral questions interview for the not necessarily manual but also for key automation position because you'll always get the behavioral questions will not go into technicals but I guess it will probably be mostly for manual since there will be no related to automation but when you go for automation interview questions you will possibly get these as well so let's get started um I don't think it's possible you would most definitely get them because um even from my experience of going through the interviews you go through different rounds and you know why one might be technical the next one might be you know about uh behavior on one excellent might be about product right so you need to have that kind of rounded knowledge about it so that's actually most definitely get it yeah yeah it's actually so true even me going for uh for a senior manager engineering manager positions I would also get a lot of those actually most of those so let's get started first one uh who wants to ask it because you guys got a list of questions as well right yes sir you do all right well you want to do the deed and ask and I'd like to answer uh well I can I can probably ask all of them let's get started cool uh can you describe a time when you had to work with a difficult team member and how did you handle it you can volunteer Ella let's go I just recently actually had an issue with one of our deaf and basically it was just um delay with some of the work that we were promised for QA and I was not really happy with everything how it's gonna when you know how it was handled so um I think the right way to handle those is first of all is be polite and friendly and definitely if you have an issue with a specific person um don't be like passive aggressive towards them um but what I did actually reach out to my manager and just let them know like hey I have the situation I'm not really sure like how to properly handle it but um you know can you maybe give me an advice or maybe talk to him but kind of like we need to specify the process and make sure you know we're hitting our deadlines so but again I was like I don't want to get anybody in trouble or anything um I just want to make sure that the issue will be handled definitely agree with that I got nothing to add anthem yeah no that's definitely the right way to go about it um you know one of the main things is not to take work stuff personally right and handling in that professional manner and uh really you know if you see that it's um not whatever they're doing might be harming the productivity of your team or even the company you you know approach it in a particular way where you mentioned certain things that are solely professional related and leave all the personal things aside from it and just yeah mention those and kind of approach it from that way and actually I can actually answer this question in a really cool way because once upon a time I had an issue with my manager and I had to deal with it very unusual situation but if possible it could possibly happen to everyone so I'm trying to talk to the person uh the person had something uh something inside of the job so we couldn't resolve an issue so I had to talk to his manager multiple times until the issue was finally resolved and this is kind of an unusual situation I would say because I wouldn't I wouldn't see how someone would have a problem with a manager but it happened you have to follow the chain of command I guess you you know if it's problem with your manager you go to his manager I mean if you have for example a QA lead in your team you probably prefer is going to go to Q8 you know QA team if you're having issues with the co-worker so I think you definitely need to go one level higher but I also want to mention that I think a lot of people was our mentality from people from different countries um that we feel bad when we go through our manager to tell that we're having issues with someone yeah which is totally fine that's okay like you're not doing anything bad just stay professional and stay polite you know so just want to mention it yep yeah for sure and try try to try to figure it out on your own try to talk to the person the way we did the way I did multiple times but if you're hitting the wall and there is no way out well if you're gonna go one level up and say I'll mention you've got to go up Coolio all right let's get to the second one how do you approach testing requirements that are incomplete or unclear this is actually a really good interview question uh for the P for the newbies I would say for the junior to mid level but actually but for student level as well yeah I mean I can go ahead and actually answer that one and it's funny because Sharon um was working today and she was like she turned around and she says hey um dick if it's safe to assume if the bug is on uh happening on like Chrome is it safe to assume that it's on like other browsers as well and I was like you never assume as an engineer right so that's kind of the most important thing to take away from it so whenever you have some sort of like difficulty understanding the requirements the worst thing you can do is you know say oh yeah I thought that's you know this is it right and then down the road you ship some something to the production and then you know they discovered the bug in production and then you're like oh yeah but I thought this was it right so you don't want to be that kind of a foolish person to because you will be held accountable as a QA right so um always go and clarify whether it's the project manager whether it's the you know your QA lead whoever that person of the contact you know who has those requirements uh or who can double check on those things for you always go to them and kind of clarify those things as well so that way there's not going to be any issues and you know you're kind of getting that weight off of your shoulder of assumptions and things like that have that clear list of one two three these are the mock-ups these are functional requirements and kind of Base your testing off of that yeah yeah that's for sure I'm completely on the same page and I feel like this is a good interview question for our students who are learning who are learning how to become a QA engineer because a lot of times they get into a situation where they have requirements but they are not they don't understand what's happening they're like am I dumb or just not clear and usually they think that they're dumb because they're students they're like well maybe that's the right way and I just cannot understand it maybe QA is not my thing but no this is the thing you got to ask you've got to find out what's the truth and never assume don't be afraid to ask questions that's totally normal if you feel that you don't understand something ask that's fine please yeah that's that's really good advice alrighty well let's get to the third one and can you tell me about a time when you identified a problem with a product that your team did not notice all the time so the question was can you tell me about a time when your answer is all the time that makes sense that's very acceptable I mean you know it could be from the QA side as well as it can be from the dev side as well like um I just recently had an issue we had an open ticket where the original issue was that we were not able to put an email so it was supposed to be like a five minute testing you know just to make sure I can put an email well I start actually putting in email and I also was like hey can I actually put any special characters there like other than the AD Sign and ended up yes you can put whatever with her at that specific field for the email and I was like guys I think we forgot to check that before um and yeah now it's a huge project for the devs I don't know why what's going on in the back end but yeah supposed to be five minute testing now it's back to the development so that happens yeah that's it's totally you know nobody's perfect right if um we were computers maybe then it would be a little bit more perfect but um you know we're humans and we're prone to errors and you know so at any point in time I think if you do find it um you can you know easily address it and just address it from the way that's not offensive I should say and it's more so like hey I you know I was just looking at this and you know I I happen to find this one did you already maybe file this bug or something like that right where you ask that question and but that question also lets them know about the issue and they might say hey oh yeah I totally forgot thanks for catching that right versus if you're really direct person you say hey you forgot this right and that sounds really offensive and everybody's gonna be like why are you accusing me of this so having that proper approach to you know whenever you find some sort of issue I think that's also really important to consider yep yep that makes a lot of sense alrighty well how do you guys prioritize testing tasks when there are no that when they're competing demands so pretty much uh what are you what are you going to test if there are other priorities well personally speaking right um I always have a list of priorities right so if there's other priorities right you know everything is important right they can say you know no bug is not important but certain things are more important than others right so I always like to say Hey you know I always have a list of you know priorities and they are ranked by the level right this is the highest priority this is the second highest priority this is the third priority right so I always worked from that top-down approach I first tackled that you know the thing that's most most critical right to the functionality of the application if it's critical to the timing of like the release or something like that and then I kind of make my um way down so I think that's kind of like the best way to really go about it because then they'll say okay this person doesn't think that everything is important he's actually able to say okay you know this is pushing this is like on fire we need to fix this or you need to test this or something like that and then you just go ahead and you know tackle those things first and then you tackle everything else after that so that's how I go about it typically yeah that's really good answer I was thinking about when we were talking about it I've I just came up with an idea of testing cake not a testing pyramid but testing cake the cake in a shape of pyramid where you take a spoon and you eat it from the top the highest priority you quickly grab it from the top and then you go to the lower priority and lower until you run out of time and you have we have the time the lowest priority cannot necessarily be tested all the time so you simply uh Let It Go and test it when you have a chance or you bring other resources available you would talk to your team and ask hey since I have a really high priority is anyone else available let me talk to your leader manager is anyone available to help me out because this is high priority this ring sound is not a high priority let me turn it off this is higher priority and that is high priority and we gotta get both done so I need it and you know you can always come to your manager and say hey we those are really high priorities can you actually help me out to get a resources or to tell me which one would you like me to skip for today because we have no time for that um I also want to mention that I work with the team that switching priorities like almost every day um it's just the way how our team operates we're the mobile team and we have different operation system plus issues from our customers so for us every day on the stand up like we're talking to our devs and engineering manager and our manager and saying okay today what do you want us to concentrate on because there are some issues that for example you know it's number one priority today because we have to do it today because it's an issue for a customer for a big customer so we have to drop everything off and you know circulane um you know the issue so that's also one of the things that you know making sure that you actually follow up with the team at the same time and making sure that the thing that you think is a priority is still a priority yeah yeah that's a really good point um alrighty let's move on to the next one can you describe a time when you had to make a difficult decision during the testing a difficult decision during the testing I feel like we're making those on a daily basis aren't we I mean they might not be like life or death decisions right but again um you know I I it's hard to it's a really kind of broad question right when you say yeah decision right um but I mean in my opinion I think we do make you know those decisions every day but in the sense that um everything still comes down I think for me to a priority right whenever I'm tasks tasked with like making some sort of decision about testing it's always comes down to me like okay what's important and what's making the company money and what is the critical functionality and those are kind of the things for me um you know that's kind of like the the field that I play in like and kind of decide what is that difficult decision that you know I think I can't think of any other way that I ever approached or making any sort of decision um because at the end of the day for me it all always comes down to like what's the top priority right and um you know I may be testing something simple and then something comes around uh that's more important then I switch my focus right yeah other than that I can't think of anything else that's kind of coming to my head right now um I can think about a decision um I recently had to meet is basically to tell um our Dev team that we're not going to go with a specific feature just because the feature is not fully working um on a specific platform and it should work a lot you know along all platforms and exactly hey I want to make sure that all the customers that are using different platforms all of them have the same experience we can't really say oh okay the ones who are using Windows they're going to have this feature and but the ones we're using like for example iPads are not gonna do that but I have to say from the customer perspective like the hey um as a QA I don't feel like we should go with this you know when we had a um our retro session split planning session where we're talking about it so I think we also need to think from the customer perspective as well if you need to make a decision just to save and stay ground where you're gonna say hey I think the specific approach the dev team want to go to is not going to be a good approach for the for the Customer because I think as a QA we're kind of like are um you know supporting our customers and trying to make the best experience for them yeah customer oriented I actually have a question that came up um during uh interview with PayPal and um they said well imagine you're the only QA and um you know developers are putting out fires somewhere you know the project manager is um on vacation and you find a bug before the release what would you do right and you you have to decide how acrylic critical the bug is and and like basically have the last word on it is this gonna get shipped as is or are we gonna um you know stop the release for this bug and we're just gonna have uh like some other code right and I was sitting there I was like hmm it's a good question and I tried poking and saying hey well so I have really nobody and they're like yeah just imagine you're the only person who has to make this decision I said ultimately again I would assess the risk right if you know this hypothetically scenario right if the application requires you to log in and we're not able to log in there's no way in hell we're shipping it but then if I said if it's some sort of like low priority low severe youth thing where it's just like like colors off a little bit somewhere right and it's not quite matching the mock-up in that way I say yeah that's totally shippable right so so always assess the risk and the functionality and how critical it is to the application and then kind of Base your decision of that but I remember answering that question he's like oh yeah that's that's that's totally valid because again you have that you know High severity high priority you have low priority low severity right yeah you have to be able to kind of navigate that and make that decision accordingly agree all righty let's move on to the next one can you tell me about a time when you had to deal with the conflicting priorities or expectations from a different stakeholders by the way does anyone want to want to explain what are the stakeholders or who are the stakeholders because I'm pretty sure not a lot of people will know that yeah for me stakeholders uh it's typically the customers right over at Fortress our stakeholders are pretty much uh the properties that were on boarding right and they request different features and they tell us to work on different bugs so essentially they are kind of driving our um development and kind of the route which we're going and in different companies they could be stakeholders can just be the people at the top right so it really depends but it's essentially these are the people who are driving the direction of development or fixing things yep yep that's true that's true and on my end in uh about six years ago uh when I worked for one of the cell service companies in the USA easy to guess the stakeholders were managers engineering managers like team managers etc etc directors that level people so once again it depends about those as an under mentioned those are the people who are driving uh pretty much priorities for the team so have you ever had to deal with the conflict in priorities or expectations because in my experience it's kind of an interesting question because I never had one like this but if I would I would bring those two stakeholders together uh give both of them a bottle of beer I'm just kidding and tell them to figure it out because we gotta find out what exactly is more important for us not necessarily between them but between us three of us I would throw my ideas I would talk to them but what do you guys think I think the same thing um I mean we kind of because in my company we actually working with the schools was the school district um so um we did had an issues when for example um we would get a request for a specific feature and then we'll have to decide can we deliver this feature how long it's going to take to deliver this feature how actually how much money it's going to cost to deliver that and would it even be like reasonable because since we're working with different school districts it can be just one request from one school district but would it actually benefit you know others from the other states as well so um I think you gave the right answer but you know um talking and see like is it really worth it or not yeah yeah because that's we're the team we got to figure it out together it's not like one person's responsible other is not our goal is to grow the business and and keep customers happy while we're doing that so we all have a one goal we just gotta figure it out between all of us all righty let me put the check mark on that question and move on to the next one how do you handle a situation where there where there is a difference in opinions between you and a developer or a product owner that sounds like Ella not sure why but that sounds like her I am very yeah I always hold my opinion on things uh but to be honest I'm very lucky because of the company that I work for right now uh we have a very um close relationships with my team with the deafs I don't have any issues which was reaching out to the dev directly um the one that is actually working on a ticket so um but yeah of course we I always have a lot of disagreements sometimes but we are the team so we'll actually we'll schedule a meeting where everyone can actually come and talk about it you know if it's something big if I cannot actually talk if I need to I can actually talk directly to the deaf and describe like what my position why I think it's an issue or you know not an issue or it's a problem or not a problem um but sometimes you have to talk with the whole team to decide together communication that's the key communication and I also want to put that you always need to be friendly hello life and yeah that's very important in the work environment yeah absolutely and I think you know uh having the differences with a developer and um and a project manager are like I think they're totally separate things at least in my opinion um and the way that I have experienced it in my workplace typically differences with like the developers are like you know is this a bug right um is this how we're supposed to test it and then you know uh I never had actual differences with project managers because I actually those are like the people I look up to because they are you know living and breathing that project from like the very beginning uh when it just starts whether it's a feature whether it's some like other big other part of functionality they are the kind of like the man or the woman you know and you able to go to them at least for myself I would always go to project manager for any sort of needs and there was times that I would suggest certain things but never actually have conflict with them you know I feel like Cricket managers are not really typically they're not like your boss they're not your manager so it's for me I never had any sort of conflict with them and with developers yeah you can have sort of differences the way that you should test something or you know different permutations and looking at it it's from the particular angles and things like that but um yeah from from my side of things project manager I would always have some sort of maybe suggestion hey maybe we forgot to consider this test case and I see you wrote out the requirements but maybe you were forgetting this and it would be more like a fluid conversation uh that way instead of having you know some sort of differences yeah exactly interesting enough because in my company it's not like that really we we kind of have I mean in our company our payments our product manager managers usually have a lot of projects on in mind and sometimes it's more that we can really deliver and we do sometimes have to have like big meetings where we need to say hey yeah that's awesome that's an awesome project that's cool but hey we don't have like you know any uh Workforce right now to finish the specific test or a switch to this project or this project actually took longer than we actually anticipated so I mean I guess it depends yeah that's kind of interesting because from my experience it you at least for my professional experience uh and from the last experience I would say particularly we had the project manager who was just assigned to our project so they were involved in that project and that project alone they were not like a you know jack of all trades jumping from feature to feature to functionality functionality and that's why I kind of from my experience to say hey this is the person that I go to because you know they're right out there at the top and they know everything every moving element about this uh project but I guess it also depends like what kind of team structure you have right so every company has different team structures and you know Therefore your answer can also vary in that regard yeah I thought I was going to say that uh it will be great amazing experience for people who have no experience to watch this video because they're like hold on who's who's right Anton or Ella because everyone has a different opinion and everyone has a different story and those are actual stories from life experience that's not something you came up with and in my case uh project managers mostly they were the people who would come and just double check hey is the project still moving hey how can we move it forward how can we push it faster and the product owner would be the person who you would look up to in my case at least lately at Audible and Verizon and some other companies uh the product owner would be the person who owns the product who owns the feature who actually tells developer what needs to be fixed how needs to be fixed but as Anton and Ella did say that you could always uh you could always give them an advice what you think would be the best but they are the people who are making decisions although you would gather as a team and based on our conversations they make decisions but once again it is my experience and well I never had a different experience alrighty that was quite an interesting question that everyone's going to change and by the way if anyone else who's going to be watching this interview will have a different different experience please mention it in the comment below I want to hear that because I want to hear what are the possible structures and ways of experiencing difficult situations between developers product owners project managers Anton Ella and Sergey awesome moving forward how do you approach a test how do you approach testing products with a large number of features or complex functionality that's funny you have to plan how are you going to do that test planning it's the number one rule yeah no that's I cannot agree more with that because one of the companies that I was working for uh particularly their subscription process contained so many different permutations and permutations essentially meaning there's so many different ways that a customer would be pointed like for example if you say I want to select you know uh there's two options and you also you want to select the first option so on the next page you're going to be presented with different options and then the or where you select on the next page is going to show you the next different options on the other page so there's it's like a web of like you know if you select this one and then it's going to show you this one and another one right so there's different permutations and what helped me the most was having the test cases right so you know test it you know I know uh test first option on this page first option on this page First Option another page right and kind of like trick on down that way but yeah test cases are like the most critical thing because I feel like if I and and I was relatively right new I joined the company I had to start automating you find that I have those test cases in place I would be like okay like I have to sit there and you know sometimes you have to do yourself right come up with those test cases and do the manual testing first and then write out the test cases uh but let's say given the fact that you have the test cases in place refer to those and um you know that's how you're gonna really um understand what is um what are the different permutations of uh whatever you're doing and things like that and that's you know if you have a really complex product right that which was part kind of part of the question if you have a large number of things that are happening um yeah you're what I like to say is you as a human being are not going to be able to remember 100 of the time 100 of test cases right but what we'll remember it is the chest case management system you input it there and you don't have to sit and guess that I test this that I come up with it uh with the automation script for this one for that one right yeah test planning uh that's kind of to the Core let's go test planning yeah and always if it's a large number features and a complex functionality you would discuss it with the team as well um because sometimes even from my experience I remember that sometimes my team would be kind of slow on things and then for a while would be developing um the large amount of features and not releasing them and then automation wouldn't be in place so I would have to talk to other team members to make sure that we can have enough resources to help to support this release so not only me but someone else will be available to help so large as someone said difficult questions cannot have easy answers next one can you describe a time when you had to explain a testing issue or a result to a non-tech non-technical stakeholder honestly I when someone asks you interview a question on the interview and you do not know an answer or you do not have a case in your head I will say I did not because most of my stakeholders they were technical never had such a situation but if I would I would try to explain it in a human understandable examples by using non-technical language and actually chat GPT could help you with that I mean I used to work in I.T support so I used to actually teach like like for example elderly people how to use their computer for example so you have to you know let them know what you need to do right click or left click that's still the question that makes me you know nervous um so yeah I mean you just need to explain what the issue is just not using technical words I guess just simple like how are you describing to a child for example yep yep use examples news associations alrighty it sounds like Anton does not have any as well so I might I didn't want to add anything because it really what you said in the beginning um I think it would make sense although insurance company there are some people who are product managers and they're not necessarily technical people right um you know my company the person came from ex developer and then more transitioned into the business side of things and they became pm and therefore they knew the lingo but some people don't and you know I think there is really no right or wrong answer to this one everybody's experience varies so you could say no I never had that you know everybody was technical or you can say no the person uh you know my PM right and so you will also be right because the you know it happens so yeah yeah also you mentioned the name Sharon couple of times I'm pretty sure not a lot of people know who she is but can you tell us who she is and I'll next time I'll try to bring her for an interview sounds good well uh Sharon is my girlfriend uh she's also a QA so we got a QA family we have a dog he might become a QA eventually so um yeah so sorry maybe like some people might have seen the uh videos but I'm not sure if she was ever actually on like she wasn't a picture yeah she wasn't like on the thumbnail I don't remember but uh but yeah she's my girlfriend perfect yeah uh we're gonna end the video that Anton is talking about right here or right there uh and then yeah Anthony Sharon our first is our first condemnify UA family that had successfully graduated um so they were the first ones hopefully we're gonna shoot a video with Sharon soon and by the way I remember uh some some people who were born in America asking hey why you guys having all Eastern Europeans and people from all over the world but not from the US what's the trick and Sharon isn't American she is well she had her Heritage is from Italy but she's American so we're going to bring her for an interview and then I'm gonna say now guys you see an American on this channel well well there's a very fine line there because um she was born in Italy right um but her mom is American right but with Italian Heritage right so she's 100 Italian but depending which way you're looking at it right you can say she's American honestly when I when we met in college I was like Sharon this is the last person I would think would have like an Italian to have a thy name right because you say Sharon it's pretty American but yeah she's Italian to the core even the attitude so all right all right not gonna bring her for any of you then just kidding cool moving forward how do you ensure that your testing is comprehensive and covers all possible scenarios I can actually pick that one because there's something called test mattresses or test Matrix mattresses matches probably probably yeah like a matrix right like a test Matrix that uh which could describe what tasks are covering what functionality uh and actually what functionality is covered I think that one would be the best uh but there are also quite a few things we could add here number one that every company will have a different times for uh for writing test cases in a previous company a couple of come places to go that I worked for we would have bi-weekly release cycles and right after the release we would go through all the tickets for all the changes that were made and we would update or write new test cases in a test case management system but every company would have a different times for it and some companies you would be a lot behind in other companies we wouldn't even have a test cases we would write automation right after release and we would have daily releases so we released two tickets and by the morning I I gotta automate between two to eight test cases and have them uh have a PR created have emerge ASAP so every company will have a different uh kind of mindset for that but let me know what you guys have um yeah I mean it's same in in my team we actually didn't have test cases and any test cases for pretty long time because we had a product that needs to be tested right now and right here so we were actually you know just collaborating all together and see like okay let's make sure we cover every possible scenario um and also what we did is ask a team member from a different team different QA team and ask them to also look at the product and see if there is something that for example we missed there's a new pair of eyes can actually see more sometimes if it comes to manual testing for example oh yeah yeah that makes a lot of sense already moving forward next one can you give me an example of a time when you had to adapt your testing approach due to the change in requirements or a timeline that sounds like Ella can you repeat the question one more time sure can you give an example of a time when you had to adapt your testing approach due to change in the requirements or timeline um that's an interesting question as far as a testing approach um yeah do you do these requirements or timeline and actually if you want to take time to think about it I can't answer it because I got something go ahead sure once upon a time in 2017 approximately I've been working for the cell service company in the US and then we wanted to we wanted to release a big a big big feature in two months so I had enough time to write automation I was like let me I don't mean automate the hell out of it and then we're going to successfully release it with no issues and a quick automation test only but the things have changed and then we decided to release it in three weeks instead so I had no time for automation so pretty much test my Approach did change because I I completely went from automation into manual testing only and I had to ask for an extra resources to help me out to have success to have a test case coverage for it so because that was quite a critical uh quite a critical functional features and functionality um I had a vice versa situation where we actually started asking to give us more time to doing automation because we decided that yeah hey the manual the manual testing is actually taking a lot um and we're really as again since we have different platforms it takes like even more time so we actually started I should ask our team can you please give us time to do some automation can we please start automating our test cases please um which is not always happening because of the amount of priorities and work that we have um but we actually decided that we're going to take one day a week and only do automation nothing else like we don't exist for anything else we all need this for automation that's the way yeah no I don't really have anything to add I think both of your answers were really solid sounds good moving on can you tell me about the time when you identified a potential security vulnerability during the testing and I remember that I did have one I can probably get started with it uh so during that time I've been testing uh using a user interface field validation something like email for example password fields and then on the side I was doing not only the UI validation of those fields but also an API and I found that there was there was a UI validation for the field but through the API you could send anything you want and you could crash crash the server with that but UI would would have a cool defense it would simply tell you hey you cannot use special characters you cannot do this but through an API you can do all sort of SQL injections and things like that so that was a huge vulnerability which was quickly fixed but UI versus an API that will be an answer to this question from Island yeah I don't have a really many specific examples either um in one of my companies we had we had one's an issue where basically you could just log into the your personal page without even putting a password so yeah it was just the book um yeah thanks God we actually tested right away uh we found it right away um but we found it after release so oh boy it was it was bad it was bad but I think this guy we were able to quickly address it and fix it were you a QA on that one Eleanor no that was not me sure yeah okay no all right all right let's move on how do you ensure that your testing is inclusive and covers a diverse range of user scenarios I think we've discussed that one in a different manner already so can you describe a time when you had to manage testing project with the limited resources um I did because it's actually two QA in my specific team I mean we have a big QA team in general but we divided by the products and in my product team it's only me and my co-worker so when either of us actually taking a vacation it's only one person left so um and usually we for some odd reason if we're taking this vacations it's more than a week so um so yeah I would just let the team know like hey um you know it's I have a limited capacity I have the you know my own tickets plus I need to make sure that oh my you know my co-workers tickets are also forcing you know they're they're not forgetting or something so um so yeah I'll let the team know I will probably reach out if it's something urgent and I know I cannot make it I need to be honest with myself as well um if I can or cannot um and just reach out to like QA leader manager and just let them know hey can I please get someone to help because like I have this and I just don't have enough capacity over time um to fix it or to test it so um I think it's very important to basically um always always evaluate what you can do and what you cannot and do not promise more that she can really do um I think that's one of the big problems for the newbies when they check yeah yeah I can do this and I can also do that and I can also take that project um nope it's usually not happening so absolutely no yeah does that what you said Eleanor is definitely valid and for me I feel like every time I said I can do it I would end up working 12 14 hours a day you know and then just like then you know your girlfriend says I think you're working a little too much to be like hey you know I promised this I gotta deliver on it right so don't put yourself in that situation uh like Eleanor said you know be conservative right uh with just a little bit of effort on top of it in the sense that we're a little bit not effort but probably the word that would say extra on top of it where you can say Hey you know I'm projecting to do you know X many test cases for example or automating 10 tests in one week but that's very conservative estimate right and um yeah just don't put yourself in a bigger shoes than you really can um then you really can get into because then you make yourself look bad because you give them promises and timelines and numbers and then once you don't hit those numbers they're like yeah but you said that right and you know it's always better to under promise and when we're delivered than our promise and under deliver right yeah for sure Plus 100. alrighty then can you tell me about a time when you had to work Under Pressure to meet a tied deadline I feel like that's always the deal isn't it sometimes more than others right but yeah I think I even got asked a similar question uh or similar nature question when I was a petty when I was working when I was working when I was an interviewer for PayPal and they said um what if there is something that's super critical that you need to uh you know finish and you're like working hours are officially over right you did your eight hours or however many hours and you know I would say I would just stay and finish it right and whether it's going to take me 10 11 12 hours I'm gonna put in that work and not potentially sabotage my team or the project or whatever it is we're working on and um you know then we can figure out how we can maybe leave next day an hour earlier or something like that and companies are typically nowadays are very aware of those things like if you're put in so many extra hours after work and then they'll say Hey you know take a couple hours off the next day right yeah typically I would like to say yeah you know I would definitely stick to it I would put in extra hours and you know whether it's extra cups of coffee but I'll make sure to get it done that kind of shows the interviewer that okay this person is not lacking the effort and they're able to stick it out for the team yeah 100 agree or two thousand people are I think it's a very popular question actually how you can actually work under the pressure and tie deadlines yeah and you always say easy I can do that you always say yeah I'm ready for it I like it I like challenges that is the biggest sick day right just kidding I'm just kidding all right guys I I want to add something that came into my head um when you know when we asked that question when you're being asked that question you know can you tell me the time uh when you had to work Under Pressure what like typically happens um is you know when you have so many things to juggle and you know the the deadline is approaching some people get really like frantic and lost and all these things so I think if you say that you also stay organized uh and making sure that you kind of have your ducks in line and then it's just a matter of time for you to you know fit into that deadline by making sure you stay organized because you know so many people would just go like Mayhem and you know they have this project right here another project right here and or and and they're not really um knowing how to properly prioritize and organize and I think those are really important so kind of structure your answer in in that way and include organizing it because that I think that's really the key I think it's also very important to mention and not forget that we also have quality in the at the beginning of our uh blog position and I also very it's also very important to mention that sometimes when we're trying to run for the uh very tight very tight deadline we forget about the quality so I think it's also very important to mention when you have an interview process that yes definitely stay organized but if you know that this specific feature needs some you know more time to spend on it and making sure that we provide qual good quality high quality product to our customers we need to make sure because we also you know we need to not to forget that we need to provide a good quality service oh yeah that's for sure quality first okay all righty next one how to ensure that your testing is accessible to users with disabilities or special needs that's very interesting because for example I know companies um it's different for each campaigns some companies did it in home some some companies actually hire third-party companies that did accessibility testing for them because you have to have a specific training actually to make sure that you can do the accessibility testing it's it's not that easy so um yeah I think it depends so if you have to do the chill work and you don't have an experience you need to be honest with it and ask if there is a training to that they can provide or pay for your training to do the accessibility testing yeah I never had to do any sort of accessibility testing in my career either yep yep plus one two with Tesla uh Tesla did you really just call me test but okay [Laughter] of a QA world it was a compliment okay okay I could agree with what Ella just said it depends on the requirements and it depends on the company because in my experience we've also hired other teams to do accessibility testing and actually implement it and I remember who did implementation but accessibility testing was done by the outsourced team alrighty and next one can you give me an example a time when you had to collaborate with the remote team members or teams located in a different time zone all the time I mean my whole company Works in you know in the whole United States and we also we also actually have um employees in India as well so um you just need to make sure that you for example like all our meetings usually in the morning because it's morning for like Pacific for us here in California and it's actually day for like people in east coast yeah so usually all the meetings something important usually always happen in the morning same story in my hand um but sometimes I would have to jump if there is a release and if there if your entire testing team is somewhere in India or somewhere in Eastern Europe and there was a release happening and there is no one to support it you have to support it yourself and then stay up late until they wake up to not only not only send them a message by describing the situation and the needs but also talking to them so they could ask you follow up questions in case they ever have that really happened but that did happen as well sometimes you have to be flexible when it comes to oh yeah all right can you describe a time when you had to troubleshooting complex technical issue during testing complex had something similar didn't we I don't think so but that's a really a an interesting question because I'm thinking right like is he talking about a complex technical issue with you know the functionality or are we talking about something even wrong with your environment right well like and in this time right I would ask hey could you elaborate like what exactly are you talking about because I might start talking about oh yeah like my server stopped running and I couldn't figure out how to you know do it and the interviewer might be asking us about something like regarding the functionality of the application right so what's what's your take on this one what are you talking about Sergey yep that's a great question let's talk about your testing um about your testing generally so complex issue with uh let's talk about both let's talk about the environment first so people will know yeah yeah I mean for me certain things that would happen like um for example the server stops running and um I I'm trying to do something on UI right and all of a sudden it crashes right and then then I have to go into like vs code and see okay is my server running and I need to you know see is my Docker containers are running or whatever uh Powers up your environment or even if you have let's say um testing something that requires particular environment variables right you might have certain environment variables that are outlined for you in a ticket or the dev passes to you and you forget about them and you're testing and you're like yeah I'm not getting what you what were you telling me or I'm not seeing what I'm supposed to be seeing and then you're like oh okay like I need to go into my EnV file and add these things and really start the server and yeah I think those are kind of um I would say not complex they're not complex after you know what's going on but yeah you know while you're in it it's like what the heck is going on like you could spend you know 30 minutes an hour trying to figure it out and it's as simple as like an environment issue um yeah and we're testing you know if we're talking about some sort of complex thing um it's yeah I can't think of anything off the top of my head except like you know trying to figure out like why is this button when I click on it it's not working then I kind of started going down figuring out like is this button tied to anything right is there is it supposed to take me somewhere do I and I'll go look at the API call and figure out like what's the response I'm getting from this so I wouldn't say it's like complex complex uh but that's probably kind of the closest thing that resonates in my head right now yeah and it's very abstract question because you could think about it in quite a few different ways so you should always double check and ask questions ask follow-up questions what do you exactly mean can you give me an example can you elaborate all right sounds like we're moving forward next one how do you approach testing new technology or unfamiliar software tools you just start clicking trying go to the different directions um yeah you need to fully you know dig in I mean to it and see what it is um if it's a different environment I mean it doesn't even matter you just need to start testing like really for testing like how you do anything else I I don't see how different it is from anything else to be honest yeah yeah I definitely I was asked that once also an interview question uh and I typically like you when you transition from company to company it's difficult to find you know that every company uh you know companies are not going to use the same Tech stack and you always have to learn some sort of new Tool uh so for me I found the best way is one for example if I'm switching a company that's the tool that they're using and I haven't used it before I would kind of connect with like let's say who's the best person in the company to connect in regards to the store like who's the master of this right I'll try to talk to them because if like let's say they're my teammate uh and we're using some sort of framework or something like that I would say hey like can you give me a brief rundown like what's different between axios and super tests for that's the API Frameworks right and um you get that like person to personal interaction first in the human language and then I would go into like documentation you know looking at different YouTube videos and things like that but my first approach is go to the person um if you know given that there's a resource like that forever available for you and your team in your company and you know go documentation YouTube video or whatever else resource you think is fit yep yep for sure I'll quote Andrew one of our uh one of our keys students from the past read the official documentation whenever you're learning new tool new language with the official documentation whenever you're jumping on the uh on the new technology or approach in testing new technology also read a documentation about it and ask questions as we always do pretty much same answer already can you tell me about a time when you had to investigate a reported issue that was difficult to reproduce I'll probably pick this one if you don't mind because that's quite that's quite a common one get away sir uh yeah that's quite a common issue where someone else reported an issue and you're having trouble I have problems to reproduce it number one you do your best to understand it number two you are double checking with a person you're asking the person who had reported that question hey can you elaborate on the steps to reproduce because they are not clear or can you update it you can directly ask that person if that person is not available uh you could talk to you if it's another team and for some reason you are testing someone else's tickets or another uh teams feature that you are not familiar with and that person is not there to explain it I you know talk to product owner talk to project manager if that's the person who knows it better talk to a developer if only the app is available talk to number QA team member from that team who knows that product or feature better than you they'll be my take on it how about you guys no yeah that makes sense all right now unless there's there's been times that you know customer reports and they should you just can reproduce it you know you're sitting there one hour two hour three hours and you're like okay how how critical is this and you say okay let's see if it happens again if it's just like a one-off thing and you're spending too much time trying to reproduce this thing it's a you know it's a waste of companies and resources it's a waste of your resources uh particularly your time so um yeah if it's something that's a one-off thing and you're spending on a couple hours and you say yeah it's probably you know let's let it go and see if it happens again and then kind of look into it much deeper after that for my technical experience um sometimes you just cannot duplicate it whatsoever just because people can have different types of environments that you really cannot have at work like you don't really have any sources for that so sometimes but you definitely need to get as much information as you can regarding like what they use what the environment the problem is actually happening at yep yep and on the top you should kick their butt for not putting all of the needed information in the ticket and so next time they would know to do that right alrighty in the next one how do you ensure that your testing is aligned with overall product goals and user needs requirement I don't know that's I for me requirements are always King like it's man it's that's just kind of the most solid answer that I always jump into and say hey that's the requirements right uh you know customers are always going to tell you um you know hey I would want this we want that and the requirements might be constantly changing and it is for the person who handles those requirements uh you know it could be a QA lead or it could be a project manager to maintain the requirements documentation to make sure that any sort of deviation is you know it's documented and you know we're testing accordingly right because if customers are emphasizing certain things or stakeholders whoever you want to say and we still have the old documentation all the requirements then it's like okay now we're going to two separate directions so yeah requirements for me say hey there is nothing to add to Anton just said so yep yep plus one Anton you got it already can you describe a time when you had to manage conflict and priorities with your testing team so your team wants you to test something but you're like I got my own task guys not gonna happen now my hesitation like that I get into communication you're just letting them know like hey team I would love to help but unfortunately right now you know I have some other tasks that are the priority for me right now and for my team for example it all depends on the priority and um it all depends how much you can handle again sometimes you maybe want to take more and more you know and maybe work some overtime to help your team because again team building you know it's all about the team um so yeah but if you know that you just cannot do that just be honest with it and communicate you know don't my main thing is just don't promise don't promise something that you cannot deliver that's my thing um because I had issues with that before in a different companies where people would say yeah sure I'll do it and then forget and then you're like hey I like what's going on so yep yep agreed uh all right in the next one can you tell me about a time when you had to test a feature or a product that was controversial or potentially problematic oh yeah I'll probably start with a uh if it's a product there is controversial or problematic this conversation should have happened during a Sprint planning with your product owner or the project manager developers and designers because if that's the product related it should have been discussed way before and planned way before it gets to the testing point yeah thumbs up sorry thumbs up all right kill it moving forward to the next one just give you you just give me a compliment to yourself right just get killed good job Sergey are you true that your testing is efficient and does not result in unnecessary duplicate duplication of efforts okay Eleanor that's your favorite word you gotta say it come on communication yeah you think that one you take that one I'm not gonna try it how do you ensure that your testing is efficient and does not result in unnecessary duplication of efforts I'll actually take it because this um this in some way could possibly require Improvement of the testing processes of the QA team because most of the time QE teams simply plans out a day and then they do the testing and uh but a lot of teams are starting to moving moving their tasks into jira projects and creating separate boards for the QA team where team members would create a ticket to whenever they would work on a task so you would get to the QE board you would see what other people are working on and you that's the way number one how you would duplicate testing efforts because you will note that such a person is already automating this task you know that such a person is running regression for uh for the release 403 you will know that such a person is doing some testing efforts on the other end or writing test cases for that functionality so you will not duplicate it and also you on a daily basis teams have Sprint not in Sprint Linings but daily syncs where they where they talk about what they've done yesterday what are they planning to do today and if they have any blockers so you would also specify during dancing and this is the way to avoid unnecessary duplication of an effort again but also I mean during the Sprint planning you also signed tickets I mean I don't know how that I mean I guess it's everywhere I mean that my experience it'd always be like that where you actually would assign tickets and you know what your job is for this specific experience so you know that you're not doing something unless it's change of priority and something changed but again communication I guess uh you know just to make sure you're all on the same page yeah yep yep moving forward all right can you tell me what a time when you had to learn a new technology or a software tool tricky for testing purposes oh quickly for testing purposes so you had to learn the new tool or technology a really quick for testing purposes um I kind of did um that was for the accessibility actually we were basically testing um it's kind of like uh what you call it not extension not a ad anyways that's a specific problem let's put it this way that do the accessibility testing for you on the page is basically checking the page and telling you like hey this is what you need to change for accessibility and what I did I just basically that a company had the YouTube learning videos and I would just I just quickly watched them and see how to use that too um of course if they had a documentation but I guess YouTube video was much faster because they were showing you right away over there you know and that's was from the company that providing that program so um yeah that's how I did it about six years ago I had an interview with the goat a company that sells sneakers shoes and they gave me a challenge to write API test automation framework from scratch in in Ruby uh yeah in Ruby and I never or something else I think it was a ruby and I never learned Ruby I was a jazz guy I was also pretty much always a jazz person and then I was like okay let me figure it out so they gave me two days like but I think I did it within four hours but the three hours was installation process because I had to install python on my Mac and download that installation to realistically three hours and then it took me an hour to create automation framework from scratch and automate five API five API uh five apis and what I did during the three hours of wait time I simply created uh very easy to read animation framework in a JavaScript I sent it to them while I was doing the while I was in installation I said hey guys while I'm doing installation on Ruby uh it just takes really time so first I did in jazz just in case you want to see how I did it Jazz I emailed it to them and then after I finished the installation I did in Ruby and also emailed to them that was my take on the learning tools quickly I guess it's about um it will be about the speed of learning of a different people and also the approach because since I had already had experience in a different programming languages learning another language or creating framework you just read the documentation as Andrew said official documentation which maybe read another article if there is not enough but official documentation is the best one to go through and with enough experience you can you can do it with a matter of hours and it's also about the research unfortunately I find out that a lot of people don't know how to use Google and it's a very useful thing to know I now it's actually a skill to you so just to do research yep and ask and our skill which is going to be very similar to how this Google is how to use chat GPT yesterday one of our students got an interview Challenge and she called me she was like I don't know how to write unit tests I'm like do you have a function that you have to write unit tests for yes just paste it into chat GPT and say hey write you need to test for it I did it on my own it gave me uh three or four tests right away and uh indeed it in the mocha way pretty much it beautifully gave me an outline task tests unit tests and then if you want to update them you update them but they're fully ready to go am I the only one person that didn't do anything bye all right moving forwards moving forward how do you ensure that your testing is scalable and can handle increased user traffic or volume um I guess it's going to be a performance testing and load testing done yep yep that is correct and I think this question wouldn't be necessarily be related to manual testing anyhow but mostly into Automation in a way of using performance testing tools and load testing tools for JavaScript will be k6 if I'm not mistaken that's the easy one to go through by the way thanks to Andrew who found that tool Andrew was to Remember You um yeah I don't think manual testing would be related to it anyhow right I mean no not really I mean unless you have a huge QA team and all of you will try to do something in simultaneously I guess I don't know but no I don't think so yeah I would double check on this question with the person who asks it but because maybe they are talking about um about feature the team not a team actual functionality is getting bigger and bigger really quickly and you got to make sure that there will be someone to support it but once again it's easier to hire an automation engineer and just automate things quickly yeah alrighty let's go through six more questions I'm gonna call it for today all right can you describe the time when you had to deal with unexpected issues or challenges during testing how did you approach solving problems did anyone cover that about like having some sort of troubleshooting like issues or something like that yeah foreign how do you prioritize your work as the main lka engineer for answer for Anton yeah I guess um organization and again those are the things that I mentioned throughout this interview organization and uh priority level of priority right that assigned to uh whatever test cases you're testing because when you're a manual QR you're doing all the testing manually right and uh you really want to make sure that whenever you're preparing for some sort of release that uh and if you are you know against really a deadline and you have to pick and choose you are able to um either refer to your test case documentation where you have you know um you know this is like high priority uh test case to test right or if those things are not indicated in the test case management system you're just say okay you as a person who's working with the application and being an expert in testing you essentially go through your head and say okay what's what's critical what's what's the priority right I think organization priority again that's the top of the list so there's never a point in time I'm going to answer this question differently because organization and priority is key absolutely um same thing just being organized yeah all right then we got the number one what is your approach to collaborating with developers during the testing process so pretty much how do you collaborate with devs during your testing process um I guess the correct answer for this will be through like uh tickets for example like for the jury ticket where you actually put the comments um and tag your Dev um I think that's probably one of the right answers um it depends on what kind of communication you have with the devs um it could be like an open channel on slack for example where you can also start a conversation um about something um I don't think because I think I know that there are companies where you cannot directly you shouldn't directly reach out to your Dev so maybe if you have any questions and you have a QA lead you can reach out to your QA lead um you know discuss the issue and then they will reach out to the dev I think it depends on different companies have different approaches on that yeah yeah totally yeah for my company I had a really tight-knit relationship with developers so at any point in time during the day I'll be like hey um we got to jump on the call we've got to take a look at this thing so it was like a right okay cool let me send you a slack um or let me huddle you real quick so it really depends on the company typically bigger companies uh that have way more structure are more strict about it where you said Eleanor uh but smaller companies typically a little bit more fluid in that regard hidden experience but it was almost impossible through each other so um we had to go through our um QA manager actually for communication and I think yeah you're absolutely right it's probably more for like big companies for big bigger departments versus like smaller companies and startups yeah in my case um mostly we have a pure I mean direct communication through the Juris elemention but also if I would know the release is going to be at least should be happening tomorrow and if I'm finding an issue I'm gonna shoot out directly to the guy for the slack and going through this with him or with her and then I'm asking them to fix it ASAP because the release is tomorrow and this is really critical otherwise we're gonna have to postpone release or kick this ticket out of the on the release bucket already I think we went through quite a few questions today uh I'm hoping that this video is going to satisfy quite a lot of people who are planning to become a QA engineer or for radical Engineers that want to improve their skills anything you guys would like to add and to the end Ella or Anton any advices for the future generation of the future QA engineers I always say to um people who want to join the QA and start doing going through some interviews smile please smile during the interview um please sometimes it's also good to add a little sense of humor um to one of your answers you know just maybe a little joke because that's how that interviewer is actually probably going to remember you as well which you're gonna you know have a funny moment together but again be careful you know nothing too too much um and um yeah I just have a very positive attitude because I really want to mention that sometimes it's not about the technical things it's about what kind of person you are um what energy you're actually gonna bring to the team um because I actually met managers in my life who were like hey I can teach you whatever like I can I can you know I can spend time teaching you but if you like a bad influence to the team I won't be able to fix that so always always have your best positive even if you're not a positive person but still please try be positive during the interview it's a smile so so true so true yeah that's that's really those are the keys uh Eleanor you hit it on the on the head a nail um yeah make sure I also ask questions that might stand out for the interviewer right if they open up the time for you to ask the questions uh you know make sure you don't say oh yeah no I don't have any questions right because that will just show kind of your interest in the company could potentially right it might not be a 100 true but uh typically I always like to ask questions when the time is given you know I try to find out hey could you tell me a little bit like what does the team structure look like right what does your Tech stack look like if those are the questions that are not previously covered by the interviewer themselves right I would ask those questions because that kind of shows my interest okay I really want to know what the team structure is what you know what a Technologies and things like that they're using so yeah ask questions uh show interest right do your research about the company uh again chat GPT is your best friend because what you can do and this is what I do uh if I'm looking at a particular company and you know you can look at their website and maybe you're not quite getting what they're what they're all about you just copy and paste their link into tragic you can say what does this company do and it's going to tell you exactly what this company does and you don't even have to think as sad as it sounds right so yeah I think those are the things that I'm going to close with I also want to add one more thing for people because I also saw that a lot um people who are just moving to United States or people from different countries people like any Foreigner basically who maybe not have a pretty good English or have a you know a thick accent please don't be afraid of it uh that's fine we're all different uh and just talk just just because I saw so many times where people just really want to tell something but they're so you know um getting very hesitated about their language and they don't so please don't yep yep and what are you gonna happen and what I'm gonna do in the future I'm going to bring Kate I'll wear our Russian spy who went through the QE course whose English who could understand only 10 of the English uh when we were going through the course and she finished that in two months she got a QA automation engineer job then a year later she's already doing some API automation testing in another company and she's switching jobs easily but her English is still broken and she it's so broken that she's not she's still not even agreeing with me to come for a interview in English she's like I don't I'm going to feel bad people gonna see my English I'm like you're getting jobs what the hell are you talking about that's quite crazy so I'm going to try to bring her for an interview and I just recorded a video with that I'll send it to her and hopefully I will attach link I'm not sure where you're going to touch it but hopefully I'll attention somewhere here or there so you guys could see how you can get a job I mean how bad can your English be to you and uh in order to get a job well thank you very much for joining us it was quite an amazing an hour and 30 minutes interview we did the record thank you for coming and I hope to uh I'm gonna post the links to your Instagrams if you don't mind in the in the description of this video so people could message you and ask you if you're a real person otherwise thank you guys for joining and I'll see you again soon absolutely take care guys bye an hour and a half Wharf of behavioral interview questions you must have enjoyed it and you must be really dedicated person if you are if you're still here with me please leave your name preferably your full name in in the comment below so I would thank you personally on the next video that we are going to introduce on YouTube and also if you ever decide to go for a QA course don't forget to give us a call at columbified.com on a contact us page and tell me that you did watch it until the end I'll give you 10 discount on the top of anything you can possibly find over the Internet because I like dedicated people as I am very dedicated myself regardless thank you for watching us don't forget to give me a big fat thumb up hit the Subscribe button below and I'll see you next time [Music]