How-to: Handle job candidates who back-out after accepting an offer

It looks like Andy had a job candidate back-out on him after they had already accepted an offer. Thought I’d do a short post on some of the learning’s we’ve had with this already, just in case anyone else is going though the same thing.

First of all… don’t feel bad, because it happens. Try not to get frustrated, and realize that it’s just a cost of doing business. Easier said than done maybe, but it’s a goal, right? Best approach is to find ways to minimize the amount of pain that results when this does happen. As an aside, I’ve had candidates shop the offer after accepting, and it’s something that is hard to eliminate… often an employer will throw money at a good employee who’s considering leaving… so just keep that in mind. That said, the vast majority of the candidates that have accepted an offer seem to come on-board, and I always have a frank conversation with them about their current employer, and the likelihood of them doing a counter-offer, reminding them that we won’t get into a bidding war.

Next, it might be worth seeking legal advice if it really bothers you. It’s been my observation that the threat of legal action is a powerful one, even if there doesn’t appear to be much that can actually be done in this arena that’s really worth doing… but your mileage and options may vary.

After that come the practical things. First of all, get your bases covered… we don’t tune up phone contracts until after the first 90-days (consider letting them expense it, if it’s a sticking point), nor do we order business cards during that time period. In fact, we don’t do a lot of things until those first 90-days have passed. We stipulate that the first 90-days are an “evaluation period” when brining someone on, and that they’ll receive some type of review at the end of that time period. Other stuff we limit or otherwise restrict during that time period... Domain Admin access on client systems is restricted, as is access to the premesis after hours, all server room access, unsupervised access to clients (during the first month), and a few other things more specific to our business.

Things we do…
We do order a laptop/workstation once they accept (we can always use spares).
We do tune up a network account, and phone extension.
We do conduct the various HR tasks related to on-boarding.
We do send out a new employee introduction email to our employees as well as clients
We have lunch with the new person.
We do compensate based on the prevailing market rates (who wants an employee that doesn’t stick around beyond a year?).

Otherwise, pretty much everything is negotiable and flexible - despite the above. Oh yeah, and we try real hard to not let candidates who back out on us bother us too much.

IT Pro Interview Process - Overview and FAQ

What started out as a couple of posts on interviewing IT candidates in the SMB sector, turned into a mini-series/FAQ on the topic. So, if you work in the SMB sector, or you're a small-to-midsized business that doesn't have a very formalized interview process, or even if this is the first time you've ever had to interview job candidates, check out some of these posts.

• Getting Started


• Where do I find candidates to interview?


• What does a good resume look like?


• How do I efficiently screen candidates?


• What kind of screening questions should be asked?


• Introduction to the in-person interview


• What types of questions should I ask during the in-person interview?


• How do I make an offer to a candidate?
  

Feedback is welcome, so if you disagree or can offer additional input leave a comment or shoot me an email.

Interviewing: Making an Offer

I’ve covered just about everything that I wanted to touch base on with my series of interviewing posts, with the exception of making an offer to a candidate. Since there are plenty of books written on negotiation, I’ll consider that out of scope for this series of posts, and just leave you with these few recommendations…

1. Consider broaching the compensation topic early in your discussions – if possible do it before the in-person and establish some type of range so that you’re not wasting anyone’s time.
2. Stick to the plan of getting “X” number of candidates in for the in-person in as short of period of time as possible.
3. If you find a good candidate or two, and have already casually introduced them to your team, schedule another in-person with your entire team as soon as possible so that your team is included in the process and to make sure that there’s a good fit.
4. Make an offer. I typically give candidates 24-hours to make a decision – certainly if they need more time, I can accommodate them. But whatever you do, don’t lose your momentum. If they’re dragging their feet, don’t let so much time pass that you can’t make an offer to the other candidates that you’ve invested time in.

Every organization that employs people has a process for interviewing – even if it's not documented. So if you have any ideas to share, please let me know!

The Interview Process - Questions for the In-person interview

So what type of questions should you ask? Well, the first thing to keep in mind is the role that this person is going to fill. This is going dictate a certain minimum level of technical competency, and is something that your screening questions should have targeted already. After that you should have goals or areas-of-interest that you’re trying to satisfy. These should be designed to help you determine the “fit” of a candidate to your need. Technical competency questions are more measurable and objective than the fit/areas-of-interest questions, but you’ll weave these together to identify a candidate to hire.

