Job Interviews, and Tips for Getting a Web Development Job

In this one-on-one episode of the Versioning Show, Tim and David discuss the ins and outs of job interviews in the web industry, including tips for preparing for and getting the most out of interviews, the pros and cons of recruiters, the merits of whiteboards, and curly questions you definitely don’t want to be asked.

Show Notes

• Tim’s article on How to Get a Web Development Job
• Glassdoor
• Bubble sort algorithms
• JavaScript with statements
• Say hello on Twitter: @mdavidgreen | @tevko | @versioningshow | @sitepointdotcom

Conversation Highlights

I think what we can definitively say is, whether you come into contact with a company through an external recruiter, or an internal hiring manager, the advice that I would have to give is that it’s important that you get to speaking to a technical person as soon as possible.

---

you’re looking at putting out 80 to 100% of your working hours, of time — this time which is a resource that you cannot renew — and giving it to somebody else in exchange for a certain amount of money. And money is of course a very renewable resource.

You’re definitely on the losing side of a bargain like that, unless you go into it with the idea in mind that you need to evaluate whether this is the company that you want to work for, these are the technologies that you want to learn next, so that you can continue developing your career.

---

interview the company before they interview you. Do your research, ask your questions, make sure you have the information you need, before they start to evaluate you technically as a candidate.

---

When I am interviewing a potential company to hire me, I find myself a lot more, lately, looking at their business model — if it seems to be something that is sustainable, and not based off of hype, and most importantly, internal feedback.

---

There are so many angles to approach a job offer, and you’ve really just got to dive in. Look at the business model, look at the funding information, look at the satisfaction of the employees. Ask to meet with people and keep asking to meet with people.

---

The company is investing a lot in you, if they have made the commitment to bring you in and do interviews. You have to respect that, and you have to realize that if you’ve gotten to the point where you’re getting those interviews, they’re serious about you, and they want you to succeed.

---

So, when a company asks, Do this thing on a whiteboard, that is not an accurate challenge. That is not an accurate representation of a day-to-day job. That’s the thing that bothers me. At that point, that tells me that the company is looking mainly for me to be initiated into the group, not to be evaluated based on my technical skills for the job.

---

you shouldn’t approach whiteboard coding challenges as if they’re expecting to be able to print what’s on the whiteboard into a computer screen and have it run immediately and perfectly. You should approach it as, This is going to be how I would solve the problem. Let’s figure out what the problem actually is, and let’s get to the details.

---

When I interview candidates, I will find CodePen, I will find LinkedIn and GitHub and everything I can. If they give me their Twitter handle, I will see if they follow the same people that I follow in the industry. I will do those things, because I want to get a grasp at how in tune they are with the industry. I want to see code they’ve written and shared and contributed to.

Transcript

David:

Hey! What’s up, everybody? This is M. David Green …

Tim:

… and this is Tim Evko …

David:

… and you’re listening to episode 13 of the Versioning Podcast.

Tim:

This is a place where we get together to discuss the industry of web from development to design, with some of the people making it happen today and planning where it’s headed in the next version.

David:

This episode, we’re going to be talking about how to get a job in web development, and in the web industry, and in the tech industry in general — some of the ins and outs, some of the dos and don’ts, and really whether a job is what you’re looking for anyway. So, let’s go ahead and get this version started.

So Tim, I understand you’ve actually written an article about this on SitePoint — about how people should look for jobs in web development. What were you focusing on with that?

Tim:

The tech industry, as it stands today, is very new, and if you’re coming from a different career field, or if this is one of your first interviews in the tech setting, the way these kinds of interviews are traditionally held can be a bit surprising for people. Lots of people have written articles and tweeted and written blog posts about this process, and a lot of people sometimes find fault with it, which can be very valid. What I wanted to do is let people know what they can be expecting, and ways they can make the whole process better for them and better for the people looking to hire them.

David:

I think one of the challenging things is that, in a lot of these companies, it’s really difficult to figure out who is actually in charge of hiring — because often the responsibility falls into the hands of engineers who don’t actually have a lot of the HR-type experience, with the advice of HR people who don’t know much about engineering in a lot of cases, and getting them working together in a way that makes sense. It can be very tricky.

