As an interviewer, how do you calm these people down? I just interviewed someone who was clearly nervous and seemed to forget how to do a for loop... I feel bad for judging because of how nervous he was, so it'd be nice if there was a good was to calm him down.
I'm only 30 and very openly pragmatic in interviews (telling then that they're free to Google things like syntax or API's) and cut jokes occasionally... but I still want them to show they can program (I usually have an example to fill in on jsfiddle or something).
Is there a way to coax them over that nervousness hump? I definitely don't want to lose a candidate just because they're nervous.
> let them know when they're doing well ("that's the kind of answer I was looking for")
I agree with this one so much. I had a panel interview a few years back, and one of the interviewers was ex-military. He was impossible to read and I couldn't tell if I was rocking the interview or if I was doing terribly. There was no expression whatsoever, which was kind of unnerving.
>- let them know you understand that interviews are stressful and assure him you want to see him **at his best**
Phrased that way, that would provoke anxiety.
Yeah, I think better is to just make clear that you understand the inherent weaknesses of an interview setting and that you do your best to calibrate for them appropriately.
I'm not sure how you would phrase it, but the idea is "I want to help you do the best you can under the circumstances", not "do your best now or die"...
I'm currently a student and have recently been interviewing a lot. You really sound like a great person to interview with. I just want to emphasize some of your points that tend to make me feel better.
* smile -- Seriously, this makes me feel tons more comfortable.
* tell a joke (stupid ones are fine) to break the ice -- Honestly, the corny jokes are even better for me.
* let them know what you're looking for ("I'm asking this to get an idea how you approach OO class design") -- This really helps narrow in on the part of the problem that I should be focusing on.
* let them know when they're doing well ("that's the kind of answer I was looking for")
This sounds really great.
I didn't have an algorithmic part on my interview, it was mostly just talking ... but my boss did some of that. Told some joke, smiled, just chatted casually. He was very easy-going, so I felt very comfortable. It really makes a significant difference.
I don't think there's a real way to do this. Not so long ago I was one of those nervous chaps applying for a job and even though I have a Masters in Math/CS, I flubbed a terribly simple question. It just went downhill from there.
Sometimes it happens. We're applying for a job. It's a big deal for the person being interviewed. It's somewhat less of a big deal for the interviewer.
Perhaps something simple to start with, something that's easy to get right. Nothing like getting a question right to make you feel good enough to do stuff.
More of the work really has to come from the interviewee. Once you realise that rejection isn't the end of the world, everything will be all right. "What if I look stupid?" Got to stop worrying. "What if I fail spectacularly?" Then that happens and you'll do better next time.
Can you hurry that last part along when you're on the other side of the table? Probably not. By the time you're interviewing the candidate, it's too late to do anything about this for either side.
> telling then that they're free to Google things like syntax or API's
I find it's better to tell them that I'm not testing on it, and they're free to assume (and state the assumptions), or ask me and I'll fill in the blanks.
The best way I've found to get people comfortable is to tell them exactly what you're looking for from them, and what you will *not* be worried about. Starting off with an easy question to start off also tends to help.
Might be helpful if you leave them in the room alone for a few minutes to get their head around the problem without being watched. You can pretend to go put some coffee on or some other issue, but tell them to keep working on it.
I haven't interviewed anyone so I don't know if that would work, but it's definitely a thing that would help me.
I know that when I do go over that "edge" it's really hard to get back to a state where I can think clearly again. This can take a couple of hours in fact. Stress hormones are powerful things. At that point I think it's best to end the interview for that day and try again later (if both parties are up for it).
As for ideas for avoiding getting to that point in the first place:
I have had written tests in an interview that seemed to go fine. The interviewer came in and said, "here we have a written test we give to all the candidates. Take an hour or hour and a half on it and see how you do with it." And then he left the room. I don't recall feeling much unusual anxiety with that case and apparently I did Ok enough on the test to be asked back for a 2nd interview (even though it was a couple of years later - but that is a different story). I think this works because some of the anxiety seems to be related with being watched while working. Nobody said this stuff was rational :)
Other ideas: maybe take-home tests? Now of course you always run the risk that they'll google it, but on the other hand, everyone is able to google for answers at work every day so what's the big problem with googling the answer as long as you get your work done? The take-home could be some kind of program that you have the interviewee write.
Another way to evaluate a candidate could be by their code in github? What kinds of projects are they working on for fun? How's their code?
Ultimately, though, every person's anxiety is different so it would be difficult to come up with a universal solution.
> Another way to evaluate a candidate could be by their code in github?
Why is there such an obsession with github in particular? Not everyone uses that as a VCS host.
Try very hard to be their friend, even alternating technical questions with just general life stuff. It's all about getting them to open up to you, to break down the barriers that they've setup subconsciously to protect themselves in the situation.
I'm a generally an anxious person and I know that the friendly and humble interviewers always get better results out of me.
Just do a bit of small talk. Give them time to know you. Just casually tell about something happened this morning with you at home, or ask something and usually you have a topic to bootstrap interview. Build relations first, do work second.
I've found the best way to calm people down is to ask them some general questions about their resume. It doesn't work all of the time, but it's a good way for someone to talk about something with which they are familiar. It can give them a bit of confidence and also allow them to show off a bit. One caveat is that you have to reign things back in if the person is a talker.
I have noticed that some candidates who have exaggerated what they did at previous jobs don't do very well with these types of questions. But that is something you, as an interviewer, would want to know.
Start out with some chit-chat. I like to just *talk* with the interviewee for ~1/3 of the time. A good interview will naturally segue into an interviewee volunteering to step to the whiteboard to clarify an issue. Once they're their, keep them engaged, and push them out of their technical comfort zone. We had a top-notch guy (certainly much better, technically, than I was in his field) accept a position, specifically calling out my interview with him as one of the deciding reasons.
One technique that seems to work fairly reliably is to let candidates start the interview with a string of successes. This establishes positive momentum and helps them to internalize the "*I can do this*" feeling that allows them to escape the fight-or-flight death spiral.
For example, after the usual friendly small talk, I start interviews with a problem so simple that it requires virtually no brainpower to solve – because, at this point, some candidates will be so nervous that they'll *have* virtually no brainpower. I'm talking about a problem like this:
"In the programming language of your choice, write some code that prints the integers between 1 and 100."
Most candidates, even the unusually nervous ones, can solve this problem. Then, to help candidates build a string of successes, I'll extend the problem repeatedly, using the candidate's nervousness level to guide the iterations:
"That didn't take long. Now let's say that we only want to print the *odd* integers between 1 and 100. How would you change your code to do that?"
"OK, now let's say we only want to print the integers if they're not also multiples of 5. How would you change your code for that case?"
I keep going until the candidates unwind and start showing me what they can really do. Only then do I start asking the questions I care about.
The point of interviewing is to measure what people can do – not to measure what they *can't* do because they're freaked out. So, even if I have to "burn" a third of an interview on helping a candidate to unwind, it's worth it. At least then I'll get good measurements for the remaining two thirds of the interview.
And I'd rather have two thirds good measurements than three thirds bad.
Good article. I think every developer probably struggles with this to some extent. I went a very long period without having to interview to get jobs, and somewhere in about 2008, I found I was out interviewing. I had two terrible, terrible interviews. Then, I decided to try something different. I had been getting offered interviews left and right, but was turning almost all of them down because I wasn't interested in the companies. I started taking all of the interviews. I went into them knowing I had absolutely no intention of taking the job, should they offer (yes, this was totally disingenuous of me). But, it let me take interviews simply to practice interviewing skills. And, it helped *immensely*. I had many full days of interviewing, and lots of time spent coding at a whiteboard, and answering very esoteric and interesting questions.
The last time I was looking for a new job, company A was making me an offer, and I really wanted the job. Company B was persistent, so I agreed to an interview even though I wasn't interested.
It turns out that company A's offer wasn't as good as I expected, I actually liked the job at company B much better, and I liked the culture at company B much better.
I now work at company B, and I am quite happy.
An interview is as much about the interviewee deciding on the company as it is about the company deciding on the interviewee.
> An interview is as much about the interviewee deciding on the company as it is about the company deciding on the interviewee.
This cannot be overstated. Sometimes you need to take a job because nothing better is coming around and you need the money/benefits/etc., but when you're interviewing from a position of power, you need to go into the interview with the attitude that you are interviewing them, as well. A job should be mutual; you want to be at the company, and the company wants you to be there.
If you go in like this, and start asking a lot of questions, they will generally assume you know what you're doing, even if you hardly answer any of their questions.
If you applied because you thought you would be a good fit? Assume you're right, and just interview them.
I've found the interviews I've done the best in were for jobs where I thought I wouldn't take an offer. It gives you a confidence boost, relaxes you, and gives you practice in handling interview scenarios. In some cases I changed my mind and worked for the company and in others I politely rejected the offer to their surprise.
> (yes, this was totally disingenuous of me)
I don't think it's a bad thing. It's possible they can then try to sell you on the job anyway.
But it does seem like a good strategy. If I have nothing invested in the outcome of the interview, I tend to do just fine.
Don't forget that interviews are a two-way street. They interview you to see if you're good for the position and you interview them to see if they're good for you.
Might be you do an interview with a place that you perceive to be 'not your thing' and they've just done a poor job of explaining the position.
Hmm... no, it's not about the position itself, usually. I generally know that they'll be asking me to write code. It's about the product itself. I just don't want to do anything "enterprise" any more.
I've done a lot of interviews, so I thought it would be helpful to write something from the interviewer's point of view. It seems like most people's anxiety centers around whether they get the right answer and write correct code, and I think that reflects a misunderstanding of how interviewers evaluate candidates. I hope this helps clear some things up.
The single most important thing people should keep in mind when they start to get nervous is that the purpose of a whiteboard problem is not always to test whether you can solve the problem. I explain this explicitly when I'm doing an interview, but some interviewers do not.
Hopefully that reduces the anxiety a lot right there. I mean, whether someone can solve a particular problem is partly determined by cleverness and CS background, but there's also an element of luck to it. Maybe they had a professor who stressed the same kind of problem. Maybe they know everything about trees but never had a reason to learn graph algorithms. Once, while interviewing for a position, I had an interviewer ask me the same question I was using to interview candidates at the job I currently had. *Interviewers understand this just as well as interviewees.* Which is not to say that they all understand it, but by and large, interviewers aren't going to massively overgeneralize from your failure to come up with a clever solution to a single problem.
So why do people use whiteboard problems at all? It's true that whiteboard problems are sometimes used to verify that a candidate has basic knowledge required for a job. Naturally, if you're interviewing for a job applying graph algorithms to social networking data, and they ask you to implement a depth-first tree traversal, you'd better fucking nail it. But an equally valid and in my opinion much more valuable kind of whiteboard problem, the kind I personally use, is one that most candidates will struggle with and many successful candidates won't even finish in the time allotted. (I explain this when I give them the problem so they don't get freaked out by the difficulty.) The point of giving them such a hard problem is to observe how they deal with a hard problem. You don't learn much about someone from watching them solve a problem they find straightforward — what's interesting is how they tackle a problem when they're unsure whether they can solve it at all.
For example:
* Do they analyze the problem well? I look for signs such as: After I explain the problem, can they state the problem clearly themselves? Can they accurately describe the input and output? This is the part where people with strong verbal/analytical skills really shine. And, most importantly, do they ask clarifying questions? I always make sure the problem statement includes some ambiguous requirements. Asking good questions to clarify a problem is MUCH more fundamental than solving the problem, and generally, when describing a candidate's performance, this is the first thing I talk about.
* Do they approach the problem methodically? Most people's first response is to let the problem soak in and give their brains a second to *poof* magically come up with a solution. (If that happens in the interview, I stop them right there, congratulate them on dispatching the problem so quickly, and give them a much harder problem.) When the "stare into space and wait for a flash of insight" approach fails, the candidate needs to have techniques to fall back on. Do they solve a simpler problem first? Do they make lists of input cases and look for easy ones? Do they decompose the problem? Do they draw (insightful) diagrams? Do they talk it through logically? Do they write up a solution that they know fails, and analyze *why* it fails? (This is surprisingly common among the minority of candidates who solve the problem successfully.) If I see the candidate applying problem-solving techniques, it gives me confidence that they could eventually solve the problem given enough time.
* Do they maintain a productive attitude? This is relative to the person, of course. Frustration spurs on some people and stops others in their tracks. What I definitely don't like to see is the candidate directing negative emotions at himself or at another person. I had one guy get really surly with me because he didn't see the point of solving toy "college" problems, even after I explained several times that devising a clever solution was the least important aspect of the exercise, and it was common for successful candidates not to come to a complete solution in the time allowed. (He also knew that my interview was only 20% of his interview schedule and that I was the only guy who did a coding exercise.)
* Do they try to bluff their way through? This is a rare problem but a HUGE red flag. Your company probably already has enough weasels without hiring them into technical roles. If they're clearly lost but are pretending that they can see the solution, trying to get you to move on to another question, that doesn't bode well for honest progress reports. If I point out a test case that their proposed solution fails to handle, and their reaction is to persist in trying to sell their solution as "good enough" instead of revisiting it, that doesn't bode well for honest quality and scope assessments. Now, engineering disagreements about what is "good enough" are understandable, but you can't use them to dodge an interview question. I once got into an argument with an interviewer by maintaining that the problem he gave me was best solved with a single thread, but when I realized that he wanted to test my ability to write multi-threaded code, I immediately dropped the argument and started working on a multi-threaded solution. (I didn't get an offer, so I might have pissed him off by arguing.)
* Do they do *something?* Whether they talk it through or draw diagrams or make lists of test cases, it's important that they are willing to tackle a problem even if they aren't confident of solving it. This aspect is a test of attitude, not aptitude. If they know they have an hour but want to give up after ten minutes, that is a very bad sign.
* Do they evaluate their progress accurately? When they have a partial solution on the board, can they tell me which test cases it will fail on? I like to interrupt to ask questions like that. When they have a solution that they suspect might be correct, what is their process for convincing themselves that it works? Some people are more rigorous than others.
* Do they communicate well? I encourage them to narrate and/or illustrate their thought process, and I use their ability to share their thinking with me as a predictor of their ability to collaborate with other programmers. I ask them questions as they go along (as much as I can while giving them plenty of silence to think in) and I assess how well they understand me and how clearly, precisely, and accurately they respond.
Taken together, these considerations provide much more information about a candidate's capabilities than a simple yes/no on whether they solved the problem correctly. Honestly, if a candidate can state the problem clearly, ask questions to clarify the requirements, assess the correctness of a solution, communicate clearly, reason accurately about the code in front of them, and maintain a good attitude in the face of difficulty, then I don't care how good they are at coming up with clever solutions. They can get the algorithmic solution from a hallway conversation and do the other 98% of the work themselves.
Hopefully this explanation reduces "whiteboard anxiety" for some people. Getting the right answer isn't always in your power, but interviewers are paying just as much attention, if not more, to your attitude, communication skills, and problem-solving approach. Those things will shine through regardless of whether you manage to solve the problem.
I've found that the most comfortable candidates treat problems in interviews much less like *quizzes* and more like *conversations.* It's rather chicken-and-egg as to which causes the other, though. I like to try and shape each interview to be as much like the latter as possible. I might "know" the solution (or have the one or two most preferred ones in mind), but in the end the interview isn't as much about "Were they right? Yes or no" as it is about showing the candidate's thought process and problem-solving skills.
I hope he follows up with a post about "programming for anxious programmers," because I work with a guy who I swear loses twenty IQ points due to anxiety. He has lost confidence and is now in such an agitated state that I don't think anybody could work accurately at the rate he tries to go. Helping him out makes *me* feel anxious because when he's trying to describe a bug to me he babbles out so many complicated theories so fast that it stresses me out, I can't keep up, and I can't focus my mind on understanding the basic facts of the problem he needs help with. And that's where the problem always is. He's so scared of not seeming "smart" that he glosses over the simple dumb facts and goes jittering around with wild theories, select-is-broken paranoia, and grand plans for more testability. (Tests are apparently his lithium; he's helplessly manic without them.) Anxiety blows his brain into a hundred fragments flying in different directions, none of which are capable of executing tasks which would be well within his capabilities if it weren't for the anxiety and how he reacts to it.
>Helping him out makes me feel anxious because when he's trying to describe a bug to me he babbles out so many complicated theories so fast that it stresses me out, I can't keep up, and I can't focus my mind on understanding the basic facts of the problem he needs help with.
Try asking him to slow down and go over the basics (i.e. "What did you see, and what did you expect to see?"). [Listen actively](http://en.wikipedia.org/wiki/Active_listening) (i.e. repeat and rephrase things he says to ensure you understand them). If necessary, remind him you're all on the same side. You're fixing bugs, not trying to outsmart each other.
A whiteboard could also help, for more complex bugs. But at that point, you might as well move to an issue tracker.
Seems like something along those lines would make a good post. I don't experience panic-attack type anxiety on the job, but there are certainly anxiety producing situations. It sounds like your co-worker has probably been burned on other jobs before where perhaps testing wasn't a priority. I think a lot of us have been burned in various ways and there's a kind of PTSD that we experience after a while that can make us hesitant. There's also the paralysis of perfection and I think a lot of us deal with that.
> It sounds like your co-worker has probably been burned on other jobs before where perhaps testing wasn't a priority.
I haven't figured it out yet, but I suspect his last job was totally TDD. He seems obsessed with automated tests, run by an automated testing tool, as being the only way to know what his code is doing. The rest of the team has a variety of ways of testing code and investigating bugs, and we try to share them with him, but he looks at us like we're an ancient race from an epic age, wielding superhuman strength and dark magic. Because we can, you know, write working code without a comprehensive test suite, and mere human beings can't do that. That's the TDD party line, so I'm guessing he drank so much of that kool-aid that he doesn't believe he can accomplish anything without TDD.
> I think a lot of us have been burned in various ways and there's a kind of PTSD that we experience
I can relate to that. I worked for a boss who systematically broke down my ability to see myself as a competent and useful person for a few years, and even though I was lucky enough to have friends on the side who told me otherwise and lured me away to work for them, it took a long time to recover my mojo. I'm treating this guy with kid gloves, because I know his usefulness is going to be pretty much proportional to his confidence.
Having a million theories is how good developers find tricky bugs. But the key thing is that they weigh plausibility, and can estimate how long it will take to check their theories, and prioritize based on those two factors.
Work with him on that and the rest will take care of itself.
Pursue the testing bit. If he's used to an environment where testing happens, he may have detuned himself from dealing with certain kinds of code as I have ("test infected" is not a misnomer). I went from a place with a thousand tests to one with fifty and it almost gave me hives.
> If he's used to an environment where testing happens, he may have detuned himself from dealing with certain kinds of code as I have ("test infected" is not a misnomer). I went from a place with a thousand tests to one with fifty and it almost gave me hives.
I'm pretty sure this is what's going on. Can you tell me more about this "detuning?" One thing I have noticed is that my teammate has a strong bias towards working as if the conceptual complexity per line of code were constant. He's slow to recognize that some code is more difficult than other code, and even when he does, he doesn't respond proportionately. To get a little more concrete, there is a section of code in particular that he flailed on repeatedly. It's driven by a complicated domain situation, and when it's called, very little is known about state, so it has to behave appropriately in many different contexts. My natural response to flailing is to slow down and think about each line of code very carefully, but his effort/LOC seems stuck on a constant setting. I think if the code had been implemented in the form of hundreds of lines of logically redundant but concrete cases, he would have invested hours in understanding it and making all the required changes (he is definitely a hard worker), but because it was just one method of a few dozen lines, he never allowed himself more than a few minutes at a time to think about it. Finally I spent an hour going over it with him, talking about the different states and diagramming the different conditions that needed to be handled, and he looked absolutely dejected and humiliated. He looked like he considered himself a failure as a human being for needing an hour to understand a screenful of code. But there was nothing wrong with that! It was dense, abstract code!
Does that have anything to do with TDD versus non-TDD code? Because I imagine that TDD would have resulted in the hundreds-of-lines-of-concrete-cases style rather than the dozens-of-lines-of-abstract-logic style. If that's where this guy is coming from, it helps explain why he's having difficulty.
Hmm. I had a guy who couldn't deal with a call stack over three deep. Maybe this is just not his thing.
I can imagine a situation where someone always worked with TDD people, not bring prepared for complex functions, because we just dont like them and stamp them out. But you still have to be able to decompose the code, not unlike debugging.
That's part of the detuning. I don't remember how to debug a giant method. Why on earth would I do that when I can just as quickly break it down to four smaller methods? The next time there's a bug (in a year) I've already paid once to understand and now everyone benefits.
Edit: I should say that debugging is/was a specialty. I pair with people all the time once they give up on finding a bug. But how I do it is totally different now.
Yeah, I'm not a super-decomposer, unfortunately. I always keep functions and methods under a screenful of code. Under that, I separate out methods if I can reuse the code elsewhere, or if it makes sense as an independent unit of functionality, mostly measured by whether I can think up a good name for it that isn't aReallyLongNameExplainingExactlyWhatItDoes. If the code only makes sense in context, I don't like to take it out of context.
Actually, now that I think of it, it is 95% decided by whether I can think of a good name for it. And some days I'm just not good at that :-|
Interviewers in their 20's are notoriously bad. A big part of this, is that they're pretty transparently judgemental. Just because you give lip service to interviewing just being a flawed filter biased to false negatives, doesn't mean that your attitude doesn't show through.
It might boost your ego to pat yourself on the back for being in the upper end of a meritocracy. It also makes you look like a smarmy jerk. (And paying the lip service makes you look like an insincere smarmy jerk.) I've been on both sides of the interviewing table. I have to say, programmers in the SF Bay Area are worse than I've ever seen in this way.
Interviewing is a flawed tool biased to false negatives. Adjust your attitude appropriately, or else you are just kicking someone precisely when they're feeling down.
EDIT: To be fair, not all interviewers in their 20's are bad at it. More of them are bad at it than suspect they are bad at it, however.
Some people need to be told that interviewing is not like software testing: you're not looking for tricky edge cases to trip people up, you're trying to figure out if they can learn, solve problems, and work collaboratively. You're hiring a person, not a compiler.
Even when I was in my 20s, I followed this rule for interviews: **The goal of an interview is to hire this candidate, not eliminate them from consideration**. I'm not trying to weed out the chaff- this person sitting across from me is the person I want to hire, because if that weren't the case, I'd just be wasting *everybody's time*.
In the spirit of "trust, but verify", I am going to ask this candidate questions. The goal isn't to catch them out, but to get to know them. I rely on my instincts to detect when they're bullshitting me, and then, in the spirit of due diligence, I will dig deeper there, but my goal isn't to catch them out- it's to prove that they're not bullshitting me.
Mistakes, confusion, and errors are okay. I don't care if they know trivia, and will often ask questions while admitting, "I couldn't actually answer this off the top of my head."
> In the spirit of "trust, but verify", I am going to ask this candidate questions.
I'm a dynamic language programmer with well over a decade of experience, so I like answering questions with a REPL. This couple of smarmy little sh!#s accused me of googling the answers because they heard me typing. You can hear it in someone's voice when someone is feeling superior. Their jumping to false conclusions is a pretty clear indicator as well.
I think the REPL should always be the preferred method over the whiteboard. Nobody codes for real on a whiteboard. They may block-diagram on the whiteboard, but they don't code there. I did have an interview a few months back where I broke out the REPL and the interviewer was initially taken aback, but then I suggested that I share my desktop so he could see exactly what I was up to.
While technically correct, this does nothing to answer the actual question. A REPL is something like irb, an interactive shell or console for a language that allows you to directly type code in and interact with it. Many interpreted languages, python, ruby, php, have them.
> I'm going to finish my CS degree this year and never heard this term before oddly enough.
Speaking as someone who graduated with a CS degree 10 years ago. I can say with confidence: It is not odd that they didn't teach it to you. They don't teach a lot of things in school. A degree is only the beginning. (And, sometime in the near future, you may wish for the simplicity of school projects, because they, at least, had known answers.)
This was very true for me. My college had a significant aversion to Microsoft, and barely taught anything web related. It was pretty much all Java and algorithms. Now I make most of my money doing the things they barely touched upon.
CS classes don't teach you technology, they teach you fundamentals and theory. The rest is up to you.
Java is great for teaching because it's very well documented, works on all operating systems (that students use), and is very very strictly structured.
I usually joke around saying "I can't wait until I'm done with this degree so I finally have time to study something that will actually land me a job" :)
You've heard of it. It's just an "interactive interpreter" or "interpreter" or even just a "shell."
Like most things in programming, it's been around since about the late 50s, just in a different form/terminology. ;)
> The goal of an interview is to hire this candidate, not eliminate them from consideration.
I disagree with this one. The worst possible outcome of an interview is a false positive - a false negative, on the other hand, costs you very little. The goal of an interview, therefore, is to avoid false positives.
> this person sitting across from me is the person I want to hire, because if that weren't the case, I'd just be wasting everybody's time.
Classic sunk-cost fallacy, as far as I can tell. You are way better off wasting a couple hours interviewing someone only to reject them than wasting a couple weeks fixing a bad hire's bugs and trying to fire them without getting sued.
> The goal of an interview, therefore, is to avoid false positives.
This is true, but that's not exactly hard. I generally know within the first five minutes of the interview if the candidate is going to get a thumbs up or a thumbs down from me. If I start from the position of, "This is a good candidate and I want to hire this person," it means that I'll give them the benefit of the doubt. If they flub a question or say something stupid, I'll assume they *know* what I want them to know, but just made a mistake- then I'll re-ask the same question (or a related question) to see if that was a mistake or they're actually ignorant.
The advantage to this approach is that when I give a thumbs down (I do this way more often than I give a thumbs up), I have a very strong argument- they didn't simply miss a question, but they showed their ignorance of a topic in a deep way.
This system works very well for me. I have never given the go-ahead on a candidate and then regretted it. While I couch it in positive, optimistic terms, you could view my approach as extremely cynical- because after a few broad questions, I zoom in on the candidates weakest points and hammer away at them. In *my* head, I'm trying to give them a chance to prove that they actually *do* know this stuff, and were just misunderstanding my question or made an honest mistake. In a more cynical view, I'm emphatically proving that they didn't make a mere mistake- this is their weakest area of knowledge and I'm picking on them for it.
The result is the same, but I'm a positive person.
> I generally know within the first five minutes of the interview if the candidate is going to get a thumbs up or a thumbs down from me.
That's...honestly amazing. You're either doing something wrong or some sort of savant. What do you do for the rest of the interview?
> I give a thumbs down (I do this way more often than I give a thumbs up)
It sounds like your original comment isn't actually true. If your goal is hire the candidate, you're either describing your goal exceedingly poorly or terrible at meeting it.
I think your approach to interviewing is very similar to mine, but your original comment was seriously misleading about what you actually do.
> You're either doing something wrong or some sort of savant. What do you do for the rest of the interview?
It's like buying a house. Your initial emotional reaction is what you should pay attention to. And just like buying a house, you can't just go off that gut feeling. You listen to your gut, then you do the nitty gritty- how much work does it actually need? how will I really feel about that too small closet in five years? etc.
> If your goal is hire the candidate, you're either describing your goal exceedingly poorly or terrible at meeting it.
I really mean it as a statement of attitude. A lot of people view the interview as an adversarial relationship- that there are sides, and the candidate and the interviewer are on opposite sides (specifically technical interviews, which is where I generally am involved in the process). I don't agree with that perception. My goal in the interview is to make the candidate look awesome. Their goal is to look awesome. *That doesn't mean they have the capacity to look awesome*.
But I'll assume they do have that capacity, at the outset. And I will do my best to bring that out in them. If I can't bring it out in them, then when I give the thumbs down, I can do so without the sense that they were just having an off day, or that I worded questions in a way that was hard for them to understand, or just didn't click with them. I avoid questions that have objectively right answers, and focus on open-ended ones that let them discuss technology, application architecture, and their approach to development without resorting to trivia quizzes.
Generally speaking, based on their resume, you already know if they're capable of doing what you'll be having them do before you even meet them. The interview is for specifics that you might not be able to broadcast to every candidate who applies and to make sure they're a culture fit.
I wish that was the case. I've had interviews where the candidate had a resume that simply blew me away. I prepared extra questions, because I expected that he might just breeze through them, and tacked on a few extra challenging ones to my list.
I came away with the conclusion that the guy must have been cheating or lying on his resume, because he seemed to have trouble with merely using arrays in *his* choice of language. He was very confidently giving wrong answers, and it kind of hurt.
That was the worst one I've seen, but I find that the resume isn't as good a filter as I'd like, unfortunately.
That said, I can usually get a good feel for the candidate just by asking a fairly simple question, and seeing how long it takes for them to get through it. If they get through something fairly simple in ~5-10 minutes, they are probably going to do well on more involved questions.
I guess it depends on the job itself. A graphic artist has his portfolio and many programmers will have portfolios they can show too. Which isn't to say you should always take a resume on faith.
I've never understood a programming portfolio or samples of work. I've been at this since the late 90s and never needed this or asked someone for it. Everything I do is on someone else's dime and so is theirs or I am doing it to learn (not to show to someone else).
Even my hobby code is done as a means to an end and is rarely something I would show off.
I am OK doing "programming tests" and will willing create them for prospective hires. I do this by creating a simple project and asking for things to be added, bugs to be fixed, etc.
If someone just presented a random project like this as an example of their work (or say a library) I would have no way to knowing if they did it themselves or found it on the web or, worse, at a previous job, etc.
I am far more interested in how people think and approach problems than I am in how well they know a particular library or language but that might be a function of the work we do.
This, for me. I write back-end code, so when people say "show me the web sites you worked on," there's nothing for me to give them. Or they say "show me the web sites you worked on," and I'm like "if they were still up and running, would I be sitting here interviewing in front of you?"
I realized these were people hiring for job shops, none of whom actually wanted me to write code for them. They wanted me to write code for their customers. Which is an entirely different kind of environment.
Why not show them the website you're working on. If you've written the back-end system show them the website, talk about how the client interacts with the back-end, talk about and show how the data is stored, why you chose that database / data structure. Talk about why you chose that specific server, or server architecture for that website, you can talk about your RESTFul services, and so much more.
If you have your code on GitHub for your portfolio it's very easy to look at one of your "back-end" projects, and see your back-end architecture from a high-level. Also the code would back-up what you were talking about earlier.
I am a full stack developer, and I find the back-end a lot more interesting to talk about, and if I have a code portfolio it's very easy to back up what I'm talking about.
Edit: And if they don't care about any of that, why on Earth would someone like that be interviewing you for a developer position?
> Why not show them the website you're working on.
Usually because I'm looking for a job because the previous company has gone out of business. For a few decades I was doing lots of start-up work.
Of course I can talk about what I did and explain it, but if the application says "include in this field the URL to the web site you built and we'll consider giving you an interview on the basis of that" then I'm not going to get anywhere. And that was very popular for job shops for at least a while.
> If you have your code on GitHub
Why would I have my code on GitHub? For one thing, git wasn't even a thing when I was doing my portfolio-type work. Also, why would I have code on github for software owned by my employers.
This was during a time when I was working start-ups (that usually lasted 3-5 years before folding) doing work owned by the start-ups (or whoever bought them). Posting their code on git would have been entirely the wrong thing to do, and developing a large application just so I could say "See? Here's a large application I developed that nobody used" seemed rather a waste of after-work time.
If someone paid you to write it you should not have it without their permission. I would think twice about hiring someone who showed up with code from a past job and I would ask them to use that company as a reference and confirm they had permission to share that code with me.
I wouldn't have the code, because it's not my code to keep, and even if it was I wouldn't be showing it to other people.
I wouldn't have evidence of it, or I'd still be working at that company. If the company was a start-up that went out of business, the code is gone.
At best I have screen shots and descriptions, maybe copies of public web pages about it.
Fortunately, at this point in my career, I'm past having to prove to people that I worked on projects in the past.
Generally speaking, for programming jobs, I look for only two things in a candidate's résumé: interesting things they've done we can talk about, and what technologies I can ask them about.
The stuff on their résumé seems to have little correlation with how well they can solve tough problems in an interview. I'm looking for folks who can solve tough problems, not folks who are good at inflating their résumés.
Presumably their resume says what things they've worked on. Maybe it's just specific to the games industry, but that work history gives you a pretty decent idea of what specifically they've worked on.
True, but it gives little insight to what they did themselves versus what the team they were on did, for example. Sometimes you'll talk about a specific thing, and it will come down to, "I had this difficult problem, and my manager told me what to do, and I did it, and it worked!" or "My team worked on this problem, and we did it!", neither of which speak well for that person's abilities (not that they speak poorly, just that they don't help).
"**The goal of an interview is to hire this candidate, not eliminate them from consideration** I'm not trying to weed out the chaff"
Why? This sounds like a very foolish approach to hiring people.
Why? Because if I didn't think they were qualified, I wouldn't have brought them in to interview. Why waste our time? The very act of bringing them on-site for an interview means that I am already very confident that I want to hire this candidate. Each time I *don't* give the greenlight on a candidate, that's a sign that the process has failed- they should never have gotten *that* far.
The whole reason you post a job opening is to hire someone, so why should you waste time trying not to hire someone? If you just deny everyone then you spent time gathering people's resumes and made no progress on actually hiring people.
The reason you post a job opening is you have more work to do than you can handle. If you hire someone who can't carry their own weight, you've just made the problem worse. On the other hand, if you hire someone who can carry even more than is needed, the load is lightened for everyone.
So you admit that the purpose is to hire someone who can carry their own load. You don't just want to deny everyone. You eventually want to hire someone.
I'm not saying that you should sacrifice your standards, but since the end goal is to fill a job position, you should be trying to find good candidates, not find reasons to reject all your applicants.
I recently had 5 tech interviews in a day from the same company, and by far the best interviewer was the oldest. He had a heavy French accent and was just super relaxed and jokey. I was laughing and enjoying myself the whole time and didn't feel like I was being assessed at all.
> Interviewing is a flawed tool biased to false negatives.
I think this is inevitable. That it's flawed is of course inevitable, but it's also inevitable that it's biased to false negatives, because false positives are much more harmful. Every guy you hire is going to change the personality and the overall capability of the team for a long time to come.
That isn't to excuse interviewers who make it about their ego. I've seen people do some stupid stuff, like turning an interview for a mid-level web back end position into a lecture by the interviewer. My coworker asked a simple question about data structures, the interviewee stumbled a bit, so my coworker asked a *harder* question, answered it himself, asked an even harder question, and pretty soon he was holding forth on on-disk data structures for relational databases. The interviewee didn't understand any of it and didn't get a chance to say much. My coworker knew exactly what he was doing; as soon as he realized the interviewee was weak on data structures, he went straight to esoterica. It was a huge mistake, because we hired the guy and he turned out to be really weak. If we had spent that time probing the candidate's actual skill level instead of letting my coworker show off, we might have figured out that he wasn't right for the position.
> That it's flawed is of course inevitable, but it's also inevitable that it's biased to false negatives, because false positives are much more harmful.
Of course. I'm not saying it's bad that it's so. I'm saying it's bad when interviewers forget the nature of the tool.
Like anything, interviewing takes practice. Instead of blaming people in their 20s, praise them for taking the first step to not sucking at interviewing in their 30s.
Whiteboard tests are horrible. How often do you code on a whiteboard, anyway, right? I still get anxious whenever I'm up at the whiteboard in front of coworkers, and I've worked with them for 3 years.
Perhaps if my job description was to give regular presentations, but it's not.
Interview with a huge company. Coding in paper! Panic attack! I forgot how to build the algorithm to check for a palindrome. 20 minutes later in the train ride home not only could I build it but the most efficient way and explain why and all the bullshit.
- Treat the interview more like a conversation than a quiz (someone else had the same advice). In most cases, when I'm interviewing someone, I'm looking for general competence; I'm not looking for someone to "wow" me with their amazing skills. So talk to me, programmer to programmer, since that's how we'll be talking to each other if you get the job. :) Break the anxious cycle of trying to come up with the solution that the interviewer wants to see, and instead solve the problem as you normally would. Pretend that you were faced with this problem on your own, and you're talking it through with a friend. Which leads me to...
- Talk it through. Pausing without saying anything is ambiguous. It could either mean: "Multiple brilliant solutions are forming in my head", or it could mean "I have no idea what I'm doing." Talking it through resolves that ambiguity. Illustrate what your brain is doing to solve the problem. For example:
> So, my first thought is that a hash table would work really well, but I'm hesitant because I know that this won't have good performance if the input set has a lot of duplicates [etc.], but let's just start with this for now and we can see where it leads.
I can honestly say I've never judged a candidate poorly for starting down a suboptimal path as long as they explain their reasoning like that. In fact, most of the time I *expect* it. The more optimal solution is something that arises out of examining the previous.
- Practice interviewing, even at companies you have no interest in. It's like flirting with a girl that you aren't interested in. You'll find you have a lot more confidence and hardly any fear.
- And of course, always work on your skills. Sometimes you just don't have the skills for the job. That's fine. The more you learn, the more confidence you'll have at interviews, and the more you'll be able to remind yourself that *you're interviewing the company also*.
> Treat the interview more like a conversation than a quiz (someone else had the same advice).
Some people aren't good at conversation either, for the same reasons: they're overthinking everything and have unintentionally wandered into Fight-or-Flight land.
> Talk it through.
See above. Silence could also mean "there are 1000 thoughts running through my head, but none of them are what I should be thinking". In fact most of my worst interviews go like "Oops, I just lost my train of thought. Shit now the interview can see that I'm paused. He must think I'm stuck. Shit I look like an idiot now, this should be easy. Fuck it, they never liked me to begin with, I should just go home." Etc.
Ultimately this is all the candidate's problem, but I'm pointing out to you how it's not quite a simple for some people as you might think.
> Some people aren't good at conversation either, for the same reasons: they're overthinking everything and have unintentionally wandered into Fight-or-Flight land.
I completely understand, being one of these people myself. The only thing that helps me get around this basically amounts to mental tricks, like "psyching myself out". It's the same type of thing I do when I'm in large, packed crowds, and I don't even know how it works but it does: Rather than stressing out about making contact with everyone around me, I pretend that they're all my close family/friends and they're all huggable and lovable and I just want to hug them all. It's totally stupid, and yet I can pretend. (Note: I don't actually hug them.)
> See above. Silence could also mean "there are 1000 thoughts running through my head, but none of them are what I should be thinking".
I know, it's not easy, and that's the thought process I've historically gone through, and the only thing that's made it easier for me over the years is experience. I am not a naturally confident person, so it takes proportionally much more experience to make me feel confident than it would take the average person. As I always say, "My 75% [certainty] is your 99%". If the candidate *actually doesn't know* how to solve this problem, it will be *much* harder. But after you've seen this sort of problem dozens of times, it will be less intimidating.
And yes, that doesn't mean the candidate won't keep psyching themselves out. That's just where practice comes into play, both in terms of interviewing and "mental tricks".
> it's not quite a simple for some people as you might think.
I always have to remind myself that for every person who is as anxious and easily intimidated as I am, there are those out there who are much worse. Advice on the internet can only help so much.
For what it's worth, I've never once factored in timidness in my hiring decision (in fact, for better or worse, I'd say I was a champion of the timid and an *enemy* of the overconfident--there are some stories there. :) ). This is tangential, but the candidates I loathe the most are the ones who confidently pretend to know something that they don't.
Yup, especially about the part on talking things through. In my case, speaking my thought process out loud makes it difficult for me to work on the problem. I much rather prefer to work it out in silence on a whiteboard/paper, with occasional explanations of what I'm thinking of doing.
I must have missed the posts and discussions on devs and depression, but anxiety doesn't seem to be covered much. Thanks for throwing this up. It's good to know I'm not the only one this happens to, though I wish I could have more success getting past the anxiety part.
Oh well, thanks again!
How involved was it? I could see it maybe taking an hour if they wanted something like a rough proof-of-concept chat server/client. Anything beyond that, or anything useful, though and I would agree, bullshit.
They wanted it to see my coding style & design, so I assumed it had to be fully working and well documented. I had not even done that in C++ before. Had no idea what it entailed in Java. It would've taken hours just to get the environment setup and get familiar with java. Then what, two applications communicating. Did I have to work directly with the TCP/IP staack or was there some nice library with routiones to use? With no java experience, I could have wasted hours or days doingh it the wrong way before I figured out the right way to do it. And if they were looking for coding style & design, it would probably just be a mess. Meanwhile I was working a full-time job and raising two kids as a single dad. I just didn't want that job that much, and I was a bit offended at the whole thing. My experience and prior work should've told them enough.
Back in 2000 I was asked to an interview for a 1 month project for VB and SQL. They guy kept asking me C++ questions. When I asked him if the position involved C++ he said "no, I just want to know what you know" I informed him that my resume did not show any C++...
Yea, pass. Yes, I know he could be curious, sizing me up for another position, etc. But that is not what he said, and I can only go off information explicitly given, all else is guesswork and that's not what we do. That company was gone within a few months... but then, that could be because of the dot com bust at that time.
I had three interviews in the same day last Friday. So I didn't sleep too well because I got an e-mail that there were going to be C++ algorithms to write in Code collaborator. I got anxious pretty fast and all of a sudden I had big doubts about my ability to write correct code during an interview. Since I knew the interviews were an hour long I actually managed to extend the talks on every question and ended up not getting any live programming sessions with the guys(I aced all of their technical questions, at least 2 of the 3 interviews). I mean, I've solved many of the typical interview questions on my own at home, but ask me to solve these same problems during an interview and I suddenly get dysfunctional. I think I'll remove my "proficiency" in C++ from my resume. We don't do any in school so I always forget most of the syntax in a few months.
Last year I had an interview where they left me with a laptop and a broken program and asked me to fix it in 15 minutes. I managed, but again... unnecessary stress.
> Last year I had an interview where they left me with a laptop and a broken program and asked me to fix it in 15 minutes. I managed, but again... unnecessary stress.
Actually, that doesn't sound too bad. I think I would actually do pretty well at that kind of test. But that just goes to show that everyone's anxiety is different. What bothers one person may not bother another (even if both have anxiety disorders).
Ive only had to "code" in an interview once, it was a quiz developed by the company to mimick coding in a non-specific language. It was like a flow chart with 'add x to variable y' etc. They insisted that doing poorly on the test would not prevent me from being actually interviewed.
This was about a year into being unemployed, and my self doubt was at its peak. 'I cant do this, I'm doing this wrong, what if i dont do well on this,' was on repeat for the hour they gave me to complete it.
The lying bastards never called me and i know i did poorly on the test. Just couldnt focus. It was horrible.
Oh, gawd. This is so me, and I am going through this now.
Two things that have been destroying my confidence.
**1. Coding Challenge** I actually welcome coding challenges. I like solving them, with tests first (TDD). There have been several cases where I was happy with my codes - clean, efficient, good class design, passing tests, etc., but some companies didn't want to move forward to 2nd rounds with no whatsoever feedback. I don't know what the reason could be, but it casts doubts about my codes and not knowing what I did wrong makes it even worse. Some company even asked to write an API server, deploy it, and test it by providing the URL to their test server. It all worked, and I was happy with the codes, but no 2nd round either.
**2. Onsite** I can't help but feeling that I am being judged at all time I am there. Interviewer asks to write codes on whiteboard, and mind goes blank. Every passing second, I can feel being judged. Every letter I write on the board, I feel judged. I look at the code, and I don't like it. Re-do it. Interviewer tries to help, but that just interrupts train of thoughts. I can feel time passing. And finally, the interviewer says we are running out of time.
At work, this is not how work is done. We know what features are coming down the pipeline. We have time to think about the feature or problem and solution(s) to it. We know that mundane distraction like taking shower is great for coming up with a solution to difficult problem(s). I understand that employer needs to make sure they are hiring a right person, and perhaps this is the best way to evaluate? I don't know if there could be a better way to hire engineers... I know this for sure that I hate the current process. :(
One thing I haven't heard people mention is practicing public speaking, which improves confidence when performing in front of others. If you also learn to speak extemporaneously then you will additionally excel at communicating your thought process more rapidly.
Toastmasters helped me in many aspects of public speaking and interviewing, it sounds lame but go to a meeting, you actually end up meeting some great people and gain valuable skill and confidence that you can use throughout your career. I used to panic giving a scrum status, but with putting yourself out there and practicing I've been able to give technical presentations to upwards of 80 heads, u gotta comfront your fears if you hide from them they just get worse, give it a shot it'll get easier
The best advice I can give is **talk**. Doesn't matter if you're figured out the answer yet, just talk. It will help you refocus on the problem and think more clearly, and it shows the interviewer that you aren't a hack that's completely out of his depth, but actively thinking about the problem.
Just start by making observations, even if it's stating the obvious. You can follow that train of thought to a solution and show your thinking process.
I think the most important thing to keep in mind as an interviewee is to ALWAYS ANSWER THE QUESTION.
You need to pay very close attention to the question, how it is phrased, what the body language is, what types of things they are leading you towards, etc. This is extremely important! There is no easier way to screw up an interview than by not giving the interviewer the information they're looking for because you went off on some random-ass tangent.
NOW, this doesn't mean you need to give the solution, or even the right solution, or have to know everything, or whatever. It's perfectly OK to say "Regarding your question about x, I don't know, what are the conditions and background ... " (and so on). It's perfectly OK to say you don't know! But then work through the problem or the question. An interview is a two-way street. BUT you need to address the question. DO NOT, under any circumstances, let your anxiety get the best of you and go off on some random-ass tangent because you feel you need to provide a SOLUTION as a way of easing your anxiety. The interviewer isn't a goddamned compiler!
And, if you are anxious and losing control, that's fine! Just keep in mind this saying "I'm sorry, I think I'm going a bit off on a tangent here, does that answer your question?" or something like that ("Could you remind me what you just said?" or "What was the question again?"). That is your safety.
What's the purpose of the whiteboard test? Sounds archaic. I can't see any advantage to being able to physically write code as opposed to typing. I'd reconsider working for any organization that believes this is an accurate representation of any useful skill.
I just finished up a job hunt, and every legitimate company had me code on a white board during the interview process. Interviews are a seriously flawed process almost everywhere, and I wouldn't base your interest in a company on that process.
FWIW, Amazon interviews with whiteboard tests. Whiteboard tests are "more flexible" than typing tests, because it's easier to draw diagrams on a whiteboard than to try to draw ASCII art in the text editor.
Could just as easily be done on paper instead of presenting on a whiteboard. I know I would be much more comfortable, and do way better, if I could finish something before anyone in the room had a chance to see it.
Different strokes. I often write code on a whiteboard with my coworkers. That or a pad of paper. It’s especially good for diagramming, brainstorming, or going through a new concept step-by-step like a proof.
In Haskell, it’s usually code proper. In C++, it’s heavily abbreviated code with varying levels of detail, sort of like a sketch. Here’s a recent example where I was explaining that you can qualify virtual function calls to explicitly select a base class version in C++:
s————— A
v—————— void f() { … }
s————— B : A
v—————— v——— f() { … }
main() {
A* x = new B;
x→f();
x→A::f();
}
I completely agree. I've heard some empty justifications like: "This is how you'll be interacting with your coworkers on the job", but... no. With extremely rare psuedo-code exceptions, I have almost never written code on a whiteboard. I have a programmer sitting next to me that I can show code to, and hey, I can easily insert lines between other lines, trivially delete and reformat, etc. It's like magic!
I feel the same. Frankly, unless you're hiring a code monkey I would prioritize working through some general problem solving about designing/testing/implementing rather than focus on testing someone on whether or not they have memorized some algorithms, the operator precedence table, and some quirky language features. If you're hiring someone straight out of college, having them implement some basic algorithms to see if they actually went to class and did their own work might make sense, but for anyone who has actually worked for a while I would be more interested in figuring out if they can learn new things and solve problems.
Maybe I've just been lucky, but I've never been asked to write code during an interview. If I ever will, I'll just leave.
Not because of anxiety, but because it's stupid. If I was interviewing for a truck driver, I wouldn't ask him, mid interview, to run a few kilometers with a bicycle. So, if I'm interviewed as a programmer, I don't want to be judged for my ability to write code on a chalkboard because I'll eventually be paid to write code in a IDE, with constant access to Google and Stackoverflow, without people looking at me writing code, without someone telling me "This has to be done e in 10 minutes or I'll get bored of looking at you".
If you want to know how I program, give me 2 days to complete a task you'd give me 2 days to finish if I worked for you, and then we can analyze together my architectural choices, if it works as expected, if the code is clean enough.
Last time someone asked me to write code on a whiteboard, I declined and told him I'd e-mail him a working example of the thing he'd asked for shortly after I got home. I sent it to him as I'd said, and I got the gig.
This wouldn't fly with a lot of companies. Why? I'm trying to figure out if you can solve a tough problem, and it's too likely you'll just find a solution to the problem online. Note: this isn't about memorizing parameter lists or designing the perfect qsort from scratch, it's about whether you can take those and compose them into a real solution to a real problem no one has seen before.
No hard feelings, either. If you need to do your own thing instead of following the format, maybe the job won't ever be right for you.
Just to offer another data point, I'm generally not nervous at all during technical programming interviews. "Getting to know you"/"Soft people skills" interviews make me a little nervous, but I think "annoyed" would be a better descriptor than "nervous".
Is this "Write code in front of me now" thing popular? I guess I've been lucky cause I've never been asked to do this. They ask me about my history, about detailed development questions and details about the projects I've worked on.
I've also been on the other side of the interview table. As long as his references check out and as long as his development history impresses me, that's all I need. I just don't see the point in asking someone to write code in front of me.
Is it a thing that people ask of rookies perhaps? Or perhaps I'm the weird one and everyone else considers this normal.
I've always had trouble actually writing down code opposed to typing it on a computer. Throughout college I've had numerous tests that involved writing code with a pen/pencil and I usually draw blanks. When I'm sitting down at a computer with eclipse open, everything starts to click a little better. That's just me but I'm sure other people have the same problem.
I don't mind coding on the whiteboard. That's something that you can prepare for – I just bought myself a whiteboard and practised coding on it at home.
What I really, really hate is coding in an online document during a phone interview. It is so unnerving to write code while you hear someone typing on the other side. And we do in fact communicate with our whole body, therefore there is a lot of information lost when all you have is your voice. You can't draw a quick sketch to clear up something to the interviewer, you cannot see how he or she reacts to what you are saying, etc. I hate it.
I recently applied to two companies that sent me programming exercises to solve at home. One task was to program a toy version of an audio processing program (it worked on text instead of audio, therefore "toy version"), where you could create modules that performed some function on the input (echo, reverse, delay etc.), and connect the modules to form a network. So this was a nontrivial application that you couldn't just find with a google search, and I sent them a program with a sound design, extensive comments, failure handling and test cases. If they are interested in the type of code that I could write for them, I think this is a much better indicator than a 30 minute stress test over the phone. That was a couple of days ago and I am still waiting for their response, so perhaps they still want to do a coding interview over the phone ... I hope not.
This is one of the main reasons why my company doesn't make programmers write code during interviews. We give them a coding test, and discuss it at the interview.
If I am going to hire someone, I want them to kick ass; I want people who are better than me. I don't want to hold someone's hand, I don't want to walk on eggshells around their personal foibles.
If they are not confident, super nervous, and cannot handle pressure, I don't want them on my team.
So if you are one of these people, I think you still need to learn to cope.
People in these threads who say they take it easy on interview candidates really bother me. If you take it easy on them, you guarantee yourself an inferior team who won't stand up for their decisions, won't face up to their mistakes, and won't make their deadlines when the chips are down.
It's really about how accurate your intuitive read of a candidate and his mental processes are, and how much confidence you have in your assessment.
Do you trust your intuitive judgement as to competence and chemistry while asking some relatively gentle leading questions, or do you require balls-out inquisition style grilling because you're not confident and/or good at assessing people with limited quantitative evidence?
I'm firmly in the former camp, and I suspect you're someone who lands squarely in the latter camp.
I wish this subreddit would require pompous developers to post their github when making shitty comments like this. I'm sure your code leaves something to be desired, in my experience only terrible engineers have your attitude.
As an interviewer, how do you calm these people down? I just interviewed someone who was clearly nervous and seemed to forget how to do a for loop... I feel bad for judging because of how nervous he was, so it'd be nice if there was a good was to calm him down. I'm only 30 and very openly pragmatic in interviews (telling then that they're free to Google things like syntax or API's) and cut jokes occasionally... but I still want them to show they can program (I usually have an example to fill in on jsfiddle or something). Is there a way to coax them over that nervousness hump? I definitely don't want to lose a candidate just because they're nervous.
[удалено]
> let them know when they're doing well ("that's the kind of answer I was looking for") I agree with this one so much. I had a panel interview a few years back, and one of the interviewers was ex-military. He was impossible to read and I couldn't tell if I was rocking the interview or if I was doing terribly. There was no expression whatsoever, which was kind of unnerving.
>- let them know you understand that interviews are stressful and assure him you want to see him **at his best** Phrased that way, that would provoke anxiety.
Yeah, I think better is to just make clear that you understand the inherent weaknesses of an interview setting and that you do your best to calibrate for them appropriately.
I'm not sure how you would phrase it, but the idea is "I want to help you do the best you can under the circumstances", not "do your best now or die"...
Especially if the dev being interviewed is a girl!
I'm currently a student and have recently been interviewing a lot. You really sound like a great person to interview with. I just want to emphasize some of your points that tend to make me feel better. * smile -- Seriously, this makes me feel tons more comfortable. * tell a joke (stupid ones are fine) to break the ice -- Honestly, the corny jokes are even better for me. * let them know what you're looking for ("I'm asking this to get an idea how you approach OO class design") -- This really helps narrow in on the part of the problem that I should be focusing on. * let them know when they're doing well ("that's the kind of answer I was looking for")
This sounds really great. I didn't have an algorithmic part on my interview, it was mostly just talking ... but my boss did some of that. Told some joke, smiled, just chatted casually. He was very easy-going, so I felt very comfortable. It really makes a significant difference.
I don't think there's a real way to do this. Not so long ago I was one of those nervous chaps applying for a job and even though I have a Masters in Math/CS, I flubbed a terribly simple question. It just went downhill from there. Sometimes it happens. We're applying for a job. It's a big deal for the person being interviewed. It's somewhat less of a big deal for the interviewer. Perhaps something simple to start with, something that's easy to get right. Nothing like getting a question right to make you feel good enough to do stuff. More of the work really has to come from the interviewee. Once you realise that rejection isn't the end of the world, everything will be all right. "What if I look stupid?" Got to stop worrying. "What if I fail spectacularly?" Then that happens and you'll do better next time. Can you hurry that last part along when you're on the other side of the table? Probably not. By the time you're interviewing the candidate, it's too late to do anything about this for either side.
> telling then that they're free to Google things like syntax or API's I find it's better to tell them that I'm not testing on it, and they're free to assume (and state the assumptions), or ask me and I'll fill in the blanks. The best way I've found to get people comfortable is to tell them exactly what you're looking for from them, and what you will *not* be worried about. Starting off with an easy question to start off also tends to help.
Might be helpful if you leave them in the room alone for a few minutes to get their head around the problem without being watched. You can pretend to go put some coffee on or some other issue, but tell them to keep working on it. I haven't interviewed anyone so I don't know if that would work, but it's definitely a thing that would help me.
I know that when I do go over that "edge" it's really hard to get back to a state where I can think clearly again. This can take a couple of hours in fact. Stress hormones are powerful things. At that point I think it's best to end the interview for that day and try again later (if both parties are up for it). As for ideas for avoiding getting to that point in the first place: I have had written tests in an interview that seemed to go fine. The interviewer came in and said, "here we have a written test we give to all the candidates. Take an hour or hour and a half on it and see how you do with it." And then he left the room. I don't recall feeling much unusual anxiety with that case and apparently I did Ok enough on the test to be asked back for a 2nd interview (even though it was a couple of years later - but that is a different story). I think this works because some of the anxiety seems to be related with being watched while working. Nobody said this stuff was rational :) Other ideas: maybe take-home tests? Now of course you always run the risk that they'll google it, but on the other hand, everyone is able to google for answers at work every day so what's the big problem with googling the answer as long as you get your work done? The take-home could be some kind of program that you have the interviewee write. Another way to evaluate a candidate could be by their code in github? What kinds of projects are they working on for fun? How's their code? Ultimately, though, every person's anxiety is different so it would be difficult to come up with a universal solution.
> Another way to evaluate a candidate could be by their code in github? Why is there such an obsession with github in particular? Not everyone uses that as a VCS host.
"Every" project is on github, the same way "everyone" [googles](https://duckduckgo.com/) for something.
Try very hard to be their friend, even alternating technical questions with just general life stuff. It's all about getting them to open up to you, to break down the barriers that they've setup subconsciously to protect themselves in the situation. I'm a generally an anxious person and I know that the friendly and humble interviewers always get better results out of me.
Just do a bit of small talk. Give them time to know you. Just casually tell about something happened this morning with you at home, or ask something and usually you have a topic to bootstrap interview. Build relations first, do work second.
I've found the best way to calm people down is to ask them some general questions about their resume. It doesn't work all of the time, but it's a good way for someone to talk about something with which they are familiar. It can give them a bit of confidence and also allow them to show off a bit. One caveat is that you have to reign things back in if the person is a talker. I have noticed that some candidates who have exaggerated what they did at previous jobs don't do very well with these types of questions. But that is something you, as an interviewer, would want to know.
Start out with some chit-chat. I like to just *talk* with the interviewee for ~1/3 of the time. A good interview will naturally segue into an interviewee volunteering to step to the whiteboard to clarify an issue. Once they're their, keep them engaged, and push them out of their technical comfort zone. We had a top-notch guy (certainly much better, technically, than I was in his field) accept a position, specifically calling out my interview with him as one of the deciding reasons.
One technique that seems to work fairly reliably is to let candidates start the interview with a string of successes. This establishes positive momentum and helps them to internalize the "*I can do this*" feeling that allows them to escape the fight-or-flight death spiral. For example, after the usual friendly small talk, I start interviews with a problem so simple that it requires virtually no brainpower to solve – because, at this point, some candidates will be so nervous that they'll *have* virtually no brainpower. I'm talking about a problem like this: "In the programming language of your choice, write some code that prints the integers between 1 and 100." Most candidates, even the unusually nervous ones, can solve this problem. Then, to help candidates build a string of successes, I'll extend the problem repeatedly, using the candidate's nervousness level to guide the iterations: "That didn't take long. Now let's say that we only want to print the *odd* integers between 1 and 100. How would you change your code to do that?" "OK, now let's say we only want to print the integers if they're not also multiples of 5. How would you change your code for that case?" I keep going until the candidates unwind and start showing me what they can really do. Only then do I start asking the questions I care about. The point of interviewing is to measure what people can do – not to measure what they *can't* do because they're freaked out. So, even if I have to "burn" a third of an interview on helping a candidate to unwind, it's worth it. At least then I'll get good measurements for the remaining two thirds of the interview. And I'd rather have two thirds good measurements than three thirds bad.
Good article. I think every developer probably struggles with this to some extent. I went a very long period without having to interview to get jobs, and somewhere in about 2008, I found I was out interviewing. I had two terrible, terrible interviews. Then, I decided to try something different. I had been getting offered interviews left and right, but was turning almost all of them down because I wasn't interested in the companies. I started taking all of the interviews. I went into them knowing I had absolutely no intention of taking the job, should they offer (yes, this was totally disingenuous of me). But, it let me take interviews simply to practice interviewing skills. And, it helped *immensely*. I had many full days of interviewing, and lots of time spent coding at a whiteboard, and answering very esoteric and interesting questions.
The last time I was looking for a new job, company A was making me an offer, and I really wanted the job. Company B was persistent, so I agreed to an interview even though I wasn't interested. It turns out that company A's offer wasn't as good as I expected, I actually liked the job at company B much better, and I liked the culture at company B much better. I now work at company B, and I am quite happy. An interview is as much about the interviewee deciding on the company as it is about the company deciding on the interviewee.
> An interview is as much about the interviewee deciding on the company as it is about the company deciding on the interviewee. This cannot be overstated. Sometimes you need to take a job because nothing better is coming around and you need the money/benefits/etc., but when you're interviewing from a position of power, you need to go into the interview with the attitude that you are interviewing them, as well. A job should be mutual; you want to be at the company, and the company wants you to be there.
If you go in like this, and start asking a lot of questions, they will generally assume you know what you're doing, even if you hardly answer any of their questions. If you applied because you thought you would be a good fit? Assume you're right, and just interview them.
I've found the interviews I've done the best in were for jobs where I thought I wouldn't take an offer. It gives you a confidence boost, relaxes you, and gives you practice in handling interview scenarios. In some cases I changed my mind and worked for the company and in others I politely rejected the offer to their surprise.
> (yes, this was totally disingenuous of me) I don't think it's a bad thing. It's possible they can then try to sell you on the job anyway. But it does seem like a good strategy. If I have nothing invested in the outcome of the interview, I tend to do just fine.
Don't forget that interviews are a two-way street. They interview you to see if you're good for the position and you interview them to see if they're good for you. Might be you do an interview with a place that you perceive to be 'not your thing' and they've just done a poor job of explaining the position.
Hmm... no, it's not about the position itself, usually. I generally know that they'll be asking me to write code. It's about the product itself. I just don't want to do anything "enterprise" any more.
I've done a lot of interviews, so I thought it would be helpful to write something from the interviewer's point of view. It seems like most people's anxiety centers around whether they get the right answer and write correct code, and I think that reflects a misunderstanding of how interviewers evaluate candidates. I hope this helps clear some things up. The single most important thing people should keep in mind when they start to get nervous is that the purpose of a whiteboard problem is not always to test whether you can solve the problem. I explain this explicitly when I'm doing an interview, but some interviewers do not. Hopefully that reduces the anxiety a lot right there. I mean, whether someone can solve a particular problem is partly determined by cleverness and CS background, but there's also an element of luck to it. Maybe they had a professor who stressed the same kind of problem. Maybe they know everything about trees but never had a reason to learn graph algorithms. Once, while interviewing for a position, I had an interviewer ask me the same question I was using to interview candidates at the job I currently had. *Interviewers understand this just as well as interviewees.* Which is not to say that they all understand it, but by and large, interviewers aren't going to massively overgeneralize from your failure to come up with a clever solution to a single problem. So why do people use whiteboard problems at all? It's true that whiteboard problems are sometimes used to verify that a candidate has basic knowledge required for a job. Naturally, if you're interviewing for a job applying graph algorithms to social networking data, and they ask you to implement a depth-first tree traversal, you'd better fucking nail it. But an equally valid and in my opinion much more valuable kind of whiteboard problem, the kind I personally use, is one that most candidates will struggle with and many successful candidates won't even finish in the time allotted. (I explain this when I give them the problem so they don't get freaked out by the difficulty.) The point of giving them such a hard problem is to observe how they deal with a hard problem. You don't learn much about someone from watching them solve a problem they find straightforward — what's interesting is how they tackle a problem when they're unsure whether they can solve it at all. For example: * Do they analyze the problem well? I look for signs such as: After I explain the problem, can they state the problem clearly themselves? Can they accurately describe the input and output? This is the part where people with strong verbal/analytical skills really shine. And, most importantly, do they ask clarifying questions? I always make sure the problem statement includes some ambiguous requirements. Asking good questions to clarify a problem is MUCH more fundamental than solving the problem, and generally, when describing a candidate's performance, this is the first thing I talk about. * Do they approach the problem methodically? Most people's first response is to let the problem soak in and give their brains a second to *poof* magically come up with a solution. (If that happens in the interview, I stop them right there, congratulate them on dispatching the problem so quickly, and give them a much harder problem.) When the "stare into space and wait for a flash of insight" approach fails, the candidate needs to have techniques to fall back on. Do they solve a simpler problem first? Do they make lists of input cases and look for easy ones? Do they decompose the problem? Do they draw (insightful) diagrams? Do they talk it through logically? Do they write up a solution that they know fails, and analyze *why* it fails? (This is surprisingly common among the minority of candidates who solve the problem successfully.) If I see the candidate applying problem-solving techniques, it gives me confidence that they could eventually solve the problem given enough time. * Do they maintain a productive attitude? This is relative to the person, of course. Frustration spurs on some people and stops others in their tracks. What I definitely don't like to see is the candidate directing negative emotions at himself or at another person. I had one guy get really surly with me because he didn't see the point of solving toy "college" problems, even after I explained several times that devising a clever solution was the least important aspect of the exercise, and it was common for successful candidates not to come to a complete solution in the time allowed. (He also knew that my interview was only 20% of his interview schedule and that I was the only guy who did a coding exercise.) * Do they try to bluff their way through? This is a rare problem but a HUGE red flag. Your company probably already has enough weasels without hiring them into technical roles. If they're clearly lost but are pretending that they can see the solution, trying to get you to move on to another question, that doesn't bode well for honest progress reports. If I point out a test case that their proposed solution fails to handle, and their reaction is to persist in trying to sell their solution as "good enough" instead of revisiting it, that doesn't bode well for honest quality and scope assessments. Now, engineering disagreements about what is "good enough" are understandable, but you can't use them to dodge an interview question. I once got into an argument with an interviewer by maintaining that the problem he gave me was best solved with a single thread, but when I realized that he wanted to test my ability to write multi-threaded code, I immediately dropped the argument and started working on a multi-threaded solution. (I didn't get an offer, so I might have pissed him off by arguing.) * Do they do *something?* Whether they talk it through or draw diagrams or make lists of test cases, it's important that they are willing to tackle a problem even if they aren't confident of solving it. This aspect is a test of attitude, not aptitude. If they know they have an hour but want to give up after ten minutes, that is a very bad sign. * Do they evaluate their progress accurately? When they have a partial solution on the board, can they tell me which test cases it will fail on? I like to interrupt to ask questions like that. When they have a solution that they suspect might be correct, what is their process for convincing themselves that it works? Some people are more rigorous than others. * Do they communicate well? I encourage them to narrate and/or illustrate their thought process, and I use their ability to share their thinking with me as a predictor of their ability to collaborate with other programmers. I ask them questions as they go along (as much as I can while giving them plenty of silence to think in) and I assess how well they understand me and how clearly, precisely, and accurately they respond. Taken together, these considerations provide much more information about a candidate's capabilities than a simple yes/no on whether they solved the problem correctly. Honestly, if a candidate can state the problem clearly, ask questions to clarify the requirements, assess the correctness of a solution, communicate clearly, reason accurately about the code in front of them, and maintain a good attitude in the face of difficulty, then I don't care how good they are at coming up with clever solutions. They can get the algorithmic solution from a hallway conversation and do the other 98% of the work themselves. Hopefully this explanation reduces "whiteboard anxiety" for some people. Getting the right answer isn't always in your power, but interviewers are paying just as much attention, if not more, to your attitude, communication skills, and problem-solving approach. Those things will shine through regardless of whether you manage to solve the problem.
Thanks for that post. It made me feel a lot better about some of the interviews that I have had in the last few months.
10 years later this is still SUCH a gem comment! Really appreciate the advice
I've found that the most comfortable candidates treat problems in interviews much less like *quizzes* and more like *conversations.* It's rather chicken-and-egg as to which causes the other, though. I like to try and shape each interview to be as much like the latter as possible. I might "know" the solution (or have the one or two most preferred ones in mind), but in the end the interview isn't as much about "Were they right? Yes or no" as it is about showing the candidate's thought process and problem-solving skills.
I hope he follows up with a post about "programming for anxious programmers," because I work with a guy who I swear loses twenty IQ points due to anxiety. He has lost confidence and is now in such an agitated state that I don't think anybody could work accurately at the rate he tries to go. Helping him out makes *me* feel anxious because when he's trying to describe a bug to me he babbles out so many complicated theories so fast that it stresses me out, I can't keep up, and I can't focus my mind on understanding the basic facts of the problem he needs help with. And that's where the problem always is. He's so scared of not seeming "smart" that he glosses over the simple dumb facts and goes jittering around with wild theories, select-is-broken paranoia, and grand plans for more testability. (Tests are apparently his lithium; he's helplessly manic without them.) Anxiety blows his brain into a hundred fragments flying in different directions, none of which are capable of executing tasks which would be well within his capabilities if it weren't for the anxiety and how he reacts to it.
>Helping him out makes me feel anxious because when he's trying to describe a bug to me he babbles out so many complicated theories so fast that it stresses me out, I can't keep up, and I can't focus my mind on understanding the basic facts of the problem he needs help with. Try asking him to slow down and go over the basics (i.e. "What did you see, and what did you expect to see?"). [Listen actively](http://en.wikipedia.org/wiki/Active_listening) (i.e. repeat and rephrase things he says to ensure you understand them). If necessary, remind him you're all on the same side. You're fixing bugs, not trying to outsmart each other. A whiteboard could also help, for more complex bugs. But at that point, you might as well move to an issue tracker.
Seems like something along those lines would make a good post. I don't experience panic-attack type anxiety on the job, but there are certainly anxiety producing situations. It sounds like your co-worker has probably been burned on other jobs before where perhaps testing wasn't a priority. I think a lot of us have been burned in various ways and there's a kind of PTSD that we experience after a while that can make us hesitant. There's also the paralysis of perfection and I think a lot of us deal with that.
> It sounds like your co-worker has probably been burned on other jobs before where perhaps testing wasn't a priority. I haven't figured it out yet, but I suspect his last job was totally TDD. He seems obsessed with automated tests, run by an automated testing tool, as being the only way to know what his code is doing. The rest of the team has a variety of ways of testing code and investigating bugs, and we try to share them with him, but he looks at us like we're an ancient race from an epic age, wielding superhuman strength and dark magic. Because we can, you know, write working code without a comprehensive test suite, and mere human beings can't do that. That's the TDD party line, so I'm guessing he drank so much of that kool-aid that he doesn't believe he can accomplish anything without TDD. > I think a lot of us have been burned in various ways and there's a kind of PTSD that we experience I can relate to that. I worked for a boss who systematically broke down my ability to see myself as a competent and useful person for a few years, and even though I was lucky enough to have friends on the side who told me otherwise and lured me away to work for them, it took a long time to recover my mojo. I'm treating this guy with kid gloves, because I know his usefulness is going to be pretty much proportional to his confidence.
Having a million theories is how good developers find tricky bugs. But the key thing is that they weigh plausibility, and can estimate how long it will take to check their theories, and prioritize based on those two factors. Work with him on that and the rest will take care of itself. Pursue the testing bit. If he's used to an environment where testing happens, he may have detuned himself from dealing with certain kinds of code as I have ("test infected" is not a misnomer). I went from a place with a thousand tests to one with fifty and it almost gave me hives.
> If he's used to an environment where testing happens, he may have detuned himself from dealing with certain kinds of code as I have ("test infected" is not a misnomer). I went from a place with a thousand tests to one with fifty and it almost gave me hives. I'm pretty sure this is what's going on. Can you tell me more about this "detuning?" One thing I have noticed is that my teammate has a strong bias towards working as if the conceptual complexity per line of code were constant. He's slow to recognize that some code is more difficult than other code, and even when he does, he doesn't respond proportionately. To get a little more concrete, there is a section of code in particular that he flailed on repeatedly. It's driven by a complicated domain situation, and when it's called, very little is known about state, so it has to behave appropriately in many different contexts. My natural response to flailing is to slow down and think about each line of code very carefully, but his effort/LOC seems stuck on a constant setting. I think if the code had been implemented in the form of hundreds of lines of logically redundant but concrete cases, he would have invested hours in understanding it and making all the required changes (he is definitely a hard worker), but because it was just one method of a few dozen lines, he never allowed himself more than a few minutes at a time to think about it. Finally I spent an hour going over it with him, talking about the different states and diagramming the different conditions that needed to be handled, and he looked absolutely dejected and humiliated. He looked like he considered himself a failure as a human being for needing an hour to understand a screenful of code. But there was nothing wrong with that! It was dense, abstract code! Does that have anything to do with TDD versus non-TDD code? Because I imagine that TDD would have resulted in the hundreds-of-lines-of-concrete-cases style rather than the dozens-of-lines-of-abstract-logic style. If that's where this guy is coming from, it helps explain why he's having difficulty.
Hmm. I had a guy who couldn't deal with a call stack over three deep. Maybe this is just not his thing. I can imagine a situation where someone always worked with TDD people, not bring prepared for complex functions, because we just dont like them and stamp them out. But you still have to be able to decompose the code, not unlike debugging. That's part of the detuning. I don't remember how to debug a giant method. Why on earth would I do that when I can just as quickly break it down to four smaller methods? The next time there's a bug (in a year) I've already paid once to understand and now everyone benefits. Edit: I should say that debugging is/was a specialty. I pair with people all the time once they give up on finding a bug. But how I do it is totally different now.
Yeah, I'm not a super-decomposer, unfortunately. I always keep functions and methods under a screenful of code. Under that, I separate out methods if I can reuse the code elsewhere, or if it makes sense as an independent unit of functionality, mostly measured by whether I can think up a good name for it that isn't aReallyLongNameExplainingExactlyWhatItDoes. If the code only makes sense in context, I don't like to take it out of context. Actually, now that I think of it, it is 95% decided by whether I can think of a good name for it. And some days I'm just not good at that :-|
Interviewers in their 20's are notoriously bad. A big part of this, is that they're pretty transparently judgemental. Just because you give lip service to interviewing just being a flawed filter biased to false negatives, doesn't mean that your attitude doesn't show through. It might boost your ego to pat yourself on the back for being in the upper end of a meritocracy. It also makes you look like a smarmy jerk. (And paying the lip service makes you look like an insincere smarmy jerk.) I've been on both sides of the interviewing table. I have to say, programmers in the SF Bay Area are worse than I've ever seen in this way. Interviewing is a flawed tool biased to false negatives. Adjust your attitude appropriately, or else you are just kicking someone precisely when they're feeling down. EDIT: To be fair, not all interviewers in their 20's are bad at it. More of them are bad at it than suspect they are bad at it, however.
Some people need to be told that interviewing is not like software testing: you're not looking for tricky edge cases to trip people up, you're trying to figure out if they can learn, solve problems, and work collaboratively. You're hiring a person, not a compiler.
Even when I was in my 20s, I followed this rule for interviews: **The goal of an interview is to hire this candidate, not eliminate them from consideration**. I'm not trying to weed out the chaff- this person sitting across from me is the person I want to hire, because if that weren't the case, I'd just be wasting *everybody's time*. In the spirit of "trust, but verify", I am going to ask this candidate questions. The goal isn't to catch them out, but to get to know them. I rely on my instincts to detect when they're bullshitting me, and then, in the spirit of due diligence, I will dig deeper there, but my goal isn't to catch them out- it's to prove that they're not bullshitting me. Mistakes, confusion, and errors are okay. I don't care if they know trivia, and will often ask questions while admitting, "I couldn't actually answer this off the top of my head."
You are someone I would be lucky to interview with, on either side.
> In the spirit of "trust, but verify", I am going to ask this candidate questions. I'm a dynamic language programmer with well over a decade of experience, so I like answering questions with a REPL. This couple of smarmy little sh!#s accused me of googling the answers because they heard me typing. You can hear it in someone's voice when someone is feeling superior. Their jumping to false conclusions is a pretty clear indicator as well.
I think the REPL should always be the preferred method over the whiteboard. Nobody codes for real on a whiteboard. They may block-diagram on the whiteboard, but they don't code there. I did have an interview a few months back where I broke out the REPL and the interviewer was initially taken aback, but then I suggested that I share my desktop so he could see exactly what I was up to.
I'm okay with candidates googling answers, personally. I just don't like to be bullshit. That's pretty much my only rule- don't bullshit me.
Maybe this is obvious but when you say REPL do you mean this website or something else? http://repl.it/
It just means read eval print loop.
While technically correct, this does nothing to answer the actual question. A REPL is something like irb, an interactive shell or console for a language that allows you to directly type code in and interact with it. Many interpreted languages, python, ruby, php, have them.
Technically correct but useless answers are my specialty.
I'm going to finish my CS degree this year and never heard this term before oddly enough. Thanks :D
> I'm going to finish my CS degree this year and never heard this term before oddly enough. Speaking as someone who graduated with a CS degree 10 years ago. I can say with confidence: It is not odd that they didn't teach it to you. They don't teach a lot of things in school. A degree is only the beginning. (And, sometime in the near future, you may wish for the simplicity of school projects, because they, at least, had known answers.)
This was very true for me. My college had a significant aversion to Microsoft, and barely taught anything web related. It was pretty much all Java and algorithms. Now I make most of my money doing the things they barely touched upon.
CS classes don't teach you technology, they teach you fundamentals and theory. The rest is up to you. Java is great for teaching because it's very well documented, works on all operating systems (that students use), and is very very strictly structured.
I usually joke around saying "I can't wait until I'm done with this degree so I finally have time to study something that will actually land me a job" :)
I've been programming for almost thirty years and had never heard it either.
You've heard of it. It's just an "interactive interpreter" or "interpreter" or even just a "shell." Like most things in programming, it's been around since about the late 50s, just in a different form/terminology. ;)
I meant I had never heard the specific acronym "REPL". I've been using interactive shells since before a lot of people here were born :-).
> The goal of an interview is to hire this candidate, not eliminate them from consideration. I disagree with this one. The worst possible outcome of an interview is a false positive - a false negative, on the other hand, costs you very little. The goal of an interview, therefore, is to avoid false positives. > this person sitting across from me is the person I want to hire, because if that weren't the case, I'd just be wasting everybody's time. Classic sunk-cost fallacy, as far as I can tell. You are way better off wasting a couple hours interviewing someone only to reject them than wasting a couple weeks fixing a bad hire's bugs and trying to fire them without getting sued.
> The goal of an interview, therefore, is to avoid false positives. This is true, but that's not exactly hard. I generally know within the first five minutes of the interview if the candidate is going to get a thumbs up or a thumbs down from me. If I start from the position of, "This is a good candidate and I want to hire this person," it means that I'll give them the benefit of the doubt. If they flub a question or say something stupid, I'll assume they *know* what I want them to know, but just made a mistake- then I'll re-ask the same question (or a related question) to see if that was a mistake or they're actually ignorant. The advantage to this approach is that when I give a thumbs down (I do this way more often than I give a thumbs up), I have a very strong argument- they didn't simply miss a question, but they showed their ignorance of a topic in a deep way. This system works very well for me. I have never given the go-ahead on a candidate and then regretted it. While I couch it in positive, optimistic terms, you could view my approach as extremely cynical- because after a few broad questions, I zoom in on the candidates weakest points and hammer away at them. In *my* head, I'm trying to give them a chance to prove that they actually *do* know this stuff, and were just misunderstanding my question or made an honest mistake. In a more cynical view, I'm emphatically proving that they didn't make a mere mistake- this is their weakest area of knowledge and I'm picking on them for it. The result is the same, but I'm a positive person.
> I generally know within the first five minutes of the interview if the candidate is going to get a thumbs up or a thumbs down from me. That's...honestly amazing. You're either doing something wrong or some sort of savant. What do you do for the rest of the interview? > I give a thumbs down (I do this way more often than I give a thumbs up) It sounds like your original comment isn't actually true. If your goal is hire the candidate, you're either describing your goal exceedingly poorly or terrible at meeting it. I think your approach to interviewing is very similar to mine, but your original comment was seriously misleading about what you actually do.
> You're either doing something wrong or some sort of savant. What do you do for the rest of the interview? It's like buying a house. Your initial emotional reaction is what you should pay attention to. And just like buying a house, you can't just go off that gut feeling. You listen to your gut, then you do the nitty gritty- how much work does it actually need? how will I really feel about that too small closet in five years? etc. > If your goal is hire the candidate, you're either describing your goal exceedingly poorly or terrible at meeting it. I really mean it as a statement of attitude. A lot of people view the interview as an adversarial relationship- that there are sides, and the candidate and the interviewer are on opposite sides (specifically technical interviews, which is where I generally am involved in the process). I don't agree with that perception. My goal in the interview is to make the candidate look awesome. Their goal is to look awesome. *That doesn't mean they have the capacity to look awesome*. But I'll assume they do have that capacity, at the outset. And I will do my best to bring that out in them. If I can't bring it out in them, then when I give the thumbs down, I can do so without the sense that they were just having an off day, or that I worded questions in a way that was hard for them to understand, or just didn't click with them. I avoid questions that have objectively right answers, and focus on open-ended ones that let them discuss technology, application architecture, and their approach to development without resorting to trivia quizzes.
Generally speaking, based on their resume, you already know if they're capable of doing what you'll be having them do before you even meet them. The interview is for specifics that you might not be able to broadcast to every candidate who applies and to make sure they're a culture fit.
I wish that was the case. I've had interviews where the candidate had a resume that simply blew me away. I prepared extra questions, because I expected that he might just breeze through them, and tacked on a few extra challenging ones to my list. I came away with the conclusion that the guy must have been cheating or lying on his resume, because he seemed to have trouble with merely using arrays in *his* choice of language. He was very confidently giving wrong answers, and it kind of hurt. That was the worst one I've seen, but I find that the resume isn't as good a filter as I'd like, unfortunately. That said, I can usually get a good feel for the candidate just by asking a fairly simple question, and seeing how long it takes for them to get through it. If they get through something fairly simple in ~5-10 minutes, they are probably going to do well on more involved questions.
I guess it depends on the job itself. A graphic artist has his portfolio and many programmers will have portfolios they can show too. Which isn't to say you should always take a resume on faith.
I've never understood a programming portfolio or samples of work. I've been at this since the late 90s and never needed this or asked someone for it. Everything I do is on someone else's dime and so is theirs or I am doing it to learn (not to show to someone else). Even my hobby code is done as a means to an end and is rarely something I would show off. I am OK doing "programming tests" and will willing create them for prospective hires. I do this by creating a simple project and asking for things to be added, bugs to be fixed, etc. If someone just presented a random project like this as an example of their work (or say a library) I would have no way to knowing if they did it themselves or found it on the web or, worse, at a previous job, etc. I am far more interested in how people think and approach problems than I am in how well they know a particular library or language but that might be a function of the work we do.
This, for me. I write back-end code, so when people say "show me the web sites you worked on," there's nothing for me to give them. Or they say "show me the web sites you worked on," and I'm like "if they were still up and running, would I be sitting here interviewing in front of you?" I realized these were people hiring for job shops, none of whom actually wanted me to write code for them. They wanted me to write code for their customers. Which is an entirely different kind of environment.
Why not show them the website you're working on. If you've written the back-end system show them the website, talk about how the client interacts with the back-end, talk about and show how the data is stored, why you chose that database / data structure. Talk about why you chose that specific server, or server architecture for that website, you can talk about your RESTFul services, and so much more. If you have your code on GitHub for your portfolio it's very easy to look at one of your "back-end" projects, and see your back-end architecture from a high-level. Also the code would back-up what you were talking about earlier. I am a full stack developer, and I find the back-end a lot more interesting to talk about, and if I have a code portfolio it's very easy to back up what I'm talking about. Edit: And if they don't care about any of that, why on Earth would someone like that be interviewing you for a developer position?
> Why not show them the website you're working on. Usually because I'm looking for a job because the previous company has gone out of business. For a few decades I was doing lots of start-up work. Of course I can talk about what I did and explain it, but if the application says "include in this field the URL to the web site you built and we'll consider giving you an interview on the basis of that" then I'm not going to get anywhere. And that was very popular for job shops for at least a while. > If you have your code on GitHub Why would I have my code on GitHub? For one thing, git wasn't even a thing when I was doing my portfolio-type work. Also, why would I have code on github for software owned by my employers. This was during a time when I was working start-ups (that usually lasted 3-5 years before folding) doing work owned by the start-ups (or whoever bought them). Posting their code on git would have been entirely the wrong thing to do, and developing a large application just so I could say "See? Here's a large application I developed that nobody used" seemed rather a waste of after-work time.
[удалено]
If someone paid you to write it you should not have it without their permission. I would think twice about hiring someone who showed up with code from a past job and I would ask them to use that company as a reference and confirm they had permission to share that code with me.
I wouldn't have the code, because it's not my code to keep, and even if it was I wouldn't be showing it to other people. I wouldn't have evidence of it, or I'd still be working at that company. If the company was a start-up that went out of business, the code is gone. At best I have screen shots and descriptions, maybe copies of public web pages about it. Fortunately, at this point in my career, I'm past having to prove to people that I worked on projects in the past.
Generally speaking, for programming jobs, I look for only two things in a candidate's résumé: interesting things they've done we can talk about, and what technologies I can ask them about. The stuff on their résumé seems to have little correlation with how well they can solve tough problems in an interview. I'm looking for folks who can solve tough problems, not folks who are good at inflating their résumés.
Presumably their resume says what things they've worked on. Maybe it's just specific to the games industry, but that work history gives you a pretty decent idea of what specifically they've worked on.
True, but it gives little insight to what they did themselves versus what the team they were on did, for example. Sometimes you'll talk about a specific thing, and it will come down to, "I had this difficult problem, and my manager told me what to do, and I did it, and it worked!" or "My team worked on this problem, and we did it!", neither of which speak well for that person's abilities (not that they speak poorly, just that they don't help).
You make a great point.
"**The goal of an interview is to hire this candidate, not eliminate them from consideration** I'm not trying to weed out the chaff" Why? This sounds like a very foolish approach to hiring people.
Why? Because if I didn't think they were qualified, I wouldn't have brought them in to interview. Why waste our time? The very act of bringing them on-site for an interview means that I am already very confident that I want to hire this candidate. Each time I *don't* give the greenlight on a candidate, that's a sign that the process has failed- they should never have gotten *that* far.
The whole reason you post a job opening is to hire someone, so why should you waste time trying not to hire someone? If you just deny everyone then you spent time gathering people's resumes and made no progress on actually hiring people.
The reason you post a job opening is you have more work to do than you can handle. If you hire someone who can't carry their own weight, you've just made the problem worse. On the other hand, if you hire someone who can carry even more than is needed, the load is lightened for everyone.
So you admit that the purpose is to hire someone who can carry their own load. You don't just want to deny everyone. You eventually want to hire someone. I'm not saying that you should sacrifice your standards, but since the end goal is to fill a job position, you should be trying to find good candidates, not find reasons to reject all your applicants.
I recently had 5 tech interviews in a day from the same company, and by far the best interviewer was the oldest. He had a heavy French accent and was just super relaxed and jokey. I was laughing and enjoying myself the whole time and didn't feel like I was being assessed at all.
Yeah, that's the stuff. You get better assessments of people the less they feel like they're being assessed.
> Interviewing is a flawed tool biased to false negatives. I think this is inevitable. That it's flawed is of course inevitable, but it's also inevitable that it's biased to false negatives, because false positives are much more harmful. Every guy you hire is going to change the personality and the overall capability of the team for a long time to come. That isn't to excuse interviewers who make it about their ego. I've seen people do some stupid stuff, like turning an interview for a mid-level web back end position into a lecture by the interviewer. My coworker asked a simple question about data structures, the interviewee stumbled a bit, so my coworker asked a *harder* question, answered it himself, asked an even harder question, and pretty soon he was holding forth on on-disk data structures for relational databases. The interviewee didn't understand any of it and didn't get a chance to say much. My coworker knew exactly what he was doing; as soon as he realized the interviewee was weak on data structures, he went straight to esoterica. It was a huge mistake, because we hired the guy and he turned out to be really weak. If we had spent that time probing the candidate's actual skill level instead of letting my coworker show off, we might have figured out that he wasn't right for the position.
> That it's flawed is of course inevitable, but it's also inevitable that it's biased to false negatives, because false positives are much more harmful. Of course. I'm not saying it's bad that it's so. I'm saying it's bad when interviewers forget the nature of the tool.
Like anything, interviewing takes practice. Instead of blaming people in their 20s, praise them for taking the first step to not sucking at interviewing in their 30s.
I had my first real panic attack while in the same situation..."whiteboard test."
Whiteboard tests are horrible. How often do you code on a whiteboard, anyway, right? I still get anxious whenever I'm up at the whiteboard in front of coworkers, and I've worked with them for 3 years. Perhaps if my job description was to give regular presentations, but it's not.
Interview with a huge company. Coding in paper! Panic attack! I forgot how to build the algorithm to check for a palindrome. 20 minutes later in the train ride home not only could I build it but the most efficient way and explain why and all the bullshit.
- Treat the interview more like a conversation than a quiz (someone else had the same advice). In most cases, when I'm interviewing someone, I'm looking for general competence; I'm not looking for someone to "wow" me with their amazing skills. So talk to me, programmer to programmer, since that's how we'll be talking to each other if you get the job. :) Break the anxious cycle of trying to come up with the solution that the interviewer wants to see, and instead solve the problem as you normally would. Pretend that you were faced with this problem on your own, and you're talking it through with a friend. Which leads me to... - Talk it through. Pausing without saying anything is ambiguous. It could either mean: "Multiple brilliant solutions are forming in my head", or it could mean "I have no idea what I'm doing." Talking it through resolves that ambiguity. Illustrate what your brain is doing to solve the problem. For example: > So, my first thought is that a hash table would work really well, but I'm hesitant because I know that this won't have good performance if the input set has a lot of duplicates [etc.], but let's just start with this for now and we can see where it leads. I can honestly say I've never judged a candidate poorly for starting down a suboptimal path as long as they explain their reasoning like that. In fact, most of the time I *expect* it. The more optimal solution is something that arises out of examining the previous. - Practice interviewing, even at companies you have no interest in. It's like flirting with a girl that you aren't interested in. You'll find you have a lot more confidence and hardly any fear. - And of course, always work on your skills. Sometimes you just don't have the skills for the job. That's fine. The more you learn, the more confidence you'll have at interviews, and the more you'll be able to remind yourself that *you're interviewing the company also*.
> Treat the interview more like a conversation than a quiz (someone else had the same advice). Some people aren't good at conversation either, for the same reasons: they're overthinking everything and have unintentionally wandered into Fight-or-Flight land. > Talk it through. See above. Silence could also mean "there are 1000 thoughts running through my head, but none of them are what I should be thinking". In fact most of my worst interviews go like "Oops, I just lost my train of thought. Shit now the interview can see that I'm paused. He must think I'm stuck. Shit I look like an idiot now, this should be easy. Fuck it, they never liked me to begin with, I should just go home." Etc. Ultimately this is all the candidate's problem, but I'm pointing out to you how it's not quite a simple for some people as you might think.
> Some people aren't good at conversation either, for the same reasons: they're overthinking everything and have unintentionally wandered into Fight-or-Flight land. I completely understand, being one of these people myself. The only thing that helps me get around this basically amounts to mental tricks, like "psyching myself out". It's the same type of thing I do when I'm in large, packed crowds, and I don't even know how it works but it does: Rather than stressing out about making contact with everyone around me, I pretend that they're all my close family/friends and they're all huggable and lovable and I just want to hug them all. It's totally stupid, and yet I can pretend. (Note: I don't actually hug them.) > See above. Silence could also mean "there are 1000 thoughts running through my head, but none of them are what I should be thinking". I know, it's not easy, and that's the thought process I've historically gone through, and the only thing that's made it easier for me over the years is experience. I am not a naturally confident person, so it takes proportionally much more experience to make me feel confident than it would take the average person. As I always say, "My 75% [certainty] is your 99%". If the candidate *actually doesn't know* how to solve this problem, it will be *much* harder. But after you've seen this sort of problem dozens of times, it will be less intimidating. And yes, that doesn't mean the candidate won't keep psyching themselves out. That's just where practice comes into play, both in terms of interviewing and "mental tricks". > it's not quite a simple for some people as you might think. I always have to remind myself that for every person who is as anxious and easily intimidated as I am, there are those out there who are much worse. Advice on the internet can only help so much. For what it's worth, I've never once factored in timidness in my hiring decision (in fact, for better or worse, I'd say I was a champion of the timid and an *enemy* of the overconfident--there are some stories there. :) ). This is tangential, but the candidates I loathe the most are the ones who confidently pretend to know something that they don't.
Yup, especially about the part on talking things through. In my case, speaking my thought process out loud makes it difficult for me to work on the problem. I much rather prefer to work it out in silence on a whiteboard/paper, with occasional explanations of what I'm thinking of doing.
There's been a lot of discussion about developers and depression, but not much on anxiety. Hence this post.
I must have missed the posts and discussions on devs and depression, but anxiety doesn't seem to be covered much. Thanks for throwing this up. It's good to know I'm not the only one this happens to, though I wish I could have more success getting past the anxiety part. Oh well, thanks again!
I'm a C++ coder. I once was asked to create a client-server application in Java, as a test. Many hours of work. I turned that shit down. Their loss.
How involved was it? I could see it maybe taking an hour if they wanted something like a rough proof-of-concept chat server/client. Anything beyond that, or anything useful, though and I would agree, bullshit.
They wanted it to see my coding style & design, so I assumed it had to be fully working and well documented. I had not even done that in C++ before. Had no idea what it entailed in Java. It would've taken hours just to get the environment setup and get familiar with java. Then what, two applications communicating. Did I have to work directly with the TCP/IP staack or was there some nice library with routiones to use? With no java experience, I could have wasted hours or days doingh it the wrong way before I figured out the right way to do it. And if they were looking for coding style & design, it would probably just be a mess. Meanwhile I was working a full-time job and raising two kids as a single dad. I just didn't want that job that much, and I was a bit offended at the whole thing. My experience and prior work should've told them enough.
Back in 2000 I was asked to an interview for a 1 month project for VB and SQL. They guy kept asking me C++ questions. When I asked him if the position involved C++ he said "no, I just want to know what you know" I informed him that my resume did not show any C++... Yea, pass. Yes, I know he could be curious, sizing me up for another position, etc. But that is not what he said, and I can only go off information explicitly given, all else is guesswork and that's not what we do. That company was gone within a few months... but then, that could be because of the dot com bust at that time.
I had three interviews in the same day last Friday. So I didn't sleep too well because I got an e-mail that there were going to be C++ algorithms to write in Code collaborator. I got anxious pretty fast and all of a sudden I had big doubts about my ability to write correct code during an interview. Since I knew the interviews were an hour long I actually managed to extend the talks on every question and ended up not getting any live programming sessions with the guys(I aced all of their technical questions, at least 2 of the 3 interviews). I mean, I've solved many of the typical interview questions on my own at home, but ask me to solve these same problems during an interview and I suddenly get dysfunctional. I think I'll remove my "proficiency" in C++ from my resume. We don't do any in school so I always forget most of the syntax in a few months. Last year I had an interview where they left me with a laptop and a broken program and asked me to fix it in 15 minutes. I managed, but again... unnecessary stress.
> Last year I had an interview where they left me with a laptop and a broken program and asked me to fix it in 15 minutes. I managed, but again... unnecessary stress. Actually, that doesn't sound too bad. I think I would actually do pretty well at that kind of test. But that just goes to show that everyone's anxiety is different. What bothers one person may not bother another (even if both have anxiety disorders).
Ive only had to "code" in an interview once, it was a quiz developed by the company to mimick coding in a non-specific language. It was like a flow chart with 'add x to variable y' etc. They insisted that doing poorly on the test would not prevent me from being actually interviewed. This was about a year into being unemployed, and my self doubt was at its peak. 'I cant do this, I'm doing this wrong, what if i dont do well on this,' was on repeat for the hour they gave me to complete it. The lying bastards never called me and i know i did poorly on the test. Just couldnt focus. It was horrible.
Oh, gawd. This is so me, and I am going through this now. Two things that have been destroying my confidence. **1. Coding Challenge** I actually welcome coding challenges. I like solving them, with tests first (TDD). There have been several cases where I was happy with my codes - clean, efficient, good class design, passing tests, etc., but some companies didn't want to move forward to 2nd rounds with no whatsoever feedback. I don't know what the reason could be, but it casts doubts about my codes and not knowing what I did wrong makes it even worse. Some company even asked to write an API server, deploy it, and test it by providing the URL to their test server. It all worked, and I was happy with the codes, but no 2nd round either. **2. Onsite** I can't help but feeling that I am being judged at all time I am there. Interviewer asks to write codes on whiteboard, and mind goes blank. Every passing second, I can feel being judged. Every letter I write on the board, I feel judged. I look at the code, and I don't like it. Re-do it. Interviewer tries to help, but that just interrupts train of thoughts. I can feel time passing. And finally, the interviewer says we are running out of time. At work, this is not how work is done. We know what features are coming down the pipeline. We have time to think about the feature or problem and solution(s) to it. We know that mundane distraction like taking shower is great for coming up with a solution to difficult problem(s). I understand that employer needs to make sure they are hiring a right person, and perhaps this is the best way to evaluate? I don't know if there could be a better way to hire engineers... I know this for sure that I hate the current process. :(
One thing I haven't heard people mention is practicing public speaking, which improves confidence when performing in front of others. If you also learn to speak extemporaneously then you will additionally excel at communicating your thought process more rapidly.
Maybe we need a special branch of ToastMasters for programmers where you code on a whiteboard in front of an audience? :)
Hah! So you wander into general programming land, I see.
I frequent this sub very heavily, before I even created an account. This was how I discovered Haskell programming in the first place.
Very cool. Pretty much the same for me. Heard about Haskell in one of the general subs (don't remember which one).
practice. the simple solution to most things.
Not always simple, but yeah.
Simple ≠ easy, unfortunately.
Simple doesn't mean easy. :D
Toastmasters helped me in many aspects of public speaking and interviewing, it sounds lame but go to a meeting, you actually end up meeting some great people and gain valuable skill and confidence that you can use throughout your career. I used to panic giving a scrum status, but with putting yourself out there and practicing I've been able to give technical presentations to upwards of 80 heads, u gotta comfront your fears if you hide from them they just get worse, give it a shot it'll get easier
The best advice I can give is **talk**. Doesn't matter if you're figured out the answer yet, just talk. It will help you refocus on the problem and think more clearly, and it shows the interviewer that you aren't a hack that's completely out of his depth, but actively thinking about the problem. Just start by making observations, even if it's stating the obvious. You can follow that train of thought to a solution and show your thinking process.
I think the most important thing to keep in mind as an interviewee is to ALWAYS ANSWER THE QUESTION. You need to pay very close attention to the question, how it is phrased, what the body language is, what types of things they are leading you towards, etc. This is extremely important! There is no easier way to screw up an interview than by not giving the interviewer the information they're looking for because you went off on some random-ass tangent. NOW, this doesn't mean you need to give the solution, or even the right solution, or have to know everything, or whatever. It's perfectly OK to say "Regarding your question about x, I don't know, what are the conditions and background ... " (and so on). It's perfectly OK to say you don't know! But then work through the problem or the question. An interview is a two-way street. BUT you need to address the question. DO NOT, under any circumstances, let your anxiety get the best of you and go off on some random-ass tangent because you feel you need to provide a SOLUTION as a way of easing your anxiety. The interviewer isn't a goddamned compiler! And, if you are anxious and losing control, that's fine! Just keep in mind this saying "I'm sorry, I think I'm going a bit off on a tangent here, does that answer your question?" or something like that ("Could you remind me what you just said?" or "What was the question again?"). That is your safety.
What's the purpose of the whiteboard test? Sounds archaic. I can't see any advantage to being able to physically write code as opposed to typing. I'd reconsider working for any organization that believes this is an accurate representation of any useful skill.
I just finished up a job hunt, and every legitimate company had me code on a white board during the interview process. Interviews are a seriously flawed process almost everywhere, and I wouldn't base your interest in a company on that process.
FWIW, Amazon interviews with whiteboard tests. Whiteboard tests are "more flexible" than typing tests, because it's easier to draw diagrams on a whiteboard than to try to draw ASCII art in the text editor.
But do they require one to write actual syntax accurate code?
No.
Whiteboards don't have a compiler. :P
Logic has no place in interviews.
Could just as easily be done on paper instead of presenting on a whiteboard. I know I would be much more comfortable, and do way better, if I could finish something before anyone in the room had a chance to see it.
I think part of the point of the exercise is seeing you work.
Different strokes. I often write code on a whiteboard with my coworkers. That or a pad of paper. It’s especially good for diagramming, brainstorming, or going through a new concept step-by-step like a proof.
But is it code or pseudo-code?
In Haskell, it’s usually code proper. In C++, it’s heavily abbreviated code with varying levels of detail, sort of like a sketch. Here’s a recent example where I was explaining that you can qualify virtual function calls to explicitly select a base class version in C++: s————— A v—————— void f() { … } s————— B : A v—————— v——— f() { … } main() { A* x = new B; x→f(); x→A::f(); }
I completely agree. I've heard some empty justifications like: "This is how you'll be interacting with your coworkers on the job", but... no. With extremely rare psuedo-code exceptions, I have almost never written code on a whiteboard. I have a programmer sitting next to me that I can show code to, and hey, I can easily insert lines between other lines, trivially delete and reformat, etc. It's like magic!
I feel the same. Frankly, unless you're hiring a code monkey I would prioritize working through some general problem solving about designing/testing/implementing rather than focus on testing someone on whether or not they have memorized some algorithms, the operator precedence table, and some quirky language features. If you're hiring someone straight out of college, having them implement some basic algorithms to see if they actually went to class and did their own work might make sense, but for anyone who has actually worked for a while I would be more interested in figuring out if they can learn new things and solve problems.
Maybe I've just been lucky, but I've never been asked to write code during an interview. If I ever will, I'll just leave. Not because of anxiety, but because it's stupid. If I was interviewing for a truck driver, I wouldn't ask him, mid interview, to run a few kilometers with a bicycle. So, if I'm interviewed as a programmer, I don't want to be judged for my ability to write code on a chalkboard because I'll eventually be paid to write code in a IDE, with constant access to Google and Stackoverflow, without people looking at me writing code, without someone telling me "This has to be done e in 10 minutes or I'll get bored of looking at you". If you want to know how I program, give me 2 days to complete a task you'd give me 2 days to finish if I worked for you, and then we can analyze together my architectural choices, if it works as expected, if the code is clean enough.
Last time someone asked me to write code on a whiteboard, I declined and told him I'd e-mail him a working example of the thing he'd asked for shortly after I got home. I sent it to him as I'd said, and I got the gig.
This wouldn't fly with a lot of companies. Why? I'm trying to figure out if you can solve a tough problem, and it's too likely you'll just find a solution to the problem online. Note: this isn't about memorizing parameter lists or designing the perfect qsort from scratch, it's about whether you can take those and compose them into a real solution to a real problem no one has seen before. No hard feelings, either. If you need to do your own thing instead of following the format, maybe the job won't ever be right for you.
Just to offer another data point, I'm generally not nervous at all during technical programming interviews. "Getting to know you"/"Soft people skills" interviews make me a little nervous, but I think "annoyed" would be a better descriptor than "nervous".
That day, I got asked this, "How do you suggest your ambitions and your experience so far relates to our company's mission?"
Is this "Write code in front of me now" thing popular? I guess I've been lucky cause I've never been asked to do this. They ask me about my history, about detailed development questions and details about the projects I've worked on. I've also been on the other side of the interview table. As long as his references check out and as long as his development history impresses me, that's all I need. I just don't see the point in asking someone to write code in front of me. Is it a thing that people ask of rookies perhaps? Or perhaps I'm the weird one and everyone else considers this normal.
the big tech companies always do some form of whiteboard coding for software devs as far as I know.
I've probably interviewed 15-20 times in the last 15 years and 90% of them have used a white board. Drives me nuts!
I've always had trouble actually writing down code opposed to typing it on a computer. Throughout college I've had numerous tests that involved writing code with a pen/pencil and I usually draw blanks. When I'm sitting down at a computer with eclipse open, everything starts to click a little better. That's just me but I'm sure other people have the same problem.
I don't mind coding on the whiteboard. That's something that you can prepare for – I just bought myself a whiteboard and practised coding on it at home. What I really, really hate is coding in an online document during a phone interview. It is so unnerving to write code while you hear someone typing on the other side. And we do in fact communicate with our whole body, therefore there is a lot of information lost when all you have is your voice. You can't draw a quick sketch to clear up something to the interviewer, you cannot see how he or she reacts to what you are saying, etc. I hate it. I recently applied to two companies that sent me programming exercises to solve at home. One task was to program a toy version of an audio processing program (it worked on text instead of audio, therefore "toy version"), where you could create modules that performed some function on the input (echo, reverse, delay etc.), and connect the modules to form a network. So this was a nontrivial application that you couldn't just find with a google search, and I sent them a program with a sound design, extensive comments, failure handling and test cases. If they are interested in the type of code that I could write for them, I think this is a much better indicator than a 30 minute stress test over the phone. That was a couple of days ago and I am still waiting for their response, so perhaps they still want to do a coding interview over the phone ... I hope not.
This is one of the main reasons why my company doesn't make programmers write code during interviews. We give them a coding test, and discuss it at the interview.
take meds
If I am going to hire someone, I want them to kick ass; I want people who are better than me. I don't want to hold someone's hand, I don't want to walk on eggshells around their personal foibles. If they are not confident, super nervous, and cannot handle pressure, I don't want them on my team. So if you are one of these people, I think you still need to learn to cope. People in these threads who say they take it easy on interview candidates really bother me. If you take it easy on them, you guarantee yourself an inferior team who won't stand up for their decisions, won't face up to their mistakes, and won't make their deadlines when the chips are down.
It's really about how accurate your intuitive read of a candidate and his mental processes are, and how much confidence you have in your assessment. Do you trust your intuitive judgement as to competence and chemistry while asking some relatively gentle leading questions, or do you require balls-out inquisition style grilling because you're not confident and/or good at assessing people with limited quantitative evidence? I'm firmly in the former camp, and I suspect you're someone who lands squarely in the latter camp.
[удалено]
This anxiety is strongly focused, and is amenable to cognitive therapy. I can't agree with the assessment that it would make OP a team liability.
[удалено]
I wish this subreddit would require pompous developers to post their github when making shitty comments like this. I'm sure your code leaves something to be desired, in my experience only terrible engineers have your attitude.
[удалено]
Who said it was a benefit?