Since we’ve been talking mostly about a “Server Analyst” or “Sysadmin” type of position in this series of posts, I’ll focus on that in my example.

Ok… but, what to ask?

“Tell me about yourself”… This one is a good (if obvious) first question because it marks the transition from making the candidate comfortable, to getting to know them as a potential employee. Some candidates will ask for some clarification, others will start telling you about their current job, and still others will tell you about something in no way relevant to the task at hand. So it’s actually an interesting tell right off the bat.

But only let that last one go so far… make sure you get them on track quickly with… “Tell me about your current employer, and your role in the organization.” That’s really what I wanted when I asked the first question, so you might consider stringing them into one. The first part of this is finding out what their employer does. If it’s a tech-company, or something tech-like, then you’ll get some context. If it’s a large corporation, then you’ll know to illicit some feedback on other areas that will determine the breadth of their experience. Finally, if they work in a small organization you’ll know that you need to focus on the day-to-day technical aspects of what the job will entail –so you have some idea if they are technically capable of the position. The second part of that question is about their role.

What’s their role again? Are you sure?

Server Analyst, Systems Engineer, Network Engineer, Network Administrator, IT Manager… and so on are used so interchangeably in this profession that I never really know what someone does until I meet them and talk to them about their role. Make sure if you want a “server analyst”, you’re getting the type of server analyst that you’d expect. So figure out the context…

For context, I start asking for some numbers… “How many servers are you directly responsible for?”, “How many users?”, “how many customers/clients”… numbers don’t necessarily tell you a whole lot, but it’s enough to figure-out if they’ve been forced to rely on some type of automation, or if they’re just dabbling as a server analyst. Let me explain… if someone tells me they’re responsible for a 200 user environment, with 4 servers, I know I’m going to have to illicit some more information to figure out if the their role is really that of a “server analyst”, or if they’re a “desktop support” person who does some server stuff when necessary. On the other hand, if they tell me they’re a Citrix Metaframe admin, with a 30-server farm, then I’m going to ask an entirely different set of questions. In either case, I’ll proceed to figure out if they have they experience in the areas-of-interest that I’m looking for. Personally, I usually need someone with good customer relationship skills, someone capable of juggling multiple priorities (often technical), while maintaining an excellent attitude, and always being customer-focused and driven. In the 200-user environment example, this might drive a whole other line of questioning… “So you’re responsible for 4 servers? What do they run?” Oh, you run Exchange? What version, and at what service pack? How many Exchange databases – if multiple, what drove you to use more than 1? What tool(s) would you run to troubleshoot a problem with your priv.mdb file?”… “So you’ve used eseutil before – tell me what you did with it”? I’m not looking for someone who knows the command-line flags of a random tool, I'm interested in their approach. I don’t want someone whose only answer is that they look stuff up in newsgroups, or in a KB article either - but it's okay to use resrouces to find information.

So in the above, I was trying to get a picture for what their job looks like. To generalize – are they Enterprise, or SMB? And beyond that, I tried to illicit some technical details about their environment. I was able to validate that they ran Exchange, and were up-to-date on the SP level, and if they’ve ever had to troubleshoot an Exchange server that was down. Now, depending on your need, you might want to get some more detail. Maybe ask about what other services are being provided by the Exchange server – find out if the placement of the Exchange databases makes sense in terms of the storage configuration and server utilization. Are they using a SAN to host the Exchange databases? If so, what challenges did they run into with making this work reliably. And so on… if you’re asking technical questions, you probably want to avoid getting too deep in an area that you have no experience in - as any technical person knows, it’s pretty easy to spot someone trying to fake knowledge or experience. So with that in mind, you’re going to want to ask a series of questions that are designed to give the candidate an opportunity to explain something to you as if you were a novice. There are a couple of schools of thought here – either pick something that you know a lot about so that you can coach the candidate and illicit the information you’re looking for, or pick something that you have no background on. I usually do both, but focus on the later. This will let you can focus on watching the candidate explain something to you, and to determine if their explanation makes sense. Ask them to explain the details, and why things are they way they are. It’s an excellent opportunity for you to A) learn something new, and B) figure out if the candidate can explain something to a novice. This will help you learn about their attitude, and their approach to working with clients.

Why is the sky blue? (Or, how to use open-ended questions)

