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.