Scale By The Bay 2019: Oli Makhasoeva, The Art of Asking Questions

Scale By The Bay 2019: Oli Makhasoeva, The Art of Asking Questions

Recording: Scale By The Bay 2019: Oli Makhasoeva, The Art of Asking Questions

[Music] so I owe you an apology in advance because I was notified that I'm giving this talk like 10 minutes ago so I'm not completely sure that I have all slides in place but I will do my best for you and it's also my third talk at this conference so let's have some fun this is talk this talk is not very technical it's about skills soft skills that I think are important to have one year working as a software engineer or anything so let's start we are at of asking questions are there any questions already yeah I know I'm not supposed to start like that but it's it's an emergency replaced why not right but actually if you still do have questions you can join slide ooh and add them while I'm talking let's keep this part because or maybe maybe we can do that how about audience participation would you like to answer my questions yeah so let's let's let's do that louder okay I will count three two one and you will shout the answer if you are up for this then three two one you can do better guys no there are not a lot of you but still you can do better let's relax this is the second day of the conference and the speaker could not make it so let's just relax and have fun time three two one one plus one equals three two one no it's not - guys come on it's one anyway I wanted to talk about my personal journey the trouble that I've been through in my life in December of 2016 I moved to the United States seeking for my American Dream but I didn't speak English so while I was traveling and taking this pictures have no idea that I would ever publicly show them some of them are ridiculous I was thinking about my first technical interview because you all know right how difficult it is rounds and rounds of questions white board an elder is maybe you don't use them in production but you still supposed to know them and remember them like your hands are shaking they're sweating you're thinking oh my god I need to do that all of that but in English which is not my native M which I didn't know so I was thinking oh my god I need to come up with some kind of plan like how do I nail this interview right and then I thought what if I will prepare questions and while my interviewer answering them I will just sit because everyone loves talking about themselves so while they enjoy answering the questions I will just pretend that I know English very well yeah cool plan but before I'm going to give you framework how I nailed it I want to talk about this particular to it so Scalia invited me to give my first keynote ever and I was so thankful and I was so proud and so grateful that I wrote this - it may be the most important tweet in my career so far and you know after all these years I still cannot spell the word grateful so 65,000 fused 65,000 people know me is the only bad spellers and the reason I'm saying that to you is that yes I was really really nervous before my first technical interview in the United States even though I had experience as a software engineer but still I was very nervous but then I realized I don't have to be perfect and you don't have to be perfect either the most important part that you are passionate and you care about what you do so I decided ok it's too late to remove that someone already retweeted that Samael raised like that so let let's use that in my keynote why not so back to my plan I googled and I figured that Joel Spolsky wrote this article about how to evaluate your own system where how to evaluate someone else's system when you join a company and that was about 20 years ago and some of these questions are pretty outdated like for example do you use source control so do you use source control in your project yeah that's possibly not like a question that you would ask it interview because they would be like what isn't it too late to ask that so I came up with some questions which I saw are important and the first topic is of course technical details because we're software engineer will laugh talking about that and here I want to put emphasis on something new like how for example the company brings and integrates adopts new project and you new libraries like when I come to the interview I asked them actually how do you do that and I remember that story that was I was a Java developer Java refugee someone told me yeah yes and I came to the interview at around 1:00 Java 8 came out and they introduced this stream API where you can filter map flatmap and do all these cool things on a collection on a stream and that's all immutable probably I was doomed to be Scala developer when I loved that part so I came there and the interviewer gave me a problem some kind of like graph algorithm and I started to solve that and at some point I just asked him I am familiar with the streaming API and it turns out he wasn't so I started to explain him the idea and then I was solving the problem using that API and he was like oh my god I know I know here you need to use filter and that idea that you can pass the function inside function just part in him and he solved the problem himself did he but he saw that and without him and not isn't that because he was involved because we were collaborating and that's something that I think very important during any interview to feel like you're collaborating you were part of that company what do we care right now about would you care about Scala 2:13 did you all adopt its color 2:13 did you move to that why not hahaha it's not easier but if early you think about that like do I support Scala 2:11 we're doing like cross-compile what do i do do I use this like collection a library of what it's called I don't remember but anyway this is one step but would it not about another step did you try to compile your project with Dottie did you look at the other project project that do that and Dottie as early the project the company starts to think about that as easier will be the transition the migration to Dottie right when you come to an interview you want to know like I'm passionate about these things I want to use new features all this new cool stuff new types like union types and all of this from Dottie did you already think about that so my point about interview is that this is two-way process not only you are interviewing but also you are interviewing the company you want to know whether you like their culture or not are you going to be additive to their culture is that the real place where you wanna work another important topic in in my opinion is like development process I know that a lot of people from functional program inside of Scala often struggle with how their performance is measured so you want to know that in advance you want to talk through that with your manager with your team members in advance and I'm personally very anoying candidate I never say yes to an offer until I actually see someone with whom I'm going to work on word on day by day basis like I asked for additional interview for a company so that I could talk to a team member and figure out whether we get along really well or not because I'm really into it I want to make sure that once I'm on board in I want to stay with that company for a longer time I don't want to continue and go through this rounds of interview again and the last thing is education and improvement there are lots of them and I wrote the whole blog post about that but speaking of Education and improvement I wanna point on the thing called personal brand for example when I joined 47° I didn't join the company I didn't join the just random consultancy I joined people because I knew them from community and I knew what they are up to I knew their capabilities I knew what I can learn from them and this is very important to let you people if you are leading a team if you're running a company you should think about like your talents are greatest assets of your company and if your clients know your people then they know what kind of expertise they what kind of things they can do and what expertise they will bring so if you're looking for questions that you can ask as an interviewer I encourage you to check out my blog post because I have over 100 questions there and I usually they're not because when I rolled them I was Java developers they're not specific to Scala or anything but you will grab the idea of how I can build that and I wrote this Paul on Twitter and asked people like how many questions they think is comfortable for them to ask and look at that 14 percent of people do not ask questions at all and okay time of them I probably after giving the start several times I hope to decrease that number and let people people know what they can ask but for a percent this is ridiculous for me they they think it's useless well it's not I bet they don't ask for directions when they are driving like I know my way I know I know and they get confused and 5% 18% ask for five and more questions which is the way to go because one to five questions when you come to Starbucks they ask more questions than one to five like do you want flat white decaf I don't know some kind of syrup all of this and I wanna I remember that vividly when I came to my first interview that was my birthday and for some reason I learned that by heart no no I I wasn't fluent in English so I was just repeating same words staying like hello Olli I today is my birthday I have questions if I look stupid that's just they're not in the list all of that was hard accident and wrong intonation but I did get a job so I just want to point out how questions can make you more successful just it's very simple idea just ask more but it's really powerful so let's turn it around and talk about questions as an interviewer so Joel Spolsky again said do whatever you want but make the candidate wrote some code because this is their production well you read how they can write a code and this is not technical talk so I'm not going to talk about technical questions although I think that every project should tailor the questions to the ever every company should tailor questions to the project and do not ask like a lot of generic questions but be specific to what your company or what your project has at the moment don'ts so this is a tricky question let's vote on that so we have a function and we have another function inside and with printing value so let's think for a bit and try to shout the answer so 3 2 1 I cannot hear you this is easy 3 2 1 is that confusing it's Scala puzzler it's from Scala puzzlers book and to be honest I do not think that this is a good question for an interview because it's really confusing and if you're not the correct answer is B but that's okay if you don't know that because if you are doing functional program you probably have no idea not even functional programming but if your skull developer you and you never had experience with jelly you probably don't even use richer than ever and you have no idea what it does so that's okay also it's not D because by default it ignores unreachable code but if you were really into it and always use Rob Norris flags then it would fail so I wanted just to show that questions should be should show you something you should learn something about candidate instead of just show them how smart questions can be and yes this this is this is the most tricky question as a in as a podcaster I tend to ask a lot of questions like I ask questions all the time I ask my guests about their experience and I do interviews as well and I never ask people seriously tell me about yourself because usually I do have some kind of CV and I can read through that and I can ask questions specific to that person instead of like wasting time by and confusing them by such a generic question I encourage people I think we should we should like spend our time a little bit on CV or on like looking at their LinkedIn and whatnot and then that specific question tell me about your like University project I think it looks cool but tell me more another type of question is self-serving question what do you know about our company why did you decide to apply to our company oh well you know I just clicked on that easy apply button in LinkedIn and that's why I'm here or there is this abbreviation func Facebook Amazon Netflix whatever whatever and the I applied just because I think your company's cool yeah I have no idea what you do in your particular project because Amazon is like huge or Microsoft or whatever and what am I supposed to answer when someone asks me question like that were people who are working for startups also somehow I should know about your startup I'm sorry I don't know like really so try not to do that but as hey I want to tell you about our company's top me if you think that you already know all of that and don't go too personal of course I had like such a bizarre experience when someone from startup asked me are you pregnant or are you going to be pregnant because we have deadlines and we can of week not move that so sometimes people ask if I'm married but that's not necessarily malicious what they actually mean that the company is family-friendly and you can always bring +1 to our like team-building events but let's put that that way don't ask two personal questions if you want to say hey we have like football team board games team and everything just put it there and don't ask people are you interested in any sports well III don't follow anything I I don't know that's my like playing with Mona's count as a sport maybe it's not let's talk about positive things so Voltaire said judge a man by his questions rather than his answers what that made me think that probably is the interviewer I want to ask a question which will result in a question I also do talks about three cars and schemes so that probably affected me and I tend to ask questions that result in question and in questions and so on so this is one of the examples like you just gather information whether they understand or not the requirements for this position as them which would you ask if you were interviewing someone for that so say I'm interviewing now your interview or what would you ask and that can be they that can show their passion and also how well they feed if someone who does compiler and things who's fascinated about that come to a place where they are going to be build like web application do this I'll create update database request probably they will not be too happy and they're over skilled for that you need to learn that in advance right were if that a new great new Grady just recently graduated someone and they didn't have particular experience in the like hands-on and the project in enterprise but you still want to learn about them how what questions should I ask - sure - let me show your potential fully and that can result in really interested in discussions and I had some of them I had someone who came from bioinformatics environment and they talked like they got so passionate and they were talking a lot about different things and different researchers and I would never probably learned that if I didn't ask that question and also that showed me that the person is definitely into learning and that could be a great opportunity if we could have them on our project or you can gather feedback what questions from the one that I asked you where the good one and why or going back to technical discussions you can give them a stack trace lock statement and so for example they spend some time on investigate on investigation and they still couldn't figure out what's going on and you just give them a cold simple and stuck trace and let them ask question on Stack Overflow and you want to make sure that that question makes sense which will show you when you are collaborating with the person that their ability to explain things briefly first and second that they ask that in a secure way like they removed all password if you happen to have them in stock statement now hopefully that doesn't happen but still and that they removed all like package names or company name if you don't want to expose that and also when you ask how many of you actually asked questions on Stack Overflow or Deiter ever yeah a lesson that doesn't have but that's that my experience is that when I ask the question sometimes I try to reduce the number of lines so that it would be like minimal reproducible come sample and then oh my god this is this is three lines and now I can put everything in my hand and all of a sudden I know the answer already right so this is the power of questions you can answer them yourself if you ask the correct questions the right question so but we're here at the conference and we do networking and collaboration here and I want to talk about like a few things that I think are important in the process in any company the first one is the feedback and that happens when you write when you're participating PR reviews architectural discussions design meetings and all of this how are we doing on time by the way okay so let's rock let's rub this up like really quickly so how do you feel when you join a new company probably less confident than when you spend like five years there already right and I wanted to talk about my friend and I decided to name her Dorothy because the nickname is dotty so and she's a Python developer so dirty Python sorry developer came to her a new job she got the offer from a company and she needed to build a pipeline for some kind of data analysis and she needed to choose an assembler and she went to wear a fancy university and she liked it was led by a Nobel Prize winner so all people were cool and they were building their own assembler and she was like oh gosh I need to use that right and she used that created the PR and her team leader said you should use different one and like the name whatever you should use X and she was like okay and she started to rebuild her PR was that ax and then she was like having trouble not really understanding why she should do that then she gained enough courage to ask like why did we do that and it turns out that this is for historical reasons because they always use that X and they never actually considered anything else and she figured that this is this is wrong this is not how you give a feedback you it's not even feedback problem it's how you approach the profit creating something right you need to know what are you building and why I building this why behind is very important like I need to use assembler why I'm why I need to use assembler acts historical reasons probably not the best one but anyway she admitted that she did a mistake - she went to preferential like she was like I went to fancy University and I chose that assembler and that's she didn't think about like the result or metrics that would show that that assembler is the best choice that was complete preferential because I like that people I know them personally I can rely they have high standard standards and everything but I have nothing to do about the goals of their project and my project and how they fit each other but I like them so I'll leave that can be negative - don't use this library I don't like their maintainer he's too controversial whatever and this is actually not only unhelpful because it does nothing to achieve the result but also it's toxic because if you're in a position of approval your team consciously or subconsciously tries to follow your preferences and tries to satisfy them even if it's in conflict with the goal of the project right incomplete use ax instead was not right to you because it didn't show why behind that or some terrible story when someone would tell you this is terrible and you're like why I honestly don't know right or like when someone tries to just promote themselves and hope and show how smart and superiors there are and bring attention to themselves that's also not only not always malicious it's just someone's style but if you keep in mind what you've seen and why behind that if you were reacting on something like oh my god this is terrible you should like what I usually do I just take ten minutes and I think why I'm reacting like that why that seems to me like super cool because I'm not focusing only on the bad things necessarily on a good things too why is it cool how I can make art I've seen is a school at this one so reactive critique is bad no matter if it's good or if it's positive or negative you still need to have a reasoning behind it and yep the correct way in my opinion is to lead with the question to ask as many questions as you can do to show people that you care also not only about the theme that they are building but the thinking behind it you want to show that you're actually interested in that person like how their mind work on that particular task or problem how they solve that what constraints or influencers they had there and I actually used that with our clients because I'm going to different companies and do architectural reviews and I ask a lot of questions like this because I need to collaborate I need to stay positive so unfortunately we don't have more time to talk about other things I have a lot of stories about like analysis and cos and 5y techniques and whatnot and this is a beautiful story of how I panicked and pushed back into production and how I thought that I worked at Expedia that they would send me back to Siberia by booking ticket on Expedia calm and that's actually the reason do not use enumerations ever but anyway that the framework ask five wise probably have heard about that another interesting thing is a retrospective like three simple questions but that may can make a huge difference at an attitude and team building when you do like you don't have to necessarily analyze things when something went wrong you can do that on a regular basis and just create a questioning culture to your company made it so that people would feel comfortable to ask questions at interviews whether it's interview we weren't interview were at regular meetings at correction of errors and root cause analysis meetings so thank you I won't have thank you very much LD yeah so unfortunately we've run out of time for questions so hopefully you can take it offline and find maybe the full presentation in another medium okay thank you [Applause] [Music]