This can be a really good tool for figuring out if a candidate is doing root cause analysis, or just treating symptoms, as well as putting them under pressure and letting a scenario play out that you might have come across in the real world. Be careful with this though, because if you haven’t carefully thought out the branches that this question can take, you might be setting a candidate up for failure based on the bias that you introduce. Questions like… “Tell me how you would troubleshoot a complaint of slow internet access” are good because they can tell you a lot about a candidate. Now, I’m not going to look at the branches this particular question might take here, but expect the candidate to talk about name resolution, bandwidth, user counts, IDS/IPS, HIDS, antivirus, networking infrastructure, and so on. Keep in mind that you’re not necessarily evaluating a candidate’s ability to figure out what’s going on at the packet-level (though you might be), what you’re really interested in is how the candidate responds to the pressure of an open-ended question. Do they freeze-up, or get noticeably stressed out? Do they get frustrated at not being able to get to the root-cause? Are they comfortable with telling you that they don’t know at some point? And do they offer a reasonable path-forward (i.e. get the Network Engineering tem involved; call Microsoft PSS if relevant, etc.)? Get them to tell you about why the sky is blue, and you’ll learn a lot about them.

Managing Expectations

This helps you learn about how the candidate interfaces with client, and if they can juggle multiple priorities, while maintaining a positive attitude. When it comes to clients/customers, everything is a priority because they’re the ones that pay the bills. So it’s important that they can demonstrate the ability to manage client-expectations while still balancing other commitments and responsibilities. The way I usually do this is by giving them a scenario... something like this… “Client A needs an inventory of IT assets for an auditor by tomorrow”… while “Client B’s CRM application is down”, and you don’t have any other staffing resources to help you manage this. Tell me how you would handle this scenario? Now, admittedly scenarios like this are only going to tell you so much about how they handle real-life situations… but it’s better than nothing, and gives them an idea of the type of issue they’ll be up against. The candidate should start by asking you questions something like this... “What’s the SLA for those items?” “Do we have a knowledge base on the CRM app, or a vendor relationship that we can leverage on the CRM app?” “Do we have an existing asset inventory that I can send, or is it something we can generate?”. Coach candidate, and get him/her direction as they need. Then have them explain why they’re doing what they’re doing. It doesn’t really matter which one they provide service to first, or if they have a plan to get both issues resolved – just that they had a plan that had been reasoned out

The Road Ahead

I always ask about tomorrow – industry trends, changes in technology, changes in perceptions... It gives the candidate an opportunity to show a passion for the field, and for the future. And it gives you a window into how they see the world. Ask them where they see the IT business in 5 years. Or better yet, how they see the role of the IT service provider changing – assuming they already have some exposure in this area. This flows nicely into questions about where they see themselves from a technical standpoint 5-years down the line… which flows into questions about like… “Technology constantly changes – how do you keep up”?

Summary

I hope this post proves helpful, and that it demonstrates that the interview process should be a conversation – there’s an ebb and flow to it. It’s not a list of 10 questions that you can check off of a list. And it’s not just softball questions about what the candidate thinks about certain things. Please don’t consider this to be a be-all-end all list of questions, rather see it as a list of ideas for managing the conversation, and getting useful information from the candidate. In the end, it’s important to keep in mind that you’re really looking for a “good fit”. Assuming the candidate meets a base-level of technical competency, focus on their attitude, pay attention to how the talk - if they’re able to have a conversation, and if you think they’ll be able to interface well with your clients, and will represent your organization well.

The Interview Process - Bringing in the Candidates

After a brief hiatus I’m back to begin wrapping up my series on the interview process. By now, you should have posted an ad, received some resumes, screened your candidates, and scheduled your first round of in-person interviews. Now, the more candidates you can meet, the better. But if you’re a small to mid-sized business, then you’re probably wearing many hats – so it’s going to be difficult to meet with dozens of candidates. Depending on your time and resources, set a goal to interview at least 5 candidates during the first seven business days of in-person interviews. As best you can, clear your schedule to make this happen. If you don’t, then this process will drag on forever, and you’ll end up forgetting about people, and never being satisfied with the results.

Why 5? It’s an arbitrary number – and an HR person might tell you that 5 isn’t nearly enough. But having worked for a medium-sized organization for a while, and watched how hiring tends to happen, having a goal of doing 5 in the first round is a reasonable, and achievable goal. So get to it.

Conducting the interview…

There are a lot of opinions on this, but here’s what I do, and I’ve found it to work well for my organization.