Tim:

That’s an excellent point, and that’s why I would say, one of the first things that I try to do when I find myself in this situation, is to — as soon as I can — figure out who I am talking to. You might not always have this luxury, but I prefer not to deal with external recruiters. That is a privilege to a lot of people, but what that allows me to do is connect with hiring managers who work internally, or CTOs who work for the company, and not this external third party. Because, a lot of times, what happens is, the third party has their own interests, which aren’t necessarily your interests.

Whereas, hiring managers in a company, or a CTO, or an engineer at a company who is looking to hire someone directly, are a little bit more concerned about the applicant. Whereas third parties like external recruiters, they get paid to do this. A lot of the times I will just, if I can, not at all deal with these third parties. Again, it is something that not everybody has the option to do.

Secondly, I will immediately try to identify if I am talking to a technical person or a non-technical person. When you find that out, as soon as possible, it does make the whole process a lot easier.

David:

What I’ve noticed, I remember when I was starting off in my career in tech, the recruiters were incredibly helpful to me.

I was somebody who repurposed myself as an engineer later in my career. I became an engineer after years of working in writing and marketing and PR and things like that. As a new engineer, I went directly to the recruiters, and I was very grateful to have their insight and their feedback — how I position myself in my resume, how to talk with technical hiring managers whom I had worked with only from an outsider’s perspective. It was very useful to me.

As I have become more mature as an engineer, I’ve gotten to the point now where I think I’m in the same position that you are, where recruiters get in the way and interfere with the connection that you can make directly to the company. But when you’re starting out, and you’re looking for those first couple of jobs — particularly if you’re doing your first job transition from one company to the next — having that recruiter on your side and working with you can be very valuable.

Tim [4:11]:

That is very true, and that is a good reminder for me as well. Because, now that you mention that, when I first went from my consulting, kind of just hitting up random companies on Craigslist, when I went from that to my first full-time company to do web development, there was a recruiter there who was an excellent help and went way further than he needed to, to help me get a job. So I should be a little bit more careful about casting aside all third-party recruiters. [Chuckles]

Plenty of them can be extremely helpful in getting you a job — especially if you are new to this whole scene and this whole scenario. If that is you, if that does describe you, feel them out to see exactly how helpful they are and how much aid they can give you in this process. Because sometimes — I guess for both you and me, David — they can be extremely helpful. Very good point.

David:

As you say, the importance of feeling them out is critical. When I started, I had had at least some work experience before, so I knew the importance of choosing a recruiter to work with who was compatible with me, and who understood what I was going through, and could relate to me. I talked to several, and it was a matter of kind of interviewing them, so that they could have the prize of being able to present me to a company and get 20% of my salary for the first year (or whatever it is that they end up getting).

Yes, absolutely. You need to consider this recruiter not just as, this person reaches out to you because they see your profile on LinkedIn and they know about this job, and suddenly they’re the only person you can talk to about this job. No — that is not the way that it is. They tell you about a job, or they tell you hints about a job, but you can usually use Google to find out the rest.

Tim:

Yes.

David:

You work with the recruiter that you know and that you like, because that’s the person who’s supporting you, and that person knows that, with the way careers go these days, you’re probably going to be changing jobs again in another two or three years, at most — [chuckles] — and they’re going to get another commission out of you if they just support you and work with you.

Tim:

Yeah. So, that being said, I think what we can definitively say is, whether you come into contact with a company through an external recruiter, or an internal hiring manager, the advice that I would have to give is that it’s important that you get to speaking to a technical person as soon as possible. Someone who you can ask questions.

A lot of times, these companies will have these processes wherein you will speak to a recruiter, and then, immediately, you’ll be given a like technical phone screen or even come in for an interview. And you’ll go right from talking to a non-technical person to being evaluated by a technical person. That can sometimes mean that you don’t get to ask a lot of key and important questions before you go through the trouble of being screened technically.

One of the things I try to do in this process is I try to talk to a technical person, either a lead developer or a CTO of the company, as soon as possible before I’m being evaluated for my technical proficiency.

That gives me the ability ask questions like, Hey, what kind of software do you use? Do you practice good development principles? Is your team a diverse team? Are there people from different backgrounds and genders on your team, or is it going to be a sort of inside club? Do you practice good work hours? Things like that.

