 Hello and welcome to nailing your next open-stack job interview Your presenters today are Brad PCORI who is a principal software engineer at Symantec and for the past few years He's been focusing on Horizon. I am Tim Symanzic Also a principal software engineer at Symantec and for the past few months. I've been focused on glance So what we're going to cover is what the current hiring situation is how to get yourself noticed typical interviews things specific to ops interviews things specific to dev interviews and Finally, we'll try to give you some tips to help you make the right decision once you actually have the offer So what is the current hiring situation? At least for the US here's the unemployment stats for the IT industry straight from the Department of Labor statistics You can see in 2002 that when the first tech bubble popped you can see around to 2010 I guess that's the financial crisis, but right now. We're not doing too bad. It's been better It's been worse But if you work for a big company or you know someone who works for a big company then you know that the layoffs never stop and The best time to find a new job is when you already have a job and there's two reasons for that one it gives you the luxury of time so that you can really find a good fit and make the right decision and Two it gets you a much stronger Negotiation position if you're already employed now to speak specifically about OpenStack. I'll turn it over to Brad Thanks, Tim so how is hiring changed for OpenStack jobs over the years as most of you know OpenStack is a fairly new technology and Until about 2014 those were great years There was lots of expansion in OpenStack companies were sending new hires directly to Paris when they started and if you could spell Dev stack you could have a job Now after about 2014 Things have tightened up a little more in the end. Everyone is trying to make money off of OpenStack and so There's more of a focus right now on contributing to OpenStack only if the company gets something out of it or only if it makes financial sense and So that's the bad news But OpenStack knowledge is still highly in demand So next let's talk about how to get noticed in the first place And I'll cover the obvious stuff first So you've all probably you know these websites, you know how to use them I won't waste your time with them but if you're not using them get on them and they're a valuable part of a job search and Particularly in the world of open source there are great opportunities For showcasing your work around the world while you're doing your day job Everything is done out in the open. So lots of people outside your current company can see what you're doing and Specific to developers if your primary job is upstream development You should be doing reviews regularly and this is because the hiring managers and the people who know how open open OpenStack community works know that the upstream developers who really get things done are doing lots of quality reviews And so that makes things move along a lot faster for them So notice I put code commits secondary on this list always important, but still not as important as reviews and Even if you're a developer who's just developing code internally so your code is not out in the open in public Still public documentation and blogs about what you've done are very helpful And then of course being a core or a ptl comes with the recognition that you know what you're doing So for operators The situation is nearly the same The various upstream automation projects like puppet chef and Ansible all need ongoing Contributions to stay up to date as OpenStack evolves And so those are a good way to contribute as an operator and blog posts on common operational techniques are very useful Particularly in the areas where there are common operational problems that need preventing So issues with rabbit Preventing file systems from filling up maintaining LDAP and security And the need for operators to review code and docs is also high As you know, there are lots of developers pushing code into OpenStack and many times They're breaking stuff that operators depend on and so if you're an operator Who's doing good reviews on code and preventing those issues from getting merged into the code base That's going to be noticed and that's highly useful It's also good to keep in mind what companies need and what's most valuable at the moment So most corporations using OpenStack are either selling it as vendors or they're running it internally as operators And so for those that are vendors, they need people who can contribute to the product For example, IBM Sells the whole hardware software stack including OpenStack to run in a customer environment And so they're looking for people who need engineers to write any new features upstream that they're going to need for the product Then on the operator side Lots of companies need help building and operating clouds. So it's very common that I'll be talking to someone in the tech industry and Even though they don't work on something specific to OpenStack They'll mention that they they use OpenStack internally for some environment So small companies medium companies at every level people are using OpenStack for these various environments And all those environments need ongoing maintenance Hybrid cloud is also very big lately and this means different things to different people But it's either about running OpenStack as a public and a private cloud and connecting those together Or about connecting OpenStack to other public cloud providers Not many companies just run only OpenStack And it's it's much more common that they use OpenStack for some environments and then AWS or some other public cloud provider for other environments And in those situations there are both development and operations jobs for connecting those clouds together in seamless ways For example, even rack space at this point is in the AWS game while they're still working on OpenStack as well and so next I'd like to do a little activity and Please put your hands up if you got your last job by applying specifically to that job on a website so just a few out there and What I've found in my career is that the probability of getting a good job by applying to some public job posting is almost zero We've all done this before applying to specific job postings, but they almost never work out And despite all the job finding technology we have so LinkedIn and Monster and applying on websites Personal connections are still your best bet for getting in the door When you apply on a website your resume goes to some recruiter then on to HR and then if it passes the automated screens Then on to a hiring manager But with a personal connection your resume often goes straight to the hiring manager And then you get that added benefit of the person recommending you as well so next let's go over some typical interviews and In the tech industry The interview processes can vary widely between companies and so at one end of the spectrum is the short interview process With these it's maybe one to two interviews before they make a higher or no higher decision In these your previous work is often a very big deal. They don't have a lot of time to get to know you and So they're looking at what you've done in the past to know if they're a good fit for them right now So if you're a core reviewer, this might be very easy for you to get a job in this situation since they're looking at your work from the past and In this case, maybe only one or two people you need to convince to hire you then on the other end of the spectrum is the marathon interviews and What comes to mind these days is the Fang companies Facebook Amazon Netflix and Google and with these You'll have an HR interview Possibly multiple tech screens and then four to six in-person interviews the same day So in this case what you've done in the past is relatively unimportant They have a lot of time to get to know you and they'll figure out what you're capable of During that interview on the day So one way they do this is by coding on the whiteboard and this is even for operations often times So even for operators, they might have you writing puppet code directly on the whiteboard Cores get the same coding test as everyone else So it's not such a leg up in that case and they often have separate design and behavioral interviews In this case, it's maybe four to six people. You need to convince to hire you so a lot more demanding And in this case They have sort of revolving door interviews where if you're if you're just a maybe at the end of the process They'll probably say no to you But the good thing is that Since these companies know that even if you get rejected in one interview They'll often have you reapply in a year or in a few months and they'll try again so often very easy to get second or third interviews with these companies and If you get an interview and you don't know what to expect from that specific company Glassdoor is a good place to check for it people go and post Actual interview questions that they've had asked of them for these specific companies Also, if you're working with an external recruiter They'll often tell you lots of info about what to expect in the interview the external recruiters are almost Never paid unless you get hired So it's in their best interest to get you hired and they'll often tell you probably more than they should About what to expect in the interview process So let's get into some specifics about ops interviews and We'll do a little hands-on exercise first. So since we're talking about open stack If you have pen and paper, then you can write down what you think on this one Or otherwise just think about how you would answer this in an interview situation So what happens in open stack when you boot a VM from the open stack CLI and Think about the components that get involved the order those components are invoked in the non open stack components to get involved and communication protocols used between them and I'll give you about 30 seconds to think about this before I move on Okay, so how many did you get about 10 or 15? Here's a possible list and When I asked this interview question, these are some of the things I look for One of the things people often forget is getting the keystone token Especially when we're talking about Nova calls people forget that you need that keystone token a very important part of the flow and then I won't go over all these but a Lot of things happen in Nova, of course You can take a look at these after the presentation and then eventually Nova compute uses libvert on the hypervisor to Boot the instance and so then we get outside of open stack And that's again part of the process, but something that that you should be familiar with And the idea here is not to get all the right answers but just to be able to take someone through what happens from end to end and To think about it systematically through the whole process here's another one that I've asked people during interviews and here we've got a screenshot of horizon and in this case there are two instances that have been booted and When those instances were booted, they must have had some image that they were booted with But now the image name is blank when we look at them. So what are some of the situations? where that image name could be blank and This is a good one to see how a person solves a problem. They might not already know the answer to so you might not have seen this exact scenario before But if you know enough about open stack, you can probably reason through some of the things that could have happened So some possibilities Maybe the the policies changed so if they booted the instance and then the glance policy was changed this user may no longer have access to that image But their instance is still running If the image was deleted so again They they booted the instance, but images deleted Instances still running, but the there's there's no longer an image named a display Or if the image was public and has now been made private So they they had access to it and again no longer have access at this point and For ops interviews, you're likely to get some automation and design problems as well So maybe very specific things like write an ansible playbook to install and configure horizon And with this one, they're probably not looking for you to know the exact package names to install But they probably are looking for you to write syntactically correct playbooks in this case and show that you can do that off the bat Maybe more general things like what's the best automation technology to use for open stack so you might answer puppet chef or ansible and Explain why but better yet to explain why some of those are better in some situations and then others are better in other situations And sort of in operations design problem Given budget constraints and business requirements. How would you allocate resources between the various open stack components? so this one requires you to To know enough about open stack to justify why you would make the trade-offs between different components So some critical skills for operators familiarity with at least the big tent open stack projects familiarity with how to maintain rabid mq cupid maybe other queuing systems You always have a queuing system with open stack and always very important to maintain Linux system administration Almost all open stack installations are run on top of Linux and so very important to be able to maintain those systems At least some basic networking knowledge for example, how many usable IPs are there in a slash 28 network? So you might not have the answer memorized but to be able to the reason through how you would calculate what's left And of course if you're in a networking ops person, you'll need very detailed networking knowledge But at least basic networking for everyone Certificate management So again in all open-stack environments, you need to secure the connections between the components And so managing certificates in that environment is very important And one thing I've been asked in terms of certificate management in an interview is why do you sometimes see invalid? Certificate errors when you go to websites so they're looking for if the certificate has expired if it's a self-signed certificate and you don't have the The signer in your t-store But some indication that you know how certificates work and also what their failure modes are So why do you sometimes see errors about them and next I'll turn it back to Tim for dev interviews Thank You Brad So we've already covered a little bit how important the reviews and the commits are but just to highlight it literally Whatever your current job you may have Obligations to do some number of reviews per period some number of commits per period You always have to keep in mind that everything you're doing is going to be in public forever Your next potential company is going to see this so I know Nobody here obviously, but some people enjoy gaming stack elitics with just drive-by plus ones and Your next potential boss is going to be able to see this and that's a bad red flag similarly with commits if every if flipping through your history the only thing we see is Every few months you play with the white space a little bit. That's a horrible sign But the positive signs you're completing blueprints. You're filing resolving bugs or of course if you're a core reviewer and There's actually a lot of resources out there Here's three books that we enjoyed a lot of it is information that we're covering right now But the reason to still pick those up if you're interested is they have a lot of example Coding questions and not just the questions and not just the answers also a reasonable way on how to On how you would come to this conclusion on your own in interview situation similarly sites like hacker rank or leak code that Many good examples of programming questions and the more questions you see the goal isn't to just memorize the Question and spew back the answer the more because you're never going to get the exact same question in a live interview situation But if you've seen enough questions, then you're going to already know How a similar problem was solved and it's going to give you a leg up Usually usually it's good to confirm this but The interviewer wants to see what you really do in your language of choice So for example, presumably most people here are Python developers It's great to apply for a Java job But don't make the mistake of suddenly trying to pick up a new language and cram cram cram Because I don't care how smart you are the code that you're going to demonstrate put on the whiteboard After a few days of crash course in Java is not going to be of the same quality So with no shame at all happily show me show them the Python code and show them what you can really do and This is important. Do not use pseudocode It it's a horrible red flag if if yours try to sell yourself as an experienced accomplished developer and you can't Put up some kind of syntactically plausible Python That's a red flag especially For a lot of into individual interviewers This is going to be the only code of yours that they'll see not everybody's going to go digging through your commit history So make sure it's as close to production quality as possible catch the error cases Like if you're writing a function That opens a file make sure you're catching the error and even better differentiate between why did the File open fail did the file does the file no longer exist or is the file already locked this is Little niceties like that are the difference between an ok interview and a great interview So how did we get here with all the the whiteboard coding if you've been around the industry long enough? You remember that it wasn't always like this it used to be more like any other job interview Or you'd talk about what you did and talk about what the new job would entail but I guess 15 or 10 years ago or so Bill Gates decided that this is the one true way to interview developers and ever since then most people have picked it up so What's interesting is it's not clear that being great at whiteboard coding is directly related to being great at real world coding which is unfortunate, especially if you don't like these style of interviews, but the fact is that This is the way our industry is and we all have to deal with it So one of the biggest mistakes. I see this all the time Whiteboard coding and keyboard coding are not the same and it's whiteboard coding is Skill you need to practice it. Even if you spend eight hours a day every day coding on the keyboard before the interview really try to put yourself in the In a practice whiteboard situation go to a site like hacker rank and Do the problems most interviews are 45 minutes to an hour. So give yourself that artificial time limit Don't use your IDE. It's so easy to forget How much ideas these days can help you out so use the bare bones Interface and maybe pick a question that doesn't seem like fun to you Because it a real interview situation. You don't get to say. Oh, I don't like that question. Let's do something else People have tried and it's a bad red flag So speaking of that Keyboard coding obviously is also a skill and especially as you progress with your career often you the further you get The less coding you do sometimes maybe you're managing people maybe you're managing projects You have other worries and it's so easy To just have this pin in your mind of well, of course, you're a great software coder Well, you were two years ago and now you're forgotten and now it's rusty so Don't just remember how good you used to be practice ahead of time and This is actually one of the answers I've gotten From one of the people who was unfortunately rustier than they thought I asked them a very simple coding question And they came back with oh, that's so easy I'd make an intern do it and unsurprisingly once you you poke a little bit it turns out that He hadn't actually touched a keyboard in five or so years So here's an example of an easy question Write a function that takes a string as input returns the string reversed now very very often with the simpler questions You can do it in one line, especially if you know the library well and I think there's in python There's a reverse function and it's great to know that but the thing is Interviews aren't trivia questions. It isn't it doesn't teach the interviewer anything the fact that you happen to know that the reverse function exists, so don't be surprised and Certainly go along with it when the interviewer asks you to do it the hard way to write out the code because that's what they want to see and When you're testing your code Make sure each one of your test cases actually add something for example If your function takes in an integer have the positive integer have a negative integer have zero have not a number But don't just add a bunch of numbers to say hey look how great my test coverage is because automated testing It is cheap, but it's not free You know that when you do an upstream commit it can take an hour or two for Garrett to come back to you and Some of that is useless test bloat that The individual tests they're they're the rep the repetitious so here's an example of a more difficult question and You should never worry you're Very very often the interviewers are going to collude To make sure they they eventually stump you it's not Interested they don't learn anything about you if it's just easy question easy question easy question So you are going to get a question that you can't do immediately and that was on purpose so that a Good way I'm sorry. I'm very jet lagged a good way to proceed is just start by saying oh, here's the the brute force solution and Further explain why you wouldn't use the brute force solution said doing something like that is much better than standing at the whiteboard in silence One way it gives the opportunity It gives the interviewer the opportunity to actually interact with you see how you would be to work with and It also Opens a window to let the interviewer steer the interview So start out brute brute force solution. Obviously, we wouldn't do it that way then start to think about What data structures might be useful what algorithms, you know and have that conversation think out loud and A key point make sure you're listening to what the interviewer actually Is trying to tell you when you're up there you're in the Middle of writing you have a trade of thought they know that they know that Interrupting you is going to derail your trade of thought a little bit So they're not going to do it for no reason if they point out Are you sure about that? Are you sure you want to do it that way? If you fix it or you change your plan or you don't that's your choice Just make sure that you hear what they're actually telling you and finally here's an example of a time complexity question What's the running time to find a value in a binary search tree? Well, please don't say log in Because it depends on are we talking about a balanced binary search tree and are we talking about the average runtime or the worst case runtime? I don't like the term trick question. This is sort of a trick question But there's no negativity here the point is to see are you going to spot that ambiguity? Are you going to ask for clarifications? Because again They want to see how you're going to be to work with and if you're a type of person who just jumped straight into oh, it's log in Maybe they don't want to be your co-worker and now That you've passed all your interviews. I'd like to pass it back to Brad to talk about how to Make the right decision and as far as making the right decision once you get an offer there are tons of resources out there so you can search Google and read books about How to know the company is a good fit for you and how to negotiate your salary and things like that? So I don't want to waste your time with all the general stuff that you can just go and search online for yourself but For some specific things to open stack Telltale signs that an open stack job is a bad fit for you If they're using open stack in production, but they haven't automated anything then Either when you come in you're going to be doing the automation and maybe that's what you like to do and that's fine But otherwise If they haven't automated anything and they don't plan to they're probably fighting fires all the time in that production environment right now And when you join you're going to be fighting those fires with them and it's it's just not going to be a fun job If open stack is critical critical to their future, but they're laying off open stack people and We all know companies that have done this and it's still going on right now It's unfortunate and it's never a good situation Either for the people who are still there or the people who are hiring in so it's just not a good situation If you want to do upstream development, but they only talk about operations during the interview Then when you get there, you're probably going to do operation stuff with them and not doing the upstream development that you want to and also if the hiring manager can't answer detailed questions about their open stack environment and You have to be careful how you find this stuff out. So when you're asking these detailed things So you don't sound like a jerk in the interview but If they can't answer these things then either the hiring manager is just non-technical or They really don't know what's going on in that environment and either way it's just going to be a bad situation for everyone involved So we've gone through this whole process of how to get noticed for open stack jobs How to get interviews what to expect during interviews and then how to make decisions at the end And so now you're ready to go and get your dream job. Thank you And we have some time so if you if you have a question, please come up to the mic and ask there I see one trend in open stack is like so far core components were getting getting developed But now most of the things are moving towards container. The development is moving toward container. So and I see it's a very dynamic environment because Two three years back. I saw everything was a beginning in open stack and now it's everything is mature So how we should adapt with the community like what we can do so that we can remain relevant in the market Yeah, good question. And so this is it's a challenge just in the tech industry in general just to stay up to date with what's going on and Particularly for open stack at this point. I mentioned a little a few slides back hybrid cloud so everybody's talking about hybrid cloud and how do we hook these things up right now and There's a lot of development To hook things together and make sure we automate things between those clouds But then also operations to set the things up in the first place And so hybrid cloud is one thing and then of course development that's around containers is a big thing as well But as People of the tech industry that's something that we've kind of signed up for to that we constantly have to be learning and Staying up to date with with new things that are going on Good question So the question was to repeat it. So if if your day job is not exactly the latest thing with open stack how do you handle that and One thing would be if if your company is just doing kind of old things that That aren't the the leading edge thing. You're pretty much stuck with just learning those on your own and maybe I'm building your own environment and writing blog posts about it or something like that to show that you know it but to To actually work with it and work out the details on your own is extremely important But otherwise if there are other teams at the company who are doing that more cutting-edge stuff And you want to get into that to really push your manager to get you into there So those are some things that that might help in that case I do a shameless plug in case somebody's looking for an open-stack job working off stream. Look me up What company Lenovo Lenovo Lenovo All right, if there's no more questions, thank you very much for coming. Thank you