Your first job here is to get the candidate as comfortable as possible. Why? Because you want to learn about your candidate, and the only way to do that is to get them talking. Hint – brining them in front of your entire team right now, first thing, will not make them comfortable. If you do, you’ll be wasting everyone’s time. Yeah, I know… you already screened them. But until you know who’s worth interviewing, don’t bother brining your team in. Often I'll start an interview as a one-on-one, and then if the candidate seems like a reasonable fit, I'll bring in team members who happen to be in the office, or I'll bring the candidate by the break-room after the interview to talk with the team.

What’s with this whole “getting the candidate comfortable thing” first thing? Shouldn’t we be putting him/her on the spot to see how they react?

Would you want to be treated that way? There will be a chance to push the candidate, and gauge their reaction to not knowing an answer. But it’s important to get a good read on the candidate – so make them comfortable up front.

Maybe this is obvious, but I’ll say it anyway… your job here is to get the person talking. If you’re the only one talking, you don’t learn anything. And if you don’t learn anything, how can you reasonably evaluate the candidate? So after the pleasantries… you don't launch right into a barrage of questions do you? Oh you do? Well, let me define pleasantries then.

By pleasantries, I mean things like – “any trouble finding the place?”, “nice weather we’re having…”, "did you notice "X" about last month's patch-tuesday"... and so on. One thinks this should be obvious… but I’m defining this because I’ve seen interviewers launch right into the question component of the interview, and this throws some people off and makes them even more nervous than they would be otherwise.

So… as I was saying, after the pleasantries, give your 30,00ft overview/elevator-speech on who you are as an organization , and what you do. This shouldn’t be news to the candidate, but there will be time for details later… just don’t get too verbose here, because a big part of the interview is you keeping your mouth shut. I can’t tell you how many times I’ve seen interviewers use the interview to make themselves… feel smart, or important, or… whatever. Don’t be tempted to do this – if you do, you’re shooting yourself in the foot because a smart interviewee just might pick up on this, and realize he/she can score the job just with just a few well-timed comments.

So to review… make the candidate comfortable, give them the organization overview speech, get them talking, and keep your mouth shut.

Ok… but, what to ask? Well deal with that in the next segment.

The Interview Process - What type of screening questions to ask

Picking up where we left off, you should be at the point where you've gotten some resumes in, reviewed them, and have engaged a (hopefully) non-technical person to screen the candidates with a short phone call. My recommendation is to keep the list of questions short, make sure the screener has the answers and that you've sat down with him/her and explained the criteria and a process for collecting and recording information.

For example…

1) Name as many FSMO roles as you can.
2) How many layers are in the OSI model, name as many as you can.
3) What is the difference between RAID1 and RAID5?
4) What ports do the following services run on? SMTP, HTTP, HTTPS, Remote Desktop…
5) How do you determine the IP configuration on a server or workstation?
6) In what order are group policies applied in?
7) Name some patch-management solutions you've worked with.

Alright, I can already hear it… FSMO roles aren’t changed that often in the SMB-space. Or, the OSI model is [insert one of a dozen different complaints] , or… whatever. You see, with these questions I’m just trying to get the screener to gauge the background of the candidates. If someone can’t remember 1 of the FSMO roles on the spot, well maybe that’s one thing. But if they completely miss questions 1, 2, and 6, and can't name any of 7... well, you get the idea.

Remember what you’re looking for – reasonable answers to as many questions as you can get, without overwhelming your candidate or the screener. Keep in mind that these questions should screen out, as well as screen in the type of candidates that you're looking for.

Finally, having a screener should make your life easier - if it doesn't, then don't do it.

The Interview Process - Step 2, Screening Candidates

Step 2 – Screening candidates…

This is where having a receptionist, office manager, HR person, or basically anyone non-technical can come in handy during the interview process. Why non-technical? Because if you can hand a list of screening questions to someone who doesn’t have a frame-of-reference, then you can just have the screener ask the questions and record answers. Or if you’d prefer, hand them questions and answers. Having a phone system with a few bells and whistles can improve this a step further – get the screener to forward copies of the phone calls to you so that you can review the responses on your own schedule (say for instance, at 2am on a weekend – like when I’m writing this post).

Couldn’t having a non-technical screener be unfair to the candidate?

I tend to think it’s more fair for everyone. Why? Well, primarily because your screener is likely to have less bias. Having no frame of reference, all they know is what to ask and maybe what the right answer is. You might also help the candidate by having the screener explain who they are and what the purpose behind the screening call is. It might help put your candidate at ease knowing that A) it’s a low-risk interface and B) we’re being as objective and as measurable as possible during this first round.