I like to get those questions out before I am getting into code challenges and whiteboarding type of things, just so I can get a feel for the company before I have wasted — or potentially wasted — a lot of time in the whole interview process.

David [8:04]:

I like the meta message behind what you’re talking about there, because what you’re talking about is the importance of you interviewing the company, not just the company interviewing you. I think a lot of candidates go into this with their hand out, desperately saying, Please give me a job. At least let me qualify for this job.

Tim:

Yeah.

David:

But no, you’re absolutely putting yourself on the line there, and the thing to remember when you’re looking for a job, you’re looking at putting out 80 to 100% of your working hours, of time — this time which is a resource that you cannot renew — and giving it to somebody else in exchange for a certain amount of money. And money is of course a very renewable resource.

You’re definitely on the losing side of a bargain like that, unless you go into it with the idea in mind that you need to evaluate whether this is the company that you want to work for, these are the technologies that you want to learn next, so that you can continue developing your career. You have to understand whether or not the CEO, the executives, whether the people who are in charge of this company, have a vision that you believe in and that you can support, such that you’re willing to say, Okay, I’m going to give you 100% of my time for the next two years in exchange for you paying enough money for … maybe my rent (if you’re in San Francisco, [chuckles] or a little more than that if you’re out of San Francisco).

You have to remember, you are interviewing this company. They’re not just interviewing you.

Tim:

Yes. I think we could summarize point one as being: interview the company before they interview you. Do your research, ask your questions, make sure you have the information you need, before they start to evaluate you technically as a candidate. I think once you’re able to do that, once you give the people in charge of the hiring decisions the impression that, Hey, I’m evaluating you just as hard as you’re evaluating me, I think, and I hope, you start to get being taken a lot more seriously.

So I think our first point can be: interview the company before they start interviewing you. Do you think that sounds good, David?

David:

Yeah. And as you said, if you’re doing your homework that way, and really looking for your own best interests, you’re going to look much more appealing to these companies, because they’re going to see you as somebody who is taking this seriously and who’s done the research and understands what they are and who they are, and is looking at the serious issues. You’re ready to come in there and really do some work with them, you’re not just randomly looking for somebody to give you money.

Tim:

The more I look into companies — and I’ve done this process a couple of times (I am a little bit familiar with how it goes) — I’ve started to focus more on the business side of things. When I am interviewing a potential company to hire me, I find myself a lot more, lately, looking at their business model — if it seems to be something that is sustainable, and not based off of hype, and most importantly, internal feedback.

One of the first things I’ll do is I’ll look up the company on Glassdoor and see what the reviews are like — seeing what people are saying about them in probably the most hostile of environments. Because in Glassdoor, companies can’t respond back to what the reviewers have to say. If you get a one star review, it’s going to stay there forever. I like to look at that, but I also like to look at, all right, what’s your business model? Are you a series A, meaning, did you just get your first round of funding and now you’re hiring up engineers? Are you profitable? Have you been in business for a while? Are you hiring because maybe somebody really important left, or because their salary was a little bit too much for you to pay this quarter? If I’m going to commit to working for you, I want to make sure that your business is a very good one.

David [11:56]:

That’s one of the most important reasons why a lot of the people who find the most job satisfaction when they change jobs are the ones who get jobs at companies where they have colleagues they’ve worked with before, and they’ve kept in touch with their networks. Those people can tell them, from an insider’s perspective, Oh, you’re moving into this division, you’re going to be reporting up to this director, and, These people have this kind of attitude and this is what they’re trying to work on. You can find that out from the people inside the company.

I’ve noticed that resources like Glassdoor, while it’s probably about 80% accurate, there’s this phenomenon — I don’t know if you’ve heard of it — it’s called Glassdoor turfing, where companies actually post reviews of their own company as if they were being posted by people who worked there from the outside. It’s pretty obvious when you’re working at the company if you see a review that was a Glassdoor turf review, but it’s not completely obvious to those of us on the outside doing the research. So it’s critically important to use your network and go look into companies where you know people who are working there. You can find out from the inside what the real scoop is, and what it’s really like to be there.

Tim:

