 Myself Vivek Sharma, I am from XYZ company. That is how general interviews start in India. Mostly, I don't know about abroad. But people, by heart, they're by myself itself. So yeah, but my typical answer to that question is, my name is Robin and I have been a sales executive, and a lecturer at an engineering college, and business system analyst, manual tester, automation engineer, Tesla as in, I've done a lot of things for money, okay? So with that out, see, I've given a lot of interviews in the past two, three years and I've taken a lot of interviews in the past two, three years, and I've done some research also, like late night googling and stuff. And that is when I started to see patterns or anti-patterns for that matter, okay? See, the core reason for this talk is that I am agitated and angry and irritated by the traffic jams in Bangalore. I'm actually angry about that, but the actual core reason for this talk is, this entire test automation interview circus going around town, right? So you guys, in India, you would have felt the same thing. You know, people ask you file IO in test automation, right? Or method overloading versus overriding, like 100 times, like whenever I go, method overloading, overriding. Okay, sir. Spellings are different, right? But the interviews nowadays, they become like stage plays. Stage plays like the interviewer, marks of the Fibonacci series code, candidate marks of the Fibonacci series code, they say their dialogues, and then the selection is mostly done on some other parameters like cute hairstyle, nice clothes, nice fragrance, stuff like that. So, technical interviews like this make me feel like having a cigarette most of the time. I'm feeling like having one right now. So, what you guys, all of you thought that I'll light it up, right? The fact of the matter is that I'm not a smoker, okay? Yeah. Anybody wants this, it's kept here. And the light. But everybody judged me. That is the main thing. See, it's human nature. We tend to judge people, we tend to judge them as soon as possible, right? Interviews do that all the time, which actually agitates me, right? So, I'll give you an example. So, this guy, he bumped classes, or like he ran away from classes, he learned calligraphy, he went to India, and he had mostly no technical skills. Would you hire this guy? The main question is that, because this is the same guy as Steve Jobs. So, that is my main point. You should not be judgmental. You should not do snappy judgments, okay? That is the main thing. You should not judge a book by its cover, or a person by the cigarette in his hand, okay? That is one thing. Moving on. This is another thing one of my friend used to do, is he used to play for the gotchas. Gotchas are like, you know, questions like FizzBuzz. FizzBuzz coding interview question. Very famous, very common, very easy. So, just to introduce you to FizzBuzz, we have numbers in a sorted integer of array. And you should iterate to the array for loop. And if the number you find is divisible by three, you print Fizz. If it's divisible by five, you print Buzz. And if it's divisible by both three and five, you print FizzBuzz, right? Pretty easy. So, it has a very nice gotcha element to it. You know, if you don't write the if, then if else if in the right order, you get it all wrong. So, what my friend used to do is like, you just wait like an eagle, an eagle flying. He used to wait. Oh, this guy wrote like, if else if wrong, right? Oh, gotcha. See, can't carry an interview. Can't do if else if right? Like, how does it connect to actual test automation? I have no clues. But the main factor is that people play for gotchas. So, that is my second main point. Interviewers should not play for the gotchas, right? Interviews should not be your ego satisfaction exercise. You know, like I am the smartest person in the room. You know, by the way, I invented data structures. Do you know data structures? Things like that. So, a lot of people tend to do that. I hate them. Like, I want to give them a high five in the face with a chair on the spot. Good. So, that is one thing. The next thing is like, okay, this small story. I was passing by Silk Boat a few days back. I pass by Silk Boat every day. But a few days back, I was passing again. So, the signal was stopped, okay? And I was browsing mobile, Facebook stuff, wasting mobile data. And the taxi driver next to my scooter, he says, something like Habu pump, something, I don't know. And I'm like, yeah, he's asking some time or directions. I'm like, yeah, Kannada is not there, sir. Which actually means I sort of don't know Kannada. Then there's this cute lady sitting in the taxi. Very cute, lovely. He's saying that the driver is saying that there is a snake under your scooter. The next thing I do is like accelerate, almost bump the next car, right? Lesson learned that day, be a better listener as an interview. From that day on, I'm like a lot better listener. Whatever you say, even if I don't know the language, I'll listen to you first. If you make hand movements, I'll be better listener. So, yeah, sorry. Yeah, after the snake, everybody would forget the cute lady. Okay, so yeah, that's the thing, be better listeners. Interviewers should be better listeners, definitely, right? You're not there to blow your own trumpet. You're not there to solve your own questions. You should ask questions, listen for the answers. You can ask impossible questions, by the way, but you should help the guy in front of you, okay? So that is one thing. And a few days back, I improvised another poem. It's like roses are red, violets are blue. Let me ask some Java in a Selenium interview. That's okay, people ask Java. It's okay, right? I ask Java whenever I take an interview. It's okay to a certain extent, okay? Then, but you know what happens is that it gets sort of weird after a point. How it gets weird is like people start asking you serialization and deserialization. You know, traverse inverse of binary tree. I don't know, I have never used that in test automation, right? I don't know. Who traverse the inverse of binary tree to get some web element, right? I don't know. So people ask that, I get frustrated. Same, you know, high five in the face situation. So, yeah, my tip is that, you know, ask contextual questions, ask practical questions. You know, ask things like how can you do cross browser, parallel stuff in grid, something like that. Or you know, people love to ask like what is Selenium? Like when somebody asks me that like what is Selenium, I take my CV back. Sir, what is Selenium, come on, right? So yeah, so I asked the lady a few days back in an interview that, you know, what version of Selenium do you use? I generally tend to ask versions. Let's me know how practical you are, how hands-on you are. And she says 42.1.1, and then two dot something, maybe. No, no, no, we use the latest. We have Maven for the latest, awesome. So yeah, that is the main thing, guys. You know, ask practical questions, ask contextual questions, help me help you, help the other guy help you back. And so, you know, when you ask these questions, when you ask practical problems from your project, you might get some really good out of the box solutions. You know, you might not select the guy, take his solution implemented, say you did it. Some guys do that, so that is one thing. So yeah, enough said about the interviewer. I think I'm done, five minutes. I think I have a lot of things. So we'll move on to the interviewer or the candidate, okay? He's the second most important part of the equation. We have only two parts, the interviewer and the interviewer. So yeah, two, three years back, I came back from US and I attended this interview for ENY, and the interviewer asked me, Robin, how good are you in SQL? I was like, sir, I came from US, I'm pretty good in SQL. He said like what score, like on a scale of one to 10? I said eight out of 10, I'm confident. So he said, do you know triggers? I said, no, I don't know triggers. Do you know how to like set up data basis with schema and stuff? I said, no, I generally borrow queries from the dev guys. So this guy says, Robin, you suffer from Dunning-Kruger effect. I even didn't know what was that. Now I know. So yeah, lesson learned. Lesson learned is that I was very overconfident. Interviewees should not be overconfident at all. Like I was overconfident beyond sanity, right? You should definitely not do that. And the other lesson I learned that day was like a trip and tricks. So you should undervalue and overperform. For example, when somebody asks you, how good are you in Java? I say like I'm 5.1 out of 10. And he might ask a silly question, easy one. I kill it. I kill the question, I kill the interviewer. That is how I do it generally. Or I used to do it, by the way. I'm not giving out my tips, okay? So yeah, you guys can do the same thing, right? So undervalue and overperform in the interview. That is one thing. So few months back, there's another interview I attended. And this guy asked me, like this is like nine months back or something. This guy asked me, have you done testing for responsive web? Like yeah, definitely, obviously. I've been testing for responsive web. My web app takes all kinds of responses. Small loads, big loads. We even got like proxy mob, we handle all the HTTPS stuff. This guy smiled at me, like really cute guy that was started in Bangalore. 10 member team. This guy, he's like the CTO, he smiles at me. I'm like, yeah, he's smiling, awesome. Later on I go home, do some Googling. What's responsive? Then I smile again. Responsive, okay. Responsive has a different meaning, right? So yeah, like then I understood that you should be good in your basics, right? Like one of these days or few days back, we have juniors join our company. I'm from Happiest Minds by the way. And apart from the name, I asked this lady that, do you know what are front end applications? She's like, yeah, front end is what you see in the front on the screen. Like back end is what you see at the back. Obviously, I don't know. Like people are pretty confident on their web basics. So yeah, that is another tip. You know, guys, be good in your basics. Understand how the web works. We are into test automation slash Selenium slash web automation slash mobile and other stuff. But the fact of the matter is that we should definitely understand how the web works. It does not matter. You're from CS or IT or Mac, EC, branch, school, wherever, India, outside, Bangalore. I don't care about it. Nobody cares about it. You are into web testing, sir. You should understand how the basics of the web work. You should understand things like what's web spear, what's rest, what's soap. I was telling my friends like few hours back that I took an interview and I asked this person that have you done API testing? Yeah, I've done both soap and rest. Very good. And so I asked him that, what is the full form of soap? He's like, yeah, it has APIs in it. Like, do you know what is state transfer? Yeah, that's also got APIs in it. I'm like, no, no, no, no, you've got it all wrong. So people, you know, tend to cover a small portion and then they overestimate themselves and they are like, I'm a big pro or a master in API testing or testing or for that matter, anything else. Should definitely not overestimate ourselves like I do or used to do. And, okay, so that's that. Moving on, what I believe is that interviews are like your first dates and like romantic dates. You are calm, you act cool, you act shy, fake smile, sweaty palms. You even wait for the call back from the other guy. You know, he might call me tomorrow. Okay, I don't know. You might have a long term relationship. I don't know. So see the point is it's as long as you are actually good, right, it's just like love. As long as you're actually good, you love what you do. You understand your basics. I think you should be good in a long term relationship. So yeah, that's one thing. And I as an interviewer and a lot of other people as interviewers, what they do is they say that, you know, do you have any last questions? So guys, don't waste that. You know, a lot of my last question questions have helped me in the next interview. Like the Dunning Kruger effect interview. So yeah, so people ask that, do you have any questions for us? I ask that a lot. And that is the point when you should ask, you know, your objective and subjective feedback for the interview. You know, you would obviously understand that by the course of the interview or by the end of it, you will understand how did it go. Did you answer the questions correctly? Good, did you not? Not good, stuff like that. But you know, if you ask him, I think it becomes a lot easier for you to ramp up for the next one. So I had this lady come in and I asked her like, do you have any questions for me? She's like looking at my phone and do you have iPhone 5 charging cable? I have cable, like that's a question wasted, right? Totally wasted. So yeah, that's one thing. And then there's one more very important piece. This is like the most important amongst all these. The only way to, you know, be good at coding is practice. Just one word, practice and the hard work and perseverance, like two more words. But the fact of the matter is that as long as you practice, hands on, you'll be good, right? Interview is candidates, folks like me, folks not like me. Please don't mug up the code, okay? It's a trap. It's like wearing your pants on your head. It's like, I'll buy hard my math book tonight. It's not like that. You know, you can learn the Pythagoras theorem, but you can't learn the implementation, right? So that is one advice. There are like, I think N number of websites today. They were not there when I appeared for a lot of interviews, sadly. But now we have like coding bat is there, hacker rank, hacker earth, top coder, N, N number of things, okay? See what these will help you in is doing, is a lot of practice and a lot of companies nowadays, at least in India or in Bangalore. They subscribe for the online test before you actually do a non-campus interview, right? So when I like, came to know all about this after a mishap, I had to attend a test online and I'm like first time in my life I'm seeing hacker earth and they have a small code piece which you should run and then the actual code piece. I'm not able to solve a simple programming problem because I've never seen hacker earth or hacker rank or those things before, right? So yeah, that is the crux of the matter. You should practice, practice, practice. I can repeat it like seven more times for all my fingers, but you should definitely practice. When I say practice, my juniors tend to say yeah, sir, we practice test automation daily in the project. No, that is not the case, okay? You should practice in the project, you should practice out of the project. It will keep your brain running, okay? So as simple as that. So Abraham Lincoln had once said that if you give me six hours to chop a tree, I'll invest the first two hours in sharpening my axe. The same applies to your coding skills. If you don't sharpen your axe, you know, your axe will go blunt, you will go for an interview, they might shout at you, leave dogs after you. I don't know, so frustrated, right? So things like that, you should practice daily, at least or like twice in a month. Something like that, I don't know. It's like your gym schedule. You should definitely go to gym and you should practice a lot, okay? So yeah, that brings me to actually, the last aspect of my talk is that the interviews which you give are like your portal to your career, you know? What a lot of folks don't understand is that if I'm getting 40% hike, I'm good. No, it's not like that. It's not about the hike, e-sop, free food, nice coffee, and as a matter of fact, I fell for the free coffee. Yeah, I used to work for a company with, you know, whose name started with the A and they don't have free coffee. So yeah, those things are part, the fact of the matter is that don't fall for these traps. You know, your interviews are your portal to your career. So you decide right now, like we had this interview question, where do you see yourself five years from now, right? All of us have like brilliant English answers for that. It's not like that. You should regularly and definitely figure that out right away, in the right way. Because you know, see that for the dev guys, it's sort of easy. You know, dev, senior dev, architect, senior architect, so on and so forth. For testing, how it happens is that tester, nanodester, automation engineer, senior engineer, test architect, people manager, it suddenly like becomes like a branch out of a tree, right? Like people tend to get confused after four or five years of their career, what to do next? Should I do PMP, Prince II? I don't know, I should do ISTQB? Something like that, right? So yeah, don't fall for the high KESOP, other things like that. You can fall for them if you are really greedy. But the fact of the matter is that decide your career right now. And yeah, then the last word is that yeah, I had gone for an interview next, there was this building next to my current building. I told my manager I'm going for lunch and I went for an interview. Yeah, I think all of us do that. And this lady, she handed me a laptop and a paper full of programming questions, and she's like, you know, make programs, we'll judge you on the programs you write. I'm very smart. What I did is I went to the HR back and asked her for the bathroom. Go to the bathroom and I ran away. I disappeared from the campus. They had questions like, you know, perform 2D array rotation using Java. Like pretty simple questions. And I had no clues about that. And I was pretty sure they will ask me about the big O notation also. If I do this, big O is next. Or you know, O log N is next for guaranteed. I don't know, I have never used those things in my test automation. We are a small company, we do small projects, simple ones. But people tend to have an affinity for that. I don't know why. And I don't think it's going to go away in the near future. So yeah, the important point is you guys need to practice a lot, okay? So yeah, a lot of you would be expecting slides. So I did slides. Then I redid them after, you know, all the projector magic happened yesterday. So I made projector friendly slides. So that's slide one, very important. We are here right now, okay? That's slide two. All the characters appearing in this work were fictitious, mostly, including me. And slide three. So the original slides for this talk, which are there on the description for Seacons can be found at the first URL. Inspiration for this was taken from Ted and Toastmasters and some other blogs. I don't know why they're showing up. And Google and YouTube, as always. And you can find me at my email ID or my LinkedIn profile. That's it. Thank you guys. I'm supposed to still have some time. If anybody has any questions, apart from my bank account details, or iPhone charging cable, I don't know. Ask me right away. Tell me, sir. Yes. Couple of times. Yeah, yeah, yeah. People say that you're like five out of 10. Java? Yeah. Okay, so I think a lot of interviews are mostly communication-based, right? So if you feel that sense in the air, dude, he's gonna abandon me. You know, tell him, sir, the scale, first of all, is subjective to a lot of terms and conditions. Like when I tell somebody on a scale of 1 to 10, or when you should, or anybody can, he should tell them 10 means he can code with his eyes closed. That is 10. That is why I'm five. I can open my eyes and code, right? And you know, people tell me, and you know, people tend to love folks who are smiling at least fake, like me right now, or who are confident, who are good at communication, as of now, until we get that fixed. So you know, in the interview, at least, try to be friendly. If you feel, you know, something bad's happening, try damage control, tell him more stuff. You know, I have done sterilization and deserialization. Always does the trick for me. That's one thing. Does that answer your question, by the way? Mostly, yeah, tell me, yeah. Whether do you know SQL or not, and I said, yeah, I know up to a point where I can, you know, get data from the table, just select queries, with where statement, that's it. I told this clearly, still the person kept asking about joints, triggers, and so on. And for every question, I was just smiling and I'm saying that I don't know. See, the good thing you did was you were smiling. The bad thing is, you know, people tend to stick with the interviewer. Like interviewers, like he's the captain in the room. He asks the questions. It should not be like that, right? Like, I am a simple medallist in Taekwondo. If at any point I feel it going bad, I have self-defense. If people get stuck to joints, you know, explain to a certain point, and in ways by facial expression and expression, you can say, you know, I think that's about it, about joints. In my practical experience, I've done this. You know, we should try to drag the interviewer back to what you've done, what do you know, and what you can do for him. You should sell yourself back to him. People tend to love joints, inner joints, left joint, I don't know, stuff like that. Nowadays, we have MongoDB. So you can say, I know MongoDB, I say that. Or, you know, we do Cassandra in our project. Do you know Cassandra? So yeah, like I was telling my friends at lunch that we have fashion words going around nowadays, you know, instantiation, VM, stuff like that. It will be there, you know, the world will be bad. You can't make it good. But at least in that room, we should try, right? Thanks. Thank you. Tell me, sir. Oh, that's a very tricky question, sir. Attitude is a very subjective word, first of all. And what I try to ask is practical questions. You know, like the version number, give him a programming question, may be impossible to solve. Like I tend to ask passive search or, you know, can you do recursive file directory search using Python? Stuff like that. It's difficult. I don't know that. But the fact of the matter is that you should look at the candidate and see how he approaches. It's not about a solution. It's about the approach he takes and how many times he falls and gets back up. You know, the same thing goes with quiz buzz. If you tell somebody that, you know, can you rearrange your ifs, ifs, ifs? Can you fix it? A lot of people say, I don't think I can. But then a lot of people try to do it. And then a lot of people tend to get it right. That's about attitude. That is what I try to judge. Very bad judge, but I try to do that. I just have a suggestion here. Tell me, sir. No, I think, for example, right now, when you do a resume, I think, then putting your email, putting the GitHub account is much better. Definitely. 200%. That's the one thing I would say. And second thing is that, right? I think, for me, now, for my own org, I see testing is changing. Where we look at people who are cross-functional. And being ignorant to say, I need not know a technical part is just being ignorant. Definitely. Just being ignorant. I think I don't think so. Testing is just going to be the testing as we do. All I need to know is how to write this case, pre-condition, post-condition steps. If we all think that's all testing, I would say in a big bank, which has $20 million profit every year, we can do it. But those banks are gone. Sir, even if those banks are there, I would just like to add on. That's a very good point. For me, testing is getting more and more technical. True. Again, right? I think, even if you say, for example, I'm not against a particular person here, even today, SQL or, for example, I think the expectation is that, right, you need not go to a developer to get an SQL. If someone does that, I say, you end up repeating what a developer did. No, not good. Definitely. We should not have that bias. That's a good point. I think you have to, on one side, you look at testing as independent. On the other side, you look at testing as being collaborative. On the other side, you look at testing as being more and more towards agile, more and more towards developer. There are multiple phases. I think things revolve. I think I'm going back to 14 years ago where I had no testing organization. Yeah, yeah. They end up missing back then. I think, I used to say, right, I think if you look at the current arc, we have A, A, B, A, C, A, D, A to every year, business analyst, debt analyst, quality analyst, all the years now, everything is going away. That's what I see. In my company, they say, for doing one job, you need three people, analysts, the developer in the QA, no, come on, cut them, do one. Simple. I think people think we had to put three roles into one team and do it together. I think there's no point of putting three people to do one job. Yeah, they had QAs, then they had SDEs, then they had SDETs. I don't know what they want finally. But if you're in the software world, you should know how to code, end of story. You can't be in the mind and say, I can't touch code. There are folks who stick to manual testing. I'll do manual testing for the rest of my life. You can. And that's a brilliant job. But definitely, you should learn how to automate small pieces. You could write a small snippet in Ruby, Python, scripting to help yourself. Tell me. Yes, ma'am. I just want to ask, if you come to know what the interviewer exactly wants from you, will that help us while we are giving the interviews? And if yes, how do you find it out? Because I have been giving interview from past three months. And it is really difficult to understand what exactly the interviewer is looking. That's like a Pandora's box. A lot of people come, they are like, I don't know what you want. I've got my own stuff. See, but the fact of the matter is that go through the JD. It is general written by the HR guys, badly written. And the second thing is, when you introduce yourself, at the last, you can tag a question that this is what I've done. Does this align to your targets? And if yes, awesome. If no, I'm going. Not like that. If yes, then we can do this. No, I'm a good learner, stuff like that. If you're a good learner, and you can add on that. I know this. We can help you do this, stuff like that. See, the interviewers in today's world, they are like a puzzle themselves. First need to solve themselves, then they need to solve your question, and then help you. You should help them solve themselves. Thank you. Any other questions? Going once, twice and thrice. Thank you for the talk. Thanks guys. Thank you.