What if the candidate asks probing technical questions to get perspective on the questions?

Well, if you’ve put together good questions they should be the type of questions that have real yes or no answers – questions where you only have 1 possible “right answer”. If the candidate is asking probing questions, just have the screener reiterate that they are simply recording your responses for the hiring manager.



What kinds of questions should I be asking?



I think I'll save that for tomorrow.

The Interview Process – What does a good resume look like?

So, you’ve placed your ads, and now you’ve got a stack of resumes to wade through. Where do you begin?

The cover letter.

Resumes are fine for communicating history. But a cover letter tells the candidate’s story. It’s what they should be using to grab your attention, engage you, and differentiate themselves. I always, always ask for a cover letter. If they don’t send one, I usually don’t end up looking at the resume. Maybe that sounds harsh, or unfair, but if I specifically ask for a cover letter in an ad, and I don’t get one – what does it say about the candidate? That they didn’t read the posting? Maybe they’re spamming their resume to every employer in the area. I can forgive a lot when it comes to a candidate – ugly resumes, gaps in the employment history, a technical background that’s not an exact match with the need … but I need to have a cover letter. And why not? It’s a candidate's opportunity to differentiate him/herself from the dozens of other resumes that hit my desk that morning.

Incidentally, while I might skim through resumes, I read every cover letter that I get.

Always send a cover letter. And spending 5 minutes to make sure that it’s a good fit and just a little bit customized for the position that you’re applying for can make all of the difference.

Resume tips?

There are plenty of books, and plenty of sites that cover this in detail. Specifically worth mentioning is the Jobsyntax blog – definitely worth a read. As far as what I like? Short, 1-2 page resumes. I like an “objective” statement – but if your's says anything about “finding a job”, or is “passive” in anyway, then it’s best to leave it off. I’m not in the business of giving out jobs – I’m in the business of making a profit. Help me make a profit. Otherwise, the highlights should all be on the first page, including at a minimum – current position, major accomplishments that you are comfortable discussing intelligently during an interview, and education. Education is becoming increasingly important for IT Professionals. I'm getting tired of the certification mills churning out job-seekers.

The Interview Process - Getting Resumes

As I was saying yesterday… the framework… we’ll start with the beginning.

1) Get resumes

Well, I suppose getting approval for the position wouldn’t hurt. I understand that it’s an up battle in some companies - but when you're a profit center, it's usually easier.

Alright – obviously, there’s lots of options for getting resumes in the door… Jobburner, CareerBuilder, Yahoo Jobs, Monster, Dice, and so on. But just doing something is the first step to getting people in the door – so don’t procrastinate under the guise of trying to find the best engine – they’re all adequate. Personally though, I really like Craigslist. I know some people have mixed results from them, and certainly I’d imagine that a lot depends on your local labor market – but hey, in most markets it’s free to post. So if you’re running something though one of the big names, why not double (or triple) up and use Craigslist? I think your results will depend more on your local market, but while the volume you get out of Craigslist might be less than the other boards, I’ve found the overall quality of candidates to be very good.

The Interview Process - Getting Started

In the past couple of posts, I’ve talked about just a few of the key-takeaways from the interview process – mostly from the perspective of an interviewer. While I think there are more things to consider and that would be worth talking about, I want to move on for now and talk about what our interview process looks like, and why it looks that way.

I know that some companies – like Microsoft, P&G, and Google - have really involved interview processes consisting of multiple meetings, phone calls, and so on stretched out over weeks, or sometimes months. As I’ve said before, we’re a small to midsized company and we don’t have the burden – or luxury of doing that. In fact, until very recently we didn’t have much of a process at all – very informal, and certainly not measurable. That said, I like things that are as objective and as measurable as possible – and as we’ve grown more responsibly has been pushed out into the organization, so having a standard process is important. Most would agree that there is a certain amount of subjectivity to the interview process, and that making is measurable is hard. But I don’t think that it being “hard” means throwing up your hands and saying “it can’t be done”. And while I believe that it’s important to follow-up your gut, and use your instincts, you need to check those instincts against something that is measureable.

In short, I try to balance subjectivity, and objectivity, and try to include as many members of my team in the interview process as possible.

But what does that mean?