That is very helpful. That’s why participating in the community is such a beneficial thing — again, if you have the ability to do these things. I, for one, always find myself wishing I participated more in the community. Because what I do, I make contacts with people who work at a variety of interesting companies, and it has happened before where I will get a job offer and I will talk to someone and say, Hey, you’ve worked at this company. What can you tell me? What should I expect? How are the people here? And it’s so much more of an at ease feeling, because when you don’t have that, even if the interview goes perfectly and everybody seems very nice, you could land in a team and on day one comes a hostile manager that you’ve never met before. And that’s a scary situation.

David:

It is. Especially if you’re new to the work world, you may feel like that’s the only way that people work in this industry. I’ll tell you, there are engineers who are very happy with managers who are very supportive. There are engineers who are very unhappy with managers who don’t know how to protect them from the buffeting that goes on inside of companies.

Ultimately the responsibility of the company is to make money, and if it is a publicly traded company, for the shareholders. If it’s not, for the investors. If you’re working for a bootstrap company, then you’ve got a CEO who’s desperate to make back the money that he put in from his own pocket, from the pockets of the angel investors. As I go through that now, I’m thinking, my God, it was so useful to me when I started with this that I had an MBA before I turned myself into an engineer.

Nowadays, just to get a job in these companies and evaluate the things that we were just talking about, you kind of have to have enough of a grounding in business — you know, what is a series A? What are all these funding models? How do you know about these things? You have to understand how business works before you try to position yourself in a job, in a company, because you don’t know what you’re giving up and what you’re exchanging it for.

Tim:

Yeah, and I’ve learned a lot of these lessons the hard way. I did not know what a series A was not too long ago. I didn’t know that it would be an excellent idea to look at how many rounds of funding a certain company has taken in a certain amount of years. For example, looking at just what does this company do? Does this sound like a very trendy thing?

For example (and again, if you work for this company I’m so sorry), but if you work for an ecommerce company that sells a mystery cat toy every month — if you get a job offer for that company, you have to think to yourself, Is this the kind of company that is going to take on a consistent amount of new users? Are the people in charge of the business promising me that that’s going to happen so I’ll accept their offer?

There are so many angles to approach a job offer, and you’ve really just got to dive in. Look at the business model, look at the funding information, look at the satisfaction of the employees. Ask to meet with people and keep asking to meet with people.

Again, something I don’t think we’ve touched on so far, companies spend money to hire people. Even if you don’t use an external recruiter, you have to vet people technically, which means you take engineers away from engineering time, and you divert them to hiring. Now, in this industry, a lot of us get paid very well, which means that an engineer who spends an hour technically vetting a potential hire, could be as much as $100 to $200 lost from engineering time, so you’re spending possibly around $100 to $200 an hour just to interview someone. That means that it’s in the company’s best interest to get this process done as fast as possible — which means they’re not going to spend time, if they don’t have to, to introduce you to everyone in the company who you’re going to be interacting with on a day-to-day basis. That’s on you to go and find that information out.

David [16:45]:

I always make it a point, during the second round of interviews: I request specifically to meet with a wide range of people. For example, I was working as a front-end engineer earlier on in my career, and I would always make a point of saying, I need to meet with the head designer as part of the interview process.

They’d say, Well, you’re not booked to meet with the head designer. Why do you want to meet with the designer? I said, Because I’m working front end, and I need to know how designing and engineering are working together. You can make a strong case for that, but it takes time from the designer’s time.

The company is investing a lot in you, if they have made the commitment to bring you in and do interviews. You have to respect that, and you have to realize that if you’ve gotten to the point where you’re getting those interviews, they’re serious about you, and they want you to succeed. They want somebody to come in and help them with the problem that they’re trying to solve, and they’re desperately hoping that you’re that person who can come in and do that, and that they can just throw a little bit of money at you — a little bit form their perspective, hopefully a lot from your perspective — but throw some money at you and solve their problems. So ask them for what you want. Ask them to meet with the people that you want to meet with.

Tim:

I think a good second point would be: the interview process is an expensive one, and you can use that to your advantage.

David:

That’s fair. That’s fair.

Tim:

We haven’t yet steeped into the technical side of things, which is the scary part.

David:

