 Our next speaker will be Amar and Amar she would tell us something very very important which is hello so yeah she's going to tell us about hiring yes yeah hello everyone um I hope you're enjoying your about your python so far and now it's time for hiring the mystified before we start please allow me to introduce myself my name is Mara Bartolome nice to meet you all and as you can see I know my way around pythons but aside from real snakes I've been working as a software engineer for more than a decade mostly doing web development in startups in Malagan London and I currently work as a remote freelancer but in the later years of my career I also got involved in engineering and hiding so today I'm here to tell you all I've learned after tons of trial and error and it all started when I was working at a very small startup and at some point we needed to grow the team but none of us had much idea how to do it but we've all experienced doses of interviews as candidates so we knew the drill so we just started imitating what everyone else was doing and we put together a little process which was we sent a take home project for the candidate to do at their own pace and then upon a satisfactory review we would invite the candidate over for an actual interview but it was harder than expected we started finding candidates and the solutions that we got back from the take home project were quite bad in most cases people made it to the interview and the most the the hires that we managed to do were very junior and we had to make use of expensive contractors to fill our development needs temporarily and one day we made a big mistake and invited a candidate over for an interview even when his take home project was a disaster but surprisingly when he came over and had the actual interview he was pretty okay I even recommended hiring him and that moment was when I started questioning everything our hiring practices actually rational do they work or are we just mindlessly following a cargo quote the situation reminds me of these experiments with monkeys and a ladder and it goes like this some scientists put a set of five monkeys on a cage and then when they attempt to get a banana on top of some stairs the scientists spray them with some water so they learn not to touch those bananas but then the scientists replace one of the monkeys with a new monkey which tries to climb for the bananas but the other monkeys knows what's coming so they kick the new monkey down and eventually they replace all the original monkeys by new monkeys and they all learn the same behavior of not letting anyone climb for the bananas but none of them is actually aware of the reason and I think the same thing has happened to engineering hiring we're all following the same rituals without questioning why when you ask people however most will give you some reasons for example they will tell you we test people because we want to hire the best and so they see testing as an ordeal that mortals have to pass in order to prove themselves worthy of joining the ranks but you know what that reminds me of have you ever seen this show it's like a very hard obstacle course that people need to complete in order to prove themselves the ultimate ninja warrior and every single participant on it looks like they could start an action movie and yet most of them fail along the way because it's so easy to make a slip so there's a huge luck factor involved I think engineering hiring has turned into the same thing or hiring process is so complex that for no reason other than luck you may slip and that's okay for TV entertainment but I really think it's not the best strategy in real life but of course the cool followers have a good reason for this as well they will tell you yes we know we're throwing away tons of good candidates but it's the price to pay to avoid false positives and by false positive they mean someone who might look good on paper but on reality is not and people are so terrified at making a mistake when hiring that they think a very complex hiring process will filter those out for sure and it's a reassuring thought but unfortunately I think it's incredibly naive too because we're humans and if there's something sure about humans is that we'll make mistakes no matter what and here's another fact about humans we're multifaceted and not just mindless coding machines and that's actually great because we come with a lot of soft skills that really make a difference when it comes to be the best at work but a different set of soft skills however will make people shine at interviews even when you're not explicitly testing for them there is of course some overlap with the two sets of skills and this is the reason our testing kind of works often people who are good at interviews are smart and smart people are often good developers too different hiring processes might make the overlap be better or worse but be aware that it will be impossible to have a perfect match of the two circles but it works for google I hear people say and I really can't argue with that because after all it's the giant tech companies of Silicon Valley who actually invented and popularized the hiring practices that we all now blindly follow and we follow because they are our gods and we want to be like them but what works for them doesn't necessarily work for you because you're likely very different kinds of companies for example these companies have an oversupply of candidates coming to their doors and they need to actually filter most of them out I'm pretty sure that many of you listening to this talk have applied to a big tech company at some point I have at least these tech giants are also loaded they have tons of money employees and resources that they can dedicate to hiring without making a dent in the rest of the business and I very much doubt that this is the case for your company and they have also specialized in hunting for a very specific type of candidate a fresh graduate from an elite U.S. university their hiring process is designed to be very excellent like an algorithm focused because this is what the kids at uni feel comfortable with but even for them the process is not perfect this is a tweet from the creator of homebrew the package manager for macOS every developer with a mac is using his software including most google employees so I am pretty sure that google would want him on their ranks and yet when he tried to interview there he failed and personally I think that's google's loss okay so then what what is the best way to do hiring I would say like with the most complex things there's no one true way to do it after all different companies have different needs and different candidates also respond differently to different processes the key I think is balance a good hiring process should strike a good balance between effort invested and quality of hires I'm not saying that all of our practices are bad but applying them mindlessly and discarding most candidates is really wasteful both for the company some for the candidates themselves your company is likely not sitting on a mountain of gold like google is so you need to be smarter and more efficient if we want to hire efficiently we need to be realistic about both our company needs and the characteristics of the developer market out there like I said before not all companies have the same needs and not all developers are hired equally for example most companies really want to get a hold of senior developers and for a good reason because they are the best bank for your buck but guess what they are also more difficult to hire there's less supply of them and more demand so you're going to have a hard time snatching them and you can make it even harder if you make them go through a difficult and long hiring process but the good news is that perhaps you don't need that many of them most companies do well with a small amount of mentors and then a bigger amount of horsepower and that's where mid-level developers shine people with some experience which know how to code and can work with minimal supervisions but they are more abundant and easier to hire and then there's juniors they are cheap and easy to hire but no matter how smart they are they at least some amount of supervision and guidance so I don't recommend making them the bulk of your workforce in the long run however they can be a valuable investment if you manage to keep them with you and set them on a progression path after you figure out some realistic needs the next step is to adapt your process accordingly testing is like clothes it works better when it's tailored to fit different kind of people if you do a one size fits all the same test for everybody you're only going to get one type of person and what we want instead it's a healthy balance for example it's okay for a junior straight out of uni to pair and implementing a simple algorithm they often come with no experience at all and you want to make sure they at least know the very basis of coding but for seniors on the other hand you want to keep testing to the minimum possible in order not to scare them off if you must I feel it's okay to discuss about higher-level topics regarding architecture or text stats and some whiteboarding in this context is also acceptable but algorithms or quiz questions or take-home projects I find are even insulting at this level they make you look like you don't trust that the candidate is experienced and for those in between you could mix and match several tactics but always keeping them sensible something that we always should keep in mind is that hiring goes both ways you're not just selecting people people are also selecting you so the higher you go up the seniority ladder the more you need to relax the relax the friction and switch from a buying mindset to a selling mindset it can be okay for a junior to have to prove that they are worth your time but for seniors it's the other way around you need to prove to them that your company is worth their time so don't waste their time and at every stage I think it's important to proceed with respect and trust for the applicant and try to keep the process as relaxed and pleasant as possible in this aspect I like to consider hiring less similar to an exam and more similar to dating the point is not for people to prove their knowledge or their intelligence in a formal way the point is for both the candidate and the company to get to know each other a bit better before they embark on a longer term relationship an exam makes you nervous and alert whereas a date is pleasant and relaxed and I believe hiring should be like this too an exam is unilateral one party makes all the rules and decides all the results on a date both parties participate equally and as we've seen hiring goes both ways a date is also informal and imperfect you can't expect it will give you a full picture of the personality of the other person just a feeling with hiring you really can't expect more than this either no matter the process that you're following another way to put it we're all about agile in software development right well I think the same agile principles can be applied to hiring almost word by word we should value individuals on interactions over an inflexible hiring process responding to change over following a plan collaborating with the candidate over one-sided approaches and always remember that no matter how much testing you do the only real way of knowing how someone is going to work is actually working with them we should value making candidates into workers as soon as possible over comprehensive testing okay so far I've given you some general guidelines but I think you could do with something more specific so during the rest of the conference we're going to be looking at recipes from mars tech hiring cookbook where we will go over some well-known techniques and discuss their appropriate usages let's start with job postings since they are the very first step in the hiring process and an extremely important one since a job posting is going to determine the pipeline of candidates that you get so you want to craft it with care most people write job specs that honestly read like a letter to santa they describe the most perfect candidate that they can think of it must be super experience and know all the technologies we run in the house and then some more and leave and breathe code blah blah blah and then they cry when only overconfident juniors apply look at this one for example let's see what exactly is wrong with it well first it's very unrealistic while too specific at the same time I mean 10 years of experience with python 3 has it even been around that long and then a long list of buzzwords and also knowing about ops and front and to really very few people are going to be a perfect match for this if we get any applicants they are going to be just the confident ones among the partial matches and on top of that it's written in a someone immature manner it has a nonsensical job title it's bragging about the startup being a disruptive unicorn with a last team and using terms like web scale what does that even mean when an offer looks like it's written by kids only kids are going to apply to it and lastly it's a bit opaque it asks too much from the candidate but tells us very little about the company compare that with this reworked version I now explicitly separated a description of the company stuck in the first paragraph versus the minimum requirements in the second one by doing so the requirements are now much more realistic while at the same time the spec is a lot more revealing for the candidate too and giving them a hint of what kind of systems they are going to be working around even if they turn out not to be involved with some of them like the ops or the front end we're doing two-way communication even when we're not directly talking to anyone we're not just asking we're also telling me my requirements are now not only realistic I made them as broad as possible in order to cast a wide net and not miss out on candidates I'm not asking for specifics such as python 3 or Django I'm just okay with people knowing any version of python and what development on any framework I also removed all the nonsensical language so that the offer looks a bit more serious and written by adults it doesn't need to be super formal it's clear that it's still for a startup and I'm still requiring people to be comfortable in a fast-paced environment but I can do so while talking like a normal person I'm also including a clear salary ban this is beneficial for everyone being explicit about salary from the very start saves time and effort to both parties and denotes trust and transparency from the company side after we get some candidates from the pipeline it's time to test them and the first thing that companies always think of is algorithms you know traversing trees and graphs list sorting prime numbers etc companies love testing with algorithms because they are the perfect exam material small contain easy to review and grade there's even platforms that you can subscribe to that automate the whole process for you but on the other hand candidates usually hate them because they are very detached from regular engineering work and are often too abstract or difficult to reason about the only way to get better at them is by doing explicit practice as a hiring tool I think they are okay for testing juniors especially if they come fresh from university and have no other coding experience algorithms is what they are going to feel more familiar and uncomfortable with but once people have some real coding experience there are better ways to test them I'd rather pair with the candidate so I can clarify concepts or answer questions or simply just give some reassurance rather than leave them along with the problem when pairing you can also see the thought process of the candidate which might make sense even if they fail to complete the exercise the worst are in my opinion the automated test platforms they are very cold and frustrating for candidates the tight timing makes people nervous and they usually give you very little feedback or no feedback at all when you get the solution wrong I would not use them in any case I prefer doing them on a laptop rather than on a whiteboard and I consider it's totally okay to let people google stuff like if they need to check on some syntax or library functions when you pair with them it's trivial to control what's fair googling material as an alternative to abstract algorithms for hiring juniors I prefer to use simpler programs that are easier to reason about for example a calculator or fifth boss rather than a binary tree inversion the goal in the end is not to test the intelligence of the candidate or if it can come up with clever solutions the goal is to see if the candidate in this case a junior is familiar enough with the basic building blocks of coding so we will not have to teach those on the job and then for candidates with a bit more experience take home projects are another popular hands-off hiring tactic we send the candidate the spec of a bigger project for them to solve at home at their own pace for example build a Django app that implements a to-do list or a tic-tac-toe game API with persistence they have some advantages over algorithms for starts they are more similar to actual development work so they are easier to reason about for candidates since there's no time pressure or a person looking over your shoulder they make people less nervous introvert people in particular prefer this type of testing over others since they are a bit more complex they can also give you a closer feeling of the applicant coding abilities however if you're going to use them it's important to craft them with care since they are very detached it's easy to lose the two-way communication that you want from any test and then the test might become a total pain for both sides first and most important be aware of the scope i think it's unfair to require too much of the candidates time if they're looking for a job they're not just testing for your company but for others as well and it's probable that they are also working their full-time job or perhaps they need the time to go to the gym or take care of kids free time is a luxury that not many people have so be sensible if you're not you're going to lose the candidates who lack the time and those are usually the best and more experienced ones a sensible scope would perhaps be an hour or two however be aware that it's very easy to underestimate the time that it takes to complete for example i don't start a blank yungo project every day so simply having to go through the docs to remember how to set it up and then installing a database and a virtual them and the github reboot it might take me as much as an hour just for that i strongly recommend that you eat your own dog food and use a test the challenge with yourself and other company team members first see how long it takes them to complete it and identify any points that they find frustrating or confusing and then adapt accordingly try to do your best efforts to keep the two-sided communication even when the test is asynchronous be extremely clear with the spec and requirements for example don't just say implement blackjack and assume people know the rules because there are also many variants describe the rules in your spec over communicating is preferable to the alternative reviewing can also be tricky since unlike a parent exercise you're not aware of the thought process of the candidate i find the review so much easier and fairer to do when you have the candidates feedback to explain their approach and decisions this could be done at a follow-up interview or via github review comments the best way to do a take home project in my opinion is to craft a stop with a partially created application where the candidate just needs to fill in the blanks for example add a new feature or fix some intentionally placed books this way you take most of the ground work from them and the homework becomes much more contained it's also valuable to see how people adapt to an existing code base which is exactly what they are going to be doing if they join your company it's becoming popular for companies to attempt to make their testing more similar to reality by giving candidates a real-world problem rather than just a toy exercise it's this approach can work with any type of challenge you can do it on a parent exercise or on a take home problem or even whiteboarding it can be effective when used right but it's also easy to go wrong with it the most important thing to be aware of is asymmetry especially if you're picking a problem from your own company you have tons more context on it than the candidate so it's normal for the candidate to be a bit clueless and need extra guidance from your part if communication during the test is asynchronous like on a take home project it can further accentuate the asymmetry a test I like for example is picking a simple ticket from your real backlog and then pair on it with the candidate for an hour even if you have to leave the ticket unfinished what um yeah you have to provide the candidate with a machine already set up with the necessary environment so you can go straight to coding a problem I really dislike uh on the opposite hand is picking your company's hardest problem and then letting the candidate figure out a solution it's extremely unfair even when pairing with the candidate the context asymmetry is abysmal you've had plenty of time and a full team of engineers to reach a solution while the candidate has to come up with something on the spot out of the blue so few candidates will have satisfactory answers and now face-to-face interviewing which I think is hands down the minimum viable interview all other challenges are optional and arguably they can even be counterproductive but you always need a face-to-face tool you can do it on site or you can do it on video conference but you need to do it for every type of candidate think about it in most other industries this is the only interviewing they do and they're fine remember when we said that hiring should be more like dating and less like exams well a face-to-face interview is the more deity and less ex-me of the hiring tactics so in my opinion is the one that gives the best results with minimal effort during a face-to-face I prefer to discuss open-ended opinions rather than doing quiz questions where you expect a right or wrong answer for example you could compare the text tags at your company and the candidate's previous company and discuss the pros and cons of any differences you could also ask for preferences and opinions on any topic around tech that the candidate is familiar with like the Python language itself or preferences in ecosystem tools or what do they think about testing or code reviews or git branching etc if they did any prior test challenges like a take-home project you could discuss or review those here you could ask them what they think about the challenge why did they choose that approach for solving or even if there was any pain points that they would change and this also serves as very useful feedback to adapt your testing and if they have any personal side projects you can ask them to tell you more about it in short just keep an informal discussion on geeky topics even when the chat is very unstructured like this it's normally easy to tell how knowledgeable and experienced the candidate is from their answers compare these two explicitly asking quiz questions like for example what's the difference between str and unicode or what happens when you enter a url on a browser or how does a garbage collector work quiz questions like this have the disadvantage of making people nervous and alert even when they know the answer and we want to avoid this also unless they are very universal it's easy to pick questions about a topic that is too low level or too specific and then the candidate hasn't been in touch with it in a long time and they don't know the answer on the spot but if they were working they could easily figure it out by googling a very important point with face to face is to try to make the candidate as comfortable and relaxed as possible there's a relatively high share of introverts or people with no confidence among developers and they usually get nervous and blank out during in-person interviewing this makes them look like bad candidates when in reality they are not and because of that they are usually overlooked by other companies so there's good hidden gems there and you really don't want to miss out on these candidates some tactics for making people relax are for example to explicitly reassure them that there are no right or wrong answers to try to make it a dialogue more than an interview try to talk and share as much as they do because when you open up it will motivate them to share too also pick icebreaker questions or topics where it's easy to come up with a response but then let the conversation flow to different places for example a question like what stack are you currently using has a very clear and immediate answer but then lots of opinionated discussion can follow whereas something like what was your greatest achievement in your last company totally blanks people out like we've seen before testing no matter how well designed is always imperfect because of the mismatch of the soft skills that make you proficient at testing versus working on a team and as such the best way to test people is by definition to directly put them on the same job that they would be doing when hired like a try before you buy this kind of testing also goes both ways the candidate gets a feeling of what it's like to work at the company the problem is takes testing like this is a lot more involved than other methods for both parties so it's obviously not scalable to apply to every candidate that comes into your pipeline but combined with a good face-to-face interview you could use it instead of an extensive process of coding challenges it works particularly well for senior people who can quickly demonstrate productivity once at work but have low tolerance for coding challenges this also aligns with our agile hiring principle working people over comprehensive testing there are several ways to do it and in fact you probably are already doing it without realizing it if in your company you do a probation period for new hires then you are effectively testing them on the job a probation period is a period of a few months where either party the company or the worker has the right to finish the contract without any notice of consequence some companies go a bit more explicit and offer instead a short paid contract of a week or two before offering a definitive hire this is a lower compromise level than the notice period but it might not work for everyone for example it's not acceptable for a candidate who is still working a full-time job at a different company as they won't have the time to spare plus their current contract might limit them to legally be working elsewhere the lighter option which might suit these candidates is to do a full day at the office instead this requires the candidate to take a day off their current workplace but in return they get to experience firsthand what working at your company feels like they get to know the team and they get a glimpse at the project that they will be working on some candidates value this a lot as a company however you don't get such a high return as you would expect because you can't expect people to be productive or show their full potential in a single day if you do this kind of test it will help to have a fast and ambitious and efficient onboarding process or provide the candidate with a pre-setup laptop and environment so they can get direct to coding and of course they will need full guidance and pairing from a team member along the full day remember though different candidates have different preferences some people loathe tech challenges and would take the short contract instead of testing anytime even if it means leaving their current job others however might not be able to afford it in time and money and would like more traditional testing instead i really like it when the company lets the candidate choose we can do a technical challenge or a short contract your call sometimes there comes a candidate to your pipeline with tons to show they may be regular open source contributors or have pet projects or keep a blog or podcast or do conference talks when this is the case it's you who need to do the homework and not them they are already giving you a lot of stuff to review so don't ask them for more no need to give them any more challenges they're also often great candidates so don't scare them off when someone comes with their own material like this it's a great chance to use it as a topic for discussion during the face-to-face interview people are usually very excited to talk about their personal projects as an exercise you could even ask them to show you around the code of one of their projects which is an easy way to review not just the way they code but also how they communicate and for our last recipe everyone's biggest threat what can we do if we get a bad hire remember as I said before you will get them from time to time no matter the process that you're using but don't panic failing is a part of life too and it doesn't necessarily need to be a drama for everyone's interests try to act as soon as possible when you identify a bad hire I don't mean kicking someone out on their second day at the latest suspicion but once you're sure things are not working out act sooner rather than later because the sooner you act the less painfully will be for everyone the first course of action in the case of minor problems is to give some feedback and a warning to the person along with a second chance to improve any issues but however sometimes there's no other way than to let the candidate go no one likes firing people it's a tense and violent situation and a huge setback for both sides who have to go back into looking for a new job or a new candidate however there are ways to make the process a bit smoother and park with the fire person in good ways it's important to always give honest feedback even when the feedback is harsh there's nothing more frustrating than being let go and not knowing why and you can also try to help with impossible to mend the fabric of reality you gave the candidate a job and now are taking it away so in order to restore the balance of the universe why not help them in finding a new one for example you could give the five person a small economic compensation say a week or a month of salary to help them pay the bills while they'll search for a new role but you could even go as far as helping them find the job for example by circulating them across your network if you think that they could fit well on a team different than yours even when you account for all the costs of a bad hire if you keep them just for a short time the cost is definitely cheaper than the search for a perfect hire doing a long time consider that you're saving the time invested in hiring by your team members the money spent on recruiters and temporary contractors and all of the features that are piling in your backlog with no one to do them so don't be afraid to fail but when you do try to fail fast and we're reaching the end of the presentation now but before we go let me give you some final tips on the overall hiring process I think the process should have as few steps as possible I insist even if you do just a face to face interview that's fine that's the minimum viable testing but don't do two or three different coding challenges there's no point consider this other companies are hunting for the same candidates as you and the company that offers first has an edge over the rest companies with a long and difficult process really are that is a bandage it also helps to keep the process flexible like we've seen not all tactics are effective with every type of candidate and some candidates require a bit more testing than others those who are less experienced in particular you can't have a process template but don't be afraid to bend it for every candidate you could give them choices like testing versus a short contract or pairing exercise versus a take home project so they can choose what they feel more comfortable with or skip the testing when they have public code that you can review also don't be afraid to run experiments and a test alterations to your process to see what works best and always keep it collaborative remember that the candidate is selecting you as much as you are selecting them keep it pleasant and relax and maintain the two-sided communication at all times remember the mantra date rather than XM and finally don't be afraid to make mistakes it's more realistic to be fault tolerant than to be failed proof we've seen that making mistakes doesn't have to be a drama and it's definitely better than the alternative in short just make your process as agile as possible and that's it thank you all very much for listening making all of this possible it's been a pleasure for me yeah go ahead QQ thank you so much and I really love the picture when you are taking the picture with the python a real python that's amazing so actually there's a few questions I can see in the chat because this is such a good talk one second let me hold back into the chat yeah so um there are questions about uh the oops sorry my computer is playing up now okay so uh okay do you know any company who does pair programming with the real world problem during their hiring process so I think I never experienced it but it's definitely doable like when I used to be the one training newcomers when when they when they were recent hires in the company and the first thing that I did was having a set of simple tickets that I would have prepared for for them to do on on their first day and I think like something like this could be could be adapted to to be done during hiring as well why not and I do know some companies that that that do the the full day at the job which is a similar thing they would they would show you a real ticket to do during that day so it's the same thing it's just a matter of time boxing it's one hour versus doing it during during a whole day yeah so actually I have the same idea I prefer pair programming in in the hiring process than a challenge especially like those challenge that you can find you know some company do that it's some questions from the textbook and something I think is very helpful so what's your opinion about about those like those you know coding challenges do you think is a good idea um what what calling challenges exactly because there are many types like there's like these platforms that do like math type algorithms and I think I think those are terrible like like I said on the talk especially when they are on an automated platform because it's just so cold it's it's just you versus a machine and the feedback that you get is terrible the problem itself is very difficult to reason about and it's so detached from reality it's it's really you could get the same results by throwing a dice and saying okay this candy they go song and this one doesn't because it's it's very much there's a huge lack factor involved as I said but what about uh you know coding challenge but you know you are online with the candidate so they have to do it in front of you like what do you think about like is there more human touch in that okay yeah I think that's that's equivalent to pairing like it's it's a remote equivalent to to fairings instead of doing it on the two of you on a laptop you two are connected and doing it at the same time I think what is important is just to be there and reassure and guide the kind the candidate will also uh keeping an eye on on their thought process and on how they approach the problem I think this is the the the most efficient way to to do it yeah I remember one time I was interviewing and actually was told to uh write on the whiteboard instead of just code which which is very good but I think now COVID that's the best thing you can get is to you know online be with the candidate uh I think that's a really good idea and it's like yes thank you so much for the talk and it's really really interesting to see like how you know uh because because most people they they don't put too much thought in it and it's a very important thing even myself like when we started interviewing you just start doing what everyone else does without thinking and really if you think a little about the implications you can make it much more efficient for everyone yeah and it's good for the company as well for the whole team because you want to get someone you can work with rather than someone that you are struggling to you know it may not be a good fit for the team yeah that's really good so uh thank you so much I think uh yeah I think everybody is saying is an excellent talk and there's no more questions as far as I know but if people want to keep on discussing about this uh important topic of course the breakout room is open and um yeah so thank you so much and hope you enjoy the rest of the conference yeah same voice yeah thank you and now I think we are having a coffee break excellent