It all starts with having something in place. Some type of framework, and some type of process. It doesn’t have to be perfect, and it shouldn’t be the first, last, and only time that you consider the process. It’s just that most organizations either: A) Don’t hire frequently enough to put a process around it – so they reinvent the wheel each time. Or B) Hire so frequently that they have HR department to manage it. Since we fit in the middle, we needed a process. So I started talking to contacts that I had in different sized organizations – of all sizes - and came up with something that looked pretty typical of every interview I’ve been on.

1. Get resumes
2. Screen candidates with a phone-interview
3. Bring candidates in for a 1-on-1 interview, followed by an informal team meeting
4. Second in-person interview with team
5. Offer letter

The framework probably looks similar to every other interview process on the planet – and with good reason, it was our starting point.

In the next post, I’ll drill down into the detail on the framework, to address how we get resumes, screen candidates, and so on.

The Interview Process – A few more key-takeaways

Let’s jump right in today…

Third takeaway – There’s no such thing as the perfect candidate.

If you can get beyond that, then it quickly becomes about finding a good fit. I can make a list of technical requirements for a position, and someone can show me a list of certifications that they have to meet my list, but at the end of the day, it’s about finding someone who is a good fit. Put a different way – you can train a good Engineer – or good Technical Person - to do almost anything technical. But having the right attitude makes all the different in the world. Find that good mix of technical talent, and attitude and you’ve met that “good fit” criteria.

Expanding on that point even further for a second, I would much rather hire someone who might be lacking a in a few technical areas, but has a great attitude, than someone who projects themselves as knowing everything about everything. In fact, a candidate with less technical background – or maybe even a different technical background than what I need right at this second, might be – in fact has been in the past – a more preferential candidate. For instance, when I put out a job add I don't list 10 years of experience as a requirement for anything ... in fact, I'm very general with my experience requirement because I want to see resumes, I want to talk to people, and I want to find a good fit.

Fourth takeaway – Don’t make people feel stupid (and don’t be arrogant).

I think these two go hand-in-hand, and I admit there’s a balancing act here. You want to push a candidate to get a feel for their technical depth, as well as to see how they respond when they don’t know the answer and are under pressure. That said, a “good fit” candidate shouldn’t have all of the answers. No one knows everything about everything. So if you’re interviewing candidates for a Network Administrator position, don’t expect a deep background in something unrelated – or only marginally related.

I remember going on an interview a while back, where the interviewer just slammed me for not having the answer to a very specific – and obscure problem. One learning that came out of that for me was that sometimes “I don’t know” is a good answer. If someone doesn’t know the answer, but explains how they’d go about finding the answer – proceed. Or let it go. Consider your objective met in learning that they don’t have the answer to question “X”. But pay attention to how they handled question X – and handled not knowing the answer to question X. If they get it wrong, press them on it, get them to ask you questions. But you shouldn’t be making a candidate feel stupid.

More to come...

The Interview Process: 2-key takeways from our search

Our metrics have been supporting the case for adding an additional Network Administrator position for a while now… staff utilization metrics, billable percentages, and our pipeline are all in agreement. So after posting an ad, getting a stack of resumes, and interviewing some candidates I thought I’d post some of my thoughts on the topic. Maybe even a series of posts… we’ll see how it goes.

First takeaway – Nobody really likes interviews.

That goes for all sides of the table. If you’re a job candidate, keep that in mind because it just may give you a bit of an edge. If you’re an interviewer, come prepared with discussion points, and facilitate the conversation. Obviously, you should have reviewed the candidate’s resume more than once, and should have some measurable criteria for comparing candidates. And if you’re a resource (not the lead on the interview), have some questions prepared. Have an idea of what you want in a fellow employee, and be prepared to insert yourself into the discussion if you see things getting off track.

Second takeaway – Make the most of what you have.

We’re not Microsoft… or Google… or any one of the big west coast tech employers.
We have a great team, a diverse talent pool, and a good mix of backgrounds… from Software Developers, to IT Professionals, to other Engineering types. But as a small-to-midsized technology company in the Midwest, we have limited time and limited resources. In practical terms, that means no day-long interviews with a dozen different people. We’re pretty much limited to three interviews… 1 phone interview, 1 one-on-one interview, and 1 team interview. Make the most of your time.

That’s about it for today. I’ll plan to follow-up with some more ideas, and add some interview questions that we've used - as there doesn't seem to be much in the way of intervew questions for netadmins floating around on the internet.