We’re going to talk whiteboard coding, aren’t we?

Tim:

No, actually, I am the most anti-whiteboarder you could probably find. I sometimes find it to be a red flag. Not always, but sometimes, find it to be a red flag, when a company says, We’re going to bring you on site for four hours. That’s not an amount of time, I’m just pulling out of the air. I’ve seen that on more than one occasion. And the whole time, it’s going to be a technical interview.

The reason that bothers me, is because at this point, I have sent you my GitHub profile, my CodePen profile, my portfolio site. At this point, I’ve sent you all of my information, and there is a ton of code there — which, by the way, if you’re interviewing for a job, make sure you have a lot of publicly visible code. If you can do that, that’s a great advantage. But if you’re going to ask me to come in for a technical interview that involves whiteboarding for four hours — or even half an hour — by the time I’ve sent you all this information, I’m a little bit worried that your processes might be a little bit archaic.

I much prefer when someone says, Hey, we’re going to send you a code challenge that you can complete on a computer with access to Google. Because that’s how modern web development happens. That’s how all web development happens. If you don’t do that, and you’re asking me to write some algorithm like bubble sort on a whiteboard — which I cannot do, mind you — I would sometimes think cool and intricate and complicated things on the web. I have never written a bubble sort algorithm, and I couldn’t tell you the first thing about how to start doing one. But, if you ask me to build something online, I will get it done. It might be difficult, but I’ll get it done.

So, when a company asks, Do this thing on a whiteboard, that is not an accurate challenge. That is not an accurate representation of a day-to-day job. That’s the thing that bothers me. At that point, that tells me that the company is looking mainly for me to be initiated into the group, not to be evaluated based on my technical skills for the job. When the company does one of these initiation processes, it sort of tells me that there is a lack of real competency, a lack of, We’re really interested of how good you are at solving the problems we’re going to pay you to solve, and a lot more of We all did it this way, and now you have to.

David [20:22]:

Wow, this is interesting, because my inclination, after hearing you talk about it this way, is almost to play devil’s advocate — and I am not a big whiteboard coding fan. I think that it’s one of the worst ways of evaluating an engineer.

Tim:

Yeah.

David:

That said, I’ve been at companies where there was a desperate need to bring in people, and not enough resources to put together something like a coding challenge and to evaluate coding challenges. The offers that the companies were making to the employees — that were perspective employees — just weren’t compelling enough to get the qualified candidates to take a coding challenge. We would send out coding challenges to people, and they would say, You want me to spend four hours of my time writing code for you that you’re going to use and you’re not even going to pay me for it? And, you know, all of these things.

Tim:

Yeah.

David:

It gets complicated. On the other hand, the whiteboard coding challenges, if they’re properly managed, can be an effective way of evaluating an engineer’s skills in terms of how they interact with the requirements and move forward with getting to a solution. I’m thinking about situations where the whiteboard challenge is done in an interactive way, almost like a programming situation, where there’s somebody who has requirements and they’re standing with you, and while you’re working through the problems, you’re able to ask them for questions and you’re able to demonstrate your understanding of the domain that the problem is in, and go back and forth and almost jointly solve the problem.

In my opinion, the best way of interviewing candidates is probably more of a pair programming situation, where you and the person being interviewed — or whoever this is — sit down with a problem that ideally neither one of you knows the complete solution for, or for which there could be multiple equally valid solutions, and jointly work together on a computer, in a pair programming situation, to come up with a solution and get that dialog going and demonstrate that both of you are able to work compatibly together, and that you have respect for each others’ skills and abilities.

Tim:

I think that’s a very fair point. I would say my problem with whiteboarding, aside from the fact that I can’t do it, because I never write code on a whiteboard. I can draw a concepts and vague, crudely drawn outlines of distributive systems and things like that. Like when you’re in a meeting with the other engineers, and you’re trying to talk about how do we keep our user logged in for 90 days, but prompt to them for a log in again if they’re trying to edit their account information. I can draw those sorts of concepts on a board, but what I’m not going to do is write JavaScript on a whiteboard in a way that could solve an actual code problem.

I think that’s my biggest issue with whiteboard style interviews — is that if you want to test how good I am at solving a technical challenge, we’re going to need a computer in here, because that’s where the code goes.

