Hello, ladies and gentlemen, Welcome to another episode of Adventures and DeVos. Today. I am your acting host, Jonathan Hall, and I have with me absolutely no one. So I'm going to do a solo show, or at least I'm going to try it will be an adventure. I hope you'll join me before the show. As I was staring at my screen trying to decide what I could talk to you about without anybody helping me, I decided I'm going to talk to you about getting a job. The new year is
upon us. That means a lot of companies have new budgets, They've opened new positions. It's a great time for a lot of people to start looking for work, or to continue if you've already started. So I think it's a timely topic. Before I talk about some of my suggestions and advice on how you might go about getting a job, or more to the point, how you might interview for a job and what you might do in that regard, I want to talk about my background so you understand where I'm coming from
and my sort of employment history a little bit. So I have spent most of my career as a software developer. Back in two thousand and six, I applied for a job as a network administrator. Actually, during the job interview, they gave me a whiteboard and a marker and they said, Jonathan, we just bought three news servers and we want to set up our spam email filtering service on these three servers to serve customers in the cloud. Sort
of a sass, how would you do that? And so I drew some squiggly lines between these three boxes that represented servers, and I guess I liked it because I said, great, Jonathan, we want to hire you to come do that for us. So I joined this company as essentially an operations network engineer, but within a couple of months, the lead developer of the project. And it was a small team, there were two or three of
us at the time. Lead developer left the company, so they were looking to replace him, of course, and while they were looking, of course, they still needed some work done. Customer requests came in or bugs needed to be fixed. So I was sort of filling the gap and helping with some of these requests for a while. So after a while of doing that, they decided I was doing a reasonable job and they didn't necessarily need to replace me. So they said, Jonathan, would you be willing to be
our news software developer? And I agreed and we did hire some other help over time, but for a long time I was the lead developer on this project and also the lead networksh only network engineer on this project. So although my career has been mostly software development, it has been with a slant towards back end services, software deployment, network infrastructure, and all of these sorts of things, so very much what we would nowadays called DevOps, although that
term didn't exist at the time. I worked at that company for close to ten years, and since then I've applied it a large number of other companies. I've interviewed it, probably several dozen. I've probably had at least one or two dozen job offers in the last say five years, because I liked you. When possible, have two or three offers on the table and then I can choose the best one. So that's a little bit about my experience as a software engineer as it relates to finding a job. I have also
been on the other side of the table. I have been an engineering manager. I have hired, I have interviewed and hired a large number of developers for multiple companies, and so I also have my own style of interviewing candidates, and that definitely influences the things I'm going to be telling you today. So with that background in mind, let me talk a little bit about what
I like to do to prepare for a job interview as a candidate. And actually, before I talk about what I do to prepare, let me tell you what I don't do to prepare. I see a lot of talk on LinkedIn, on social media book titles about essentially cramming for a job interview.
Cramming is, of course, the idea of learning facts a memory, facts about something about say AWS, or about a programming language, or about network infrastructure or whatever the topic is. Learning these facts so that when they ask you a question, when they say, how do you do X on AWS, you can give them an answer, Or when they say how many bytes or how many bytes in a TCP header or something like that, you have an answer. I don't do that, and I don't think you should either.
I don't think cramming for interviews is a good idea. And let me explain why. First, I believe that an interview is about it really is about or should be about getting to know each other, the company getting to know you and you getting to know the company. And if you are reciting
memorized facts, you're not giving an accurate representation of yourself. And I don't want to get hired based on a false representation of myself because that means that I will have unrealistic expectations on the job, and I'm setting my own self up for failure. So I don't want that. If I know an answer by heart, that's a different thing, because it's not a sort of false
sense of who I am. If somebody asks me how many bites are in a TCP header and I actually know the answer because I've done TCP engineering for so long that I know the answer, then it's fine to give that answer. And by the way, I don't know the answer, but cramming that the idea of memorizing facts quickly for a short term recall, I think is a dishonest way. Maybe dishonest isn't the right answer, but it's not a genuine way of giving an interview, and it's setting yourself up for failure.
That's the first reason I don't like this approach. Second, I think it's a terrible way to do an interview. It's terrible for the company doing the interview. So as a candidate, I don't really want to work for a company that does that style of interview because I'm likely to be working for a company that doesn't understand engineering correctly. And let me explain what I mean by
that. As a hiring manager or a development manager, a software development manager, or an engineering manager, I want to hire engineers who can solve problems. I don't want to hire engineers who have answers memorized. In fact, the memorized answers are usually the least valuable. I want an engineer who, when they're faced with a new problem they've never seen before, they know how to find an answer. Now. I don't care if they find the answer
in their own head, if they invent something. I don't care if they go to Google. I don't care if they ask their grandmother. I don't care if they go to a meetup and talk about it over the weekend. I don't care how they get the answer. What I care about is that they can provide an answer to solve my business needs and canned trivia questions like
how many bites in air tcpheader don't help solve those problems. So as a candidate, again, I avoid this sort of cramming approach because I think it's not genuine and it's also not useful, and so I don't want to work for companies that rely on that sort of interview process. So that's what I don't do. Let me talk about some things I do do when I'm preparing for an interview. I'm still talking about before I'm at the interview, right, one of the first things I will do is I will read up on
the company. I think that's really important. Now there are times they're rare, but there are times when this is not practical. If you're interviewing at a stealth mode startup and they have no web site or the website is intentionally vague. And I've had this experience once. I once interviewed at a startup in this stage and I really knew nothing about what they did from the website.
But that's okay. At least I looked at the website. So you want to look at their website and know enough that you can have a reasonably intelligent conversation about the company during the interview. Of course, it's also good to know if you want to work in the industry and that type of company. If you have a particular industry and mind, or certain types of companies you don't want to work for, then this helps you solve that problem.
But while you're investigating the companies, there's a few things you should definitely look at. Spend ten fifteen minutes research in a company and learn what their core business is if possible. If you can't for whatever reason because the website doesn't tell you, then that's fine. But learn their core business. Are they selling to businesses? Are they selling to consumers? Do they sell physical goods like say Amazon? Do they sell services? Do they sell software? How
do they make money? Or are they a nonprofit? Learn the high level information about what is their business model. You don't need to know all the details, but generally speaking, what do they do? It's good to know if they're publicly traded company or a privately held company. Are is there a single owner or are the multiple stakehold shareholders. You know, things like this are good to know. They're not always essential, but that they're good to
know. So just learn a little bit about the company. How big is the company? Is it is it five people, Is it a thousand people? Is it a worldwide company? And every country on the planet with thousands of people? Learn the high level stuff. And while you're doing this, have some questions in mind. Take notes if you want to questions that you can ask during the interview. Every good interview will give you an opportunity to ask questions. It's really a two way street, right, It's not just
about you introducing yourself with the company. It's not an audition. It's a two way conversation. You're getting to learn to know each other. Think of it more like a date than like an audition. So you need to be asking questions of the company too. And if they don't give you time for that, ask for time for that. That could be one of the first things you say the interview, Well, I have time for questions, So
have two or three good questions ready. I can tell you this honestly as somebody who has done many interviews as a hiring manager is it always makes a good impression when the candidate asks me questions. When I turned the interview around at the end, you know there's thirty minutes twenty minutes left, and I say, what questions do you have and the candidate looks at me and it's like, oh no, nothing really. That really leaves a bad impression.
And honestly, I don't care what they ask as long as they ask something and as long as it's a meaningful question. So have questions ready to ask. And while you're researching the company is probably the best time to prepare some of those questions. I'll talk about some more of those types of questions later, but do it here. If you can't figure out who what their core business is, definitely ask that during the interview. Say I looked at your
website for twenty minutes and I couldn't find an answer. Do you primarily sell them to end users or to businesses or whatever the question is. So get questions, have two or three questions at least ready when you go into the interview after researching the company. I like to have a list of certain standard questions ready. And these are questions that I could ask at any of any
company. So if you forget to do the company research for some reason, or maybe it's a company you were already familiar with, so you skip that step, you could still fall back to some of these questions. So when the interviewer says, what questions do you have? You can go straight to these and these are just standard questions that are usually appropriate at any company. Sometimes these questions do get answered naturally during the course of an interview, so
you can skip the ones that have already been answered. But questions I like to ask things like what techstact does the company use. Do you use Java or She's c sharp? Are you a Microsoft shop or a Mac place whatever? Do you use Aws or Google? What project management or agile methodology do you use? Are you a scrum shop or do you use con bond or is it a mix your own and do whatever you want sort of place? Do you do agile? Do you do DevOps? Ask them what DevOps means
to them? Because DevOps has so many meetings around the world, every company kind of has their own concept. Ask them what they think DevOps means. Ask them do they have DevOps engineers on each team or do they have a separate platform team? Ask them questions like this. What a question I like to ask is what's the main reason I should not work here? And that's a good way to get I a little bit of an honest response from whoever's
interviewing you. Sometimes it's two or three people. If it is, ask each of them to answer individually, what's the number one reason I should not work here? And I asked this at every interview when I'm a candidate, and I get good answers. So consider that one closely related to the list of standard questions. I think it's really important to know your deal breakers before
you go into an interview. It's good to be prepared with a list of things that you absolutely want to have or need to have for your job. This list often gets longer as you get older, and that's appropriate, but there probably are some obvious things on your list. No matter the stage of your career. If you're fresh out of university or you've just taken a boot camp or something like that, and this is your first tech job, you're still going to have a list. It might be sure, but you'll have
a list. An obvious thing would be something like what city is it in or is it remote? You probably don't want a sixteen hour commute every morning to your job, so geography is going to be an important thing on your list. Are you willing to commute? Are you willing to relocate? If the job is sixteen hours away. That would obviously mean actually, you need to relocate. Are you willing to do that? Are you willing to pay for the relocation or do you need the company to give you a relocation bonus
if that's what you're going to be doing. Do you need a four day schedule or a five day schedule or something like that. Maybe you need to take care of your children, maybe you are still studying. Know your schedule requirements. Maybe you're willing to work forty hours a week, but it needs to be on four days a week, you know, four ten hour days something like that. Know that ahead of time, and be prepared so it doesn't take you by surprise when they ask you and you're just like, yeah,
okay, whatever, and then later you regret it. Knowing your deal breakers beforehand, putting them on paper, or at least having them in your head, is really valuable when it comes time to do negotiations and make an offer. Do you want a conference budget or a learning budget? Is that important to you? That usually becomes more important as your career advances. Many companies offer that. Some will if you ask, I've used that as a
negotiation technique. Maybe they can't give you a pay raise, but they can offer you an extra thousand dollars per year to go to conferences or something like that, and anything else you think of. Maybe you want a specific operating system on your laptop, maybe you want a monitor to maybe you're working from home and you want a big monitor from them, whatever, whatever is important
to you. Just have your list ready, and you can have a list of deal breakers and a list of nice to have, but bring those things up and ask about them. If there's an important deal breaker, be prepared to ask during the interview if that's going to be a problem for you. So that's basically my interview preparation. It's those fourth it's not cramming research. The company have a list of to innered questions and know my deal breakers.
So that's kind of the all I do to prepare for an interview. Once I'm at the interview at the first stage or so, that's when my mindset changes a little bit and I'm working on different things mentally. One of the things I'm looking for at that stage is how they do technical evaluations. In my view, automated coding challenges are a complete waste of time. Whether it's hacker brank or leap code or anything like that. It simply does not test
the things that matter on the job. It's high pressure, it makes people nervous, and it's completely artificial environment. Nobody is going to ask you to traverse a linked list on the job in thirty minutes. Nobody's ever going to do that, I promise you. What they will ask you to do is solve a performance problem in production and do it as quickly as you can. If it takes thirty minutes or six weeks, do it. So I avoid hacker rank style questions. If you're early in your career and you just need
a job, maybe go ahead and do it. Not everybody's good at those tests. Actually I'm not very good at them. It's a lot more of a mental game than it is a capabilities test, really, So if you need to and you're good at it, go ahead. Otherwise I just skip those. I would tell the interviewing manager, I'm sorry, I don't do tests like that. Well. Actually, there's two options. At this stage of my career, when it's relatively easy for me to find new offers,
a new new companies interview fat I just passed on those companies. So if they ask me to do a hacker rank or leak code, I just like withdraw my candidate to say immediately for the one thing, I don't really want to be working for a company that uses that as part of their screening because they're not doing a good job at screening. But if you're looking for if you really need a job, if you're either desperate or it's your first job,
you can't be that picky, and that's fine. Ask if you could pass on it, and if not, maybe you do it, maybe you don't, but you make that call. I don't like those types of tests. I'm also not a big fan of the take home long term coding tests where they ask you to write a rest API or to build a small test app that does something. If you are faced with that, I do have some advice that might help, although it takes a little while to get there.
I've been coding for many years and I have a couple of open source projects. One of them has something like three hundred stars on Kithub. So what I usually do is when somebody asks me to do, whether it's hacker rank or a take home style coding assignment, I say thank you for offering offering me to do that, but I think it would be a better use of both our time if you would review this code that I've already written.
It's much more extensive than anything that I could do in a half day project, and it gives you a real sense of the code I have written. And I have had many companies chick me up on that and say thank you, we'll review that instead. I've also had some say no, we really want you to do our coding challenge. If they say that, then you decide whether you want to do the coding challenge or not. If you don't have an open source project like that, and I'm guessing most of you don't,
that's fine. It doesn't need to be like that. If you can get some code from a previous job that you're legally allowed to share, you don't have an NDA or something to keep to you from sharing it. You could use that if you're in university, uses one of your coding assignments from university, put that on your GitHub, and point in potential employers to that. Next time you're asked to do a coding assignment, say I think it could be a better use of our time if you would review this code.
I already wrote, would you consider that? If you don't have those options, you could easily do a coding katta. Codecutter dot com has a bunch of katas, which are basically just little story problems, so to speak. They're kind of like a hacker Rank style challenge, but usually a little bit broader, and you do it on your own. Pick one or two that you like, turn them into some code and put them on GitHub, and point a recruiter or a high manager to that and ask if they would have
considered that as a last resort. If you simply don't have the time to do that, maybe you have a family, or you're too busy for whatever reason. The next time somebody asks you to do a coding challenge, go ahead and do it, but keep that code and put it up on GitHub. And then the second time somebody asks you to do a coding challenge, point them to that and say, I've already written this code. Would you
consider that instead? That will say that will potentially save you many hours of unnecessary coding during your interview search or during your job search while you're interviewing, So I highly encourage you to do that. You have the option of deciding whether or not it's right for you to refuse to continue with the companies that require a coding challenge. But at least you give them the option and you might save yourself for eight, ten, twelve hours of coding that isn't necessary
if they're willing to look at some previously written code. During the interview, I will ask about whether or not or what sort of development environment they use. And what I mean by that is do they let me choose my own ide or do they have Maybe they already have a group license for a particular ID brand and that's that's what they have, and that's all. Maybe you care about operating system? Do you want to use? Are you a Windows
user? Maybe you're a Mac user? Do you mind switching? If you're a Windows user and they give you a MacBook, is that going to bother you? If it does, if you're if you feel less productive, or you just don't like Mac for some reason, you can ask about that during the interview and tell them that you really want Windows. Or if you're like me and you're a Linux user, then maybe it's even more of a contentious
issue. But you know, I really want to work in Linux. I've I've used Windows in Mac and Linux, and I'm far more productive and Linux, So for me, that's the choice. But just just have that in mind what's important to you and ask about it. This is another one of the questions you can you can make one of your standard questions. Do I get to choose my operating system? Can I choose my ide? Can I
choose the tools I use? Et cetera, et cetera. Maybe maybe they let you choose, but they won't pay for it, So ask about that. You know, if you want to use jet Brains, that's fine, but you have to buy your own license or something. Ask those questions if that's important to you. And one of the other things I really, I really it is a red flag for me during the interview is gotcha trivia type
questions. I was actually in an interview just a year or two ago for a site reliability engineer role, and the CEO of the company actually asked me what is the RGB value for yellow? And my mind was blown, like why would you ask anybody this? Why would you even ask a web designer or a graphics designer this question. Maybe they know, but it's like there's there's color pickers and there's Google, just look it up. Nobody needs to
memorize this. There's no reason. And aside from that, who's actually using pure yellow at a website? Anyway, You're gonna be using some shade. He also asked me the difference between xhtmail and htmail five, and a whole slew of other ridiculous questions that just had nothing to do with the job at hand. I told him several times, I don't see how this relates, and at the end I just I withdrew my candidacy. I was like, I'm not going to work for this company. They don't know how engineering works.
They're asking ridiculous, unrelated questions. So I've talked about what I do to prepare for an interview and how oh I like to do the interview. Make sure that you have a chance to ask your questions. If they don't give it to you, ask for it. An easy way to do that is at the beginning of the interview, during the introductions, they're probably going to ask you to tell them about yourself. Say here's my history, by
the way, while I have time for questions at the end. If they don't give you time for questions at the end, and your time is run out and they're pushing me out of the room. Maybe asked to follow up by email or if they can stay in extra five or ten minutes to ask your questions. But make sure you ask your questions. As a hiring manager, people who ask me questions are impressive. The ones who don't, I don't have a good opinion of them. So I think I have said enough.
My throat is getting dry. I don't know what else I can talk about when I'm by myself, so I think we're going to call this an episode. I guess it's time for picks, so I'll turn it over to myself to do picks. I'm going to pick. I'm going to promote myself. Since I'm drying my throat out talking today, I'm going to promote my own material and we're just going to call her to day. I have a daily mailing list where I talk about all things related to DevOps and software development.
And I do talk about these topics about how to get a better job, how to interview, things like that. That comes up fairly frequently. If you're interested, you can go to Jhall dot io slash Daily. You can sign up for the list it's completely free. Occasionally I will promote a paid product on there that I do, but for the most part, it's just free information. I like to give back to the community, so you're welcome to do that. I would also like to pick a YouTube channel that
I think is helpful. It's geared more for software development, but really it's not even about the technical aspect of it, so it's really appropriate for anybody in tech. It's called Healthy Software Developer. The guy who runs a channel's name is Jamie Edwards. He's an experienced software engineer. He lives I think he lives in Texas, and he has a good YouTube channel with a lot of resources about approaching software development and IT culture and product management and all these
things. All the sort of challenges and struggles we deal with. He addresses these on his channel, so we'll have links to both of those picks. Thank you for joining me this week. If you're looking for work, I wish you the best. I hope that this advice has been useful and we will see you next time.