David:

Absolutely. A computer is a necessary component, and I’ve seen companies that go the full range to Here’s a computer, here’s access to the internet, here’s Google, here’s four hours, here’s the challenge. You’re on site. Work on this, and then we’ll discuss it afterwards. That’s one approach, and I personally favor more of the interactive approach where there’s a computer, there are two people and they’re working together and they’re trying to solve a problem.

Even if you’re presented with a situation — and you will be: if you’re out there interviewing for jobs, you’re going to be presented with a situation where there’s a whiteboard — you need to take control of that and make it clear that what you’re going to write on that whiteboard is likely going to be pseudo code.

Tim:

Yes.

David [23:50]:

You’re going to need to frame the problem properly, and you’re going to need to ask for test cases, and ask for all of the requirements, and usually problems are going to be presented to you in such a way that they could be solved in multiple different ways. And you have the opportunity with a person in the room with you, while you’re whiteboard coding, to do some back and forth.

What they’re really evaluating you on is not whether or not you put a semicolon at the end of every line on the JavaScript on the screen. What they’re really evaluating you on is your intellect, and your ability to reason within the domain of the problem. So you shouldn’t approach whiteboard coding challenges as if they’re expecting to be able to print what’s on the whiteboard into a computer screen and have it run immediately and perfectly. You should approach it as, This is going to be how I would solve the problem. Let’s figure out what the problem actually is, and let’s get to the details. It’s much less intimidating if you look at the whiteboard as what you were talking about — as a place to work out concepts, rather than as a place to write code.

Tim:

Yes, and I would say my favorite way to do an interview is to have someone complete a code challenge, and then to review that challenge when they come in. That’s my favorite way. That’s personally how I find I evaluate candidates best if I have to. Most of the time when I interview candidates, if I can get away with it, I don’t have them write a single line of code. This might be a little bit confrontational, this might be a little bit edgy, but here’s the deal, David. Let’s get real here.

David:

Bring it on, man!

Tim:

This is unique. This could be unique to my situation. When I interview candidates, I will find CodePen, I will find LinkedIn and GitHub and everything I can. If they give me their Twitter handle, I will see if they follow the same people that I follow in the industry. I will do those things, because I want to get a grasp at how in tune they are with the industry. I want to see code they’ve written and shared and contributed to. If all goes according to plan, by the time they come in in person, I know they’re capable of writing the type of code that I look for. If I don’t, that’s when the coding challenge goes out.

When they come in, we sit down and we have a conversation. What do you like about front-end development? What do you prioritize, performance or business goals? When you’re writing JavaScript, what’s your favorite way to organize the code? Talk to me about a challenging problem you’ve had to solve with CSS recently.

David:

One of my favorite questions to ask a candidate along those lines is, What’s the thing, when you inherit a codebase, that you’re most afraid of seeing in there?

Tim:

Oooh … a with statement? [Laughter]

That’s probably the nerdiest joke you’ll hear on this show, ever. That being said, I like to have this type of conversation with the candidate, because when I have this conversation, I can get a feel for, all right, when we’re talking about performance, you’ve mentioned HTTP2, or you’ve mentioned something like using transforms for animations in CSS. I look for those sorts of things that the candidate mentions, and if that happens — and this method has not failed me yet, and maybe I’ve spoken too soon and it’s going to come back to bite me — but if that happens, I have gotten through interviews and hired people without having them write out a line of code for me, because I’ve already done my research, and I’ve had that conversation where I hear them talk about development, the things they like, mentioning some technical things. So far that’s done the job for me.

What I will say (a note to people who work in the hiring process): if at any point you find yourself asking a candidate to answer a question that you yourself do not know the answer to, you should leave the room. That’s probably as confrontational as I’m going to be today.

David:

I’m going to confront you on that one, because I think that one of the most valuable things to do in an interview is to ask somebody a question you don’t know the answer to and work it out together.

Tim [27:50]:

Okay, so maybe I should have clarified here. That’s fair. You called me out. All right. Good. If I come into a room with a list of questions and one of these questions is, How do you reverse bytes in JavaScript? I just barely know the answer to that question. I think it’s with the tilde operator or something like that, but I could not tell you the answer to that question definitively.

David:

JavaScript engines are never optimized for bytes.

Tim:

There you go. So I barely even know what I’m talking about. If I’m asking that question to a candidate, there is one of reasons. I’m trying to figure out that question and I want to see how they approach this problem, how they think about it. Maybe we’ll come up with the answer together, or I’m trying to trick them, or I’m trying to see how smart are you. You have to be super smart, because I don’t want to work with someone who’s dumb.

David:

That’s fair. I know where you’re going with this.

Tim:

Yeah.

David:

I called you out, but I was kind of going backwards on you with this, because I’ve been in situations where I was interviewing for a front-end job at a company that did not have a front-end engineer to evaluate my skills. And they were asking me some very fundamental things about how HTML is structured, and they’d gotten all of the answers to the questions they were asking me from some Wikipedia page that they had found. This was long enough ago that the answers were out of date with what was contemporary HTML. I gave contemporary HTML answers and they said, Well no, that’s not exactly what our response says. It says …

You know, it was all about the fact that the person who was interviewing me actually did not know the skill set that I was being interviewed for.

You’re absolutely right. If you need to interview somebody for a skill set, you need to at least have understanding — you need to have somebody on staff who is capable of evaluating that skill set. If you’re bringing in somebody and you don’t, that’s a challenge.

Tim:

Yeah. And it’s a tough situation, and sometimes that will have to happen. If you’re hiring your first front-end hire, what do you do? That’s a tough situation, but I have been in interviews where the interviewer was what I could describe to be as hostile. Trying to trick you, or not really liking your vibe, or you know, just — You have to be this smart.

In those cases, if you find yourself to be in an interview, or if I were ever again to find myself in that type of interview, I’d probably just get up and walk out. Not all companies are perfect with great culture and nice people, and those interviews can be jarring and discouraging and upsetting, and sometimes if you find yourself in that situation, it’s really just not worth it to continue in such a negative situation.

David:

That’s true. One of the issues of course is, we’re engineers. Engineers are focused on working with the machine, not necessarily working with people, and may not be trained in how to interview. They may not be trained in interpersonal skills. Frequently I’ve come in situations where the companies just didn’t have the budget, the resources, or the talent on hand to provide interviewers who were comfortable working with candidates and helping them through and evaluating them in a way that was not off-putting.

Tim:

Yeah.

David:

Sometimes the most skilled, the most qualified candidate, the most qualified person inside the company to do the evaluation, may not be the most qualified person to talk to human beings.

Tim:

Yes. Here we’re going to go out and line up point number three: Every interview — and I’m going to stand by this statement — every interview should feel comfortable and friendly. Always. No matter what.

David:

Yes. That’s the goal.

Tim:

Every single interview should be accommodating, comfortable, friendly, nice and should never leave you feeling not worthy or bad about yourself or embarrassed, ever.

I have been on the wrong side of those interviews. I have been in interviews where it was very obviously ended early because the interviewer did not find my skills to be to their pinnacle of standards. It was just an awkward and terrible time. It’s never ever something I want to go through ever again. It was awful. I promised myself from then on, if I ever interview anybody ever technically, we’re going to be friends by the time we’re done.

David [31:54]:

We’ve gone over a bunch of stuff. Let’s see. We’ve got three main points. Can you summarize those points since you were the one writing them down as we went.

Tim:

Of course. Let me pull up my notebook. Do we have paper sound effects?

[Laughter]

Point one was: interview the company before they interview you — which means do your research, ask all of the questions, find out all the information you can, and generally just get all the information you want to have before the company starts to evaluate technically. That’s the goal, right? You don’t always have the option to get all of that information, but if you can, really try to interview the company first. Does that sound like a fair point one?

I think point number two was that the interview process is an expensive one, and you can use that to your advantage. Companies spend money interviewing you, and for example, if they put an offer out that is not satisfactory to you, kick it back. They’re not going to say, Forget it, we’re just going to start this whole long, grueling and financially draining process over again and bring someone all the way to this point. No. They will be very accommodating within reason, because it’s an expensive process for them, and you have every right to take advantage of that.

Point number three was that the interview process is an excellent indicator of how good the company is and how good the people in the company are. Point number three is that the interview process should always feel accommodating, friendly, and helpful. Even if you find out mid-interview that maybe you’re not technically proficient enough for the job, which has happened to me so many times, or it’s not the company for you, or maybe this isn’t a role you’re very interested in, you should at the very least come away from the process having learned something, a valuable lesson, maybe something extra about code, maybe something you can do in the future to improve, but you should always feel like it was not a waste of your time, and like it was not a sort of dejecting and rejectful feeling sort of process.

David:

Coming away from an interview where it’s been demonstrated to you that you’re not technically up to the job that they’re hiring for, that gives you an opportunity not only to ask a lot of questions about the things that you could learn next — you’re now talking to people who know all these things and you don’t, so that’s a great opportunity to do that — but at almost every job interview that I’ve ever had, I’ve come away from it with at least one or two new LinkedIn connections from people that I’ve met during the interviews who were interesting. I didn’t necessarily take the job, but I wanted to stay in touch with these people. That’s giving the company back something that they didn’t have before, which is a connection to your network, which is another very valuable thing that you bring.

Tim:

Yeah. Speaking of LinkedIn, I’m glad you brought that up. I’ll share this with everybody listening. One of the companies early on in my career that I interviewed for, that I turned out just not being technically proficient enough for by a long shot, was LinkedIn. I interviewed with LinkedIn for a front-end developer role. It was a video pair programming exercise, and I failed some of the more technical JavaScript questions, but it was the most friendly and accommodating and just generally nice interview that I have ever been on. The interviewer said, Listen, it turns out that you’re just not where we’re looking for you to be technically for this role, but please message me again in six months, and we’ll pick up right where we left off.

By the time the six months were over, I had found a different job and I was happy where I was, but I had never been so satisfied with an interview before. Why shouldn’t it always be that way?

David [35:45]:

Why shouldn’t it always be that way? It’s important to remember. You went into an interview for a job that, at the time, you weren’t qualified for, but because of the nature of the field that we’re in, qualification for a job can come in a few months of training on a specific framework or a specific language. You went in, and you were interviewed, and you were found lacking, and you survived! It didn’t kill you. It didn’t stop your prospects. It didn’t immediately send a red flag out to every hiring manager out there saying, Do not hire this person, he failed his interview at LinkedIn.

This is just something that you went through, and you moved to the next level. You moved to the next step, and now you’re continuing forward.

Tim:

It motivated me, because you know what I did, I went on Google Calendar, I looked six months ahead. I made myself a little reminder, Call LinkedIn again. Every day for the next six months, you know what I did? I studied JavaScript. I made CodePen demos. I worked really hard at it and I looked at stuff that I wouldn’t otherwise looked at because maybe it was boring or really hard, but I was motivated to do this, because someone sat on the other side of a computer and said, Hey, you can do this. In six months we’re going to do this again, and you’re going to be great then. That was super helpful.

David:

It indicates to you where you should be thinking. What direction to put your attention to. I remember an interview where I was introduced to my first recursion problem in the middle of an interview, and I didn’t know how to solve a recursion problem. I didn’t even know what kind of problem … I was doing this ridiculous, deeply nested … It was crap, I can tell you, but they explained to me at the interview, This is a recursion problem. You can tell because of this, this and this.

I went off, I studied it. I learned more about it. Now I’m working on a functional programming course in JavaScript for SitePoint around a lot of the topics that, if I hadn’t been introduced to it in that context, it wouldn’t have motivated me to go out and learn about it.

Tim:

Yeah, very true. We have our three points.

David:

I think those three points are good.

Tim:

Are there any other points we want to line up?

David:

I think the main point is: good luck, and remember how valuable your time is. Your time is something you can never get back, and you’re selling it to these companies very cheaply, considering what percentage of their money they’re giving to you, versus what percentage of your time you’re giving to them.

Tim:

Don’t undervalue your time or your salary.

---

Thank you so much for listening, everybody. We always enjoy getting to talk technology with all of you.

David:

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat, with production help from Ralph Mason. Please feel free to send us your comments on Twitter — @versioningshow — and give us a rating on iTunes and let us know how we’re doing.

Tim:

We’ll see you next time, and we hope you enjoyed this version.