I have observed a general frustration that good developers (who are in high demand) still need to do well in an interview setting. Frustrating as it may be, I think that embracing the reality is the best path forward.
A good developer would be smart to realize that this is a part of the project of finding a great new job, and would apply themselves fully to the subtask of preparing for and succeeding at an interview.
I think that, in the same way it is a necessary frustration to make sure the site performs well on IE8, a good developer recognizes the task as essential, and does what is necessary despite the perceived lack of significance.
Of course there is a limit to this lack of significance -- I am not advocating that people become professional interview-ees. But embracing the frustrations of a profession can give you a huge edge over those who don't.
If I were to be seeking employment right now, my first step would absolutely be to sign up for resources like this one, and dedicate a couple hours a day to honing my interview skills. It would be fun, and would develop a skill that opens a lot of doors.
I have observed a general frustration that good developers (who are in high demand) still need to do well in an interview setting.
I'm not sure it's frustrating so much as it is humiliating. Programmers (especially good ones) have egos that are somewhere between healthy and oversized. Interviewers assume you know nothing and make you qualify yourself at each and every interview, as if you were a fresh college graduate who hadn't already made his bones[0] at a dozen other jobs[1].
A good developer would be smart to realize that this is a part of the project of finding a great new job, and would apply themselves fully to the subtask of preparing for and succeeding at an interview.
Sadly enough, I couldn't agree more. Complaining on the internet is not a sufficient strategy for changing the face of tech hiring, so if you want to work, you have to deal with things as they are. Then again, the best way to find new jobs is through aggressive networking, not being able to reverse a binary tree on a whiteboard. So a good developer should probably focus on that instead.
[0]: yes, that's a very entitled attitude. On the other hand, if we had gone into an apprenticed trade, like woodworking or plumbing, it's expected that you already know your job by the time you hang your own shingle. It's a sad day when plumbers get more respect than programmers.
[1]: Just to nip this one in the bud: Yes, people lie on resumes. A short conversation about their work history where you ask for specifics should be enough to verify whether they actually did what they said they did. If they're good enough to bullshit their way through an interview, they're good enough to bullshit their way through a whiteboard programming session. If, for some bizarre reason you make a bad hire despite all the other filters you have set up, fire them and chalk it up to a mistake. If you do it over and over and over, re-evaluate how you do interviews.
> If they're good enough to bullshit their way through an interview, they're good enough to bullshit their way through a whiteboard programming session.
That's not been my experience. I've met a fair number of ace bullshitters who fell to pieces when it came time to write any code. I'm not talking missing a semi-colon here or there; I'm talking closer to "an observer who walked in afterwards might not be able to tell what problem I asked them to code."
I completely agree with you in that this is currently a weakness in the system, which can be exploited by those savvy enough to realize that they can gain a pretty large advantage simply by putting in a relatively small amount of dedicated work.
Having said that, if (as many of us believe) these sorts of interviews aren't a very good way to correlate candidates with desired job skills, then the situation is bad for companies, and for the efficiency of the industry as a whole, despite being a good thing for that set of people who are willing to gain an advantage through preparation. There are probably more useful things than preparing for interviews that people could be doing for that couple hours a day.
Sorry, but I have better things to do with my time than to waste it on employers who like to grill candidates on their knowledge of obscure algorithm & data structures and their ability to code under pressure with someone breathing down their neck at all times, when these skills have absolutely nothing to do with the jobs they're hiring for.
I also consider having the traditional interview process a huge red flag, since it's a good indicator that once hired, you may have to work with the kinds of employees that this kind of interview process tends to self-select for (i.e. extrovert bro-grammers who are experts at gaming the interview process but who won't necessarily know how to build a compelling, maintainable product).
I consider myself to be a generalist and pretty personable, the latter of which I don't think many folks remember to demonstrate during interviews, so I wholeheartedly agree with the points about chitchatting & showcasing your collaboration abilities. However, on the topic of working through a coding problem, I find myself struggling not so much with the asks per se, but rather, I focus too much on the fact that I'm thrown out of my usual dev/coding environments and working through a problem in a Word doc or some other non-text editor platform and it becomes a bit of a mental block. Compound that with the fact that my style of coding includes referring to existing code of my own or looking things up in mediums such as Google and StackOverflow to jump start me, and it becomes more of a crutch that does not aid me in these sorts of situations.
I can't agree with you enough, thanks for verifying that other people like me exist!
Give a person a specific task in a specific environment, and stand over them, and generally all you see is that they can bumble through something pretty unfamiliar under a high degree of stress and social pressure. This is a useful skill approximately 0% of the time in a real job. Or if it is a useful skill in the job, your team has more fundamental problems than hiring to worry about!
Give them a problem to solve. Full stop. Let them take their time, do it at home before the interview perhaps, or in a quiet room on their own with their own laptop, or whatever tools they want, internet access etc, with no real time limit. If they 'cheat', you'll know because when you discuss their solution in depth later it'll be clear as day. This will test what you're really after, their ability to solve problems - allowing tools, the web, whatever else to work for them and not be arbitrary hurdles to jump over under pressure.
You are not alone. I'm also the same type of person, who become nervous when interacting with the interviewer. I am fine talking to coworkers one-on-one or contributing ideas in the group meetings. But when it comes with the pressure of securing a job (not to mention that I, as a candidate, has to go through several rounds of interviews within a day), it becomes a bit too much.
You're exactly right. If you get some dork that wants you to code during an interview then walk out immediately.
That's not how the real world works.
That said, as a senior software engineer, you should be able to get on a whiteboard and brainstorm and defend some architectural designs.
Even then, it's so much more important that you're all on the "same page" and can collaborate on problem solving, rather than they hoping your freaking Richard Feynman and will solve cold fusion for them
I disagree completely. Every once in a while someone will slip through phone screens, etc. who does not have the foundational knowledge I want in someone who works for me. Asking them to write code to traverse a tree or implement strcpy in the language of their choice shows me if they lack the basic skills to continue taking up my time. Then we can work our way up the stack to debugging, design, architecture, and domain-specific knowledge.
Why, coding an utterly simple problem during an interview is fine. The purpose of doing this is to show the process of thinking and the ability to produce, explain, and modify simple code. BTW ability to identify the missing pieces and google for them can also be checked, for it's valuable.
Any thing that's longer than 10-15 lines should be a quiet-room task or a do-it-at-home task.
The industry loves tree questions, which is stupid -- the vast majority of us will never and definitely should never implement a tree. Red black trees are notoriously fidgety to get right; just use the free, tested, implementations that someone has already beat on for you. But we love asking that shit in interviews. I actually got in an argument with a former engineering manager who loved tree questions; I demanded to see where in our 10m line codebase we implemented a tree. Nowhere. But if you wanted to work for him, you had to know how to implement trees on whiteboards.
So practice so you're refreshed on trees and all the other trick questions we ask and not mentally refreshing yourself in the interview, and practice specifically coding on a whiteboard. That will help you remember to leave space to add more code and to write small and...
the whole thing is fucking stupid, but sometimes life makes you jump through hoops.
Also, and I think I read this on here, that stupid question about detecting loops in lists (hare and turtle) was an open research problem for quite a while, and wasn't published until 1969. Knuth, naturally. So either everyone in computing before then was stupid, or it's not obvious, and definitely not so obvious that thinking of it in 10 minutes at a whiteboard is reasonable. So really this is just asking if you studied, rather than if you're good at algorithms.
edit: I thought I'd read on here that someone was awarded a phd for figuring out the list cycle detection, but maybe I'm wrong? I don't have my notes file handy. Either way, it's not an obvious algorithm until you've seen it, and then it looks trivial.
At the risk of focusing on your specific example, rather than your larger point which is a good one:
If you're talking about balanced trees, I sort of agree with you. That's the kind of algorithm where it makes sense to write it once, test it thoroughly, stick it in a library and never worry about it again. But there are plenty of other uses for tree-like things. Think filesystems, or the HTML DOM, or JSON documents, or (generalizing a bit) dependency graphs, and so on...
I actually like tree problems. You can take something with practical significance (laying out a web page, or syncing two directories, or simplifying a boolean expression) and strip away the details of the situation to get to a core algorithm that depends only on the tree's structure. In my experience, the biggest factor in how well interviewees cope with kind of question is their ability to reason clearly about what their code is doing, instead of just pattern-matching from their previous experience.
Right, but for most tree problems, you don't need to write your own tree. People should know how to use trees, and when one would use them (a map with ordered traversals.) For graph problems you will often have to write your own graph for the peculiarities of your problem, but the area I work in doesn't really have many graph problems.
Linked list questions are great. They're a simple data structure so it's easy to talk about without complicated details. Detect a loop? That's a great question! Any decent dev should be able to start coming up with suboptimal ideas right away and would be an interesting discussion.
I look for test data. Up front. Particularly from developers with 3+ years of experience.
It demonstrates you understand the problem and are thinking about the cases that you will have to solve. It also acts as a good safety net for your implementation.
If you've got test data that will catch a bug, I won't count it against you in your implementation. However, if you've got a buggy implementation and you haven't provided test data for it, then it's broken.
I didn't do a lot of tests in my last work, but had a pretty good system. It was in house, so didn't matter so much if the odd bug slipped past.
I just changed job, and the system I have inherited doesn't seem to have much in the way of automated testing at all, but it works, and it runs. The logging is really thorough which helps a lot. The bugs I have encountered far wouldn't be caught by tests.
Blindly hitting candidates with a test is rude. There was definitely a trend a few years ago where bigger name companies wouldn't even look at resumes. They would just send a test out to every candidate who applied.
I help people all the time when they get stuck and still give them offers. But it depends on how you get stuck. If you're struggling in refactoring from O(n^2) to O(n) but are able to get back on track after we talk through some ideas then no biggie. If you get stuck with the concept of iterating through a list then there's probably not going to be an offer extended.
I don't know about entirely stuck, but I've definitely spent a long time in the weeds on questions, writing code on the whiteboard that was clearly sub-suboptimal. I've still gotten offers. It's all about managing the interview, communicating, asking for a hint or two. Not guaranteed, but definitely possible.
I just feel like I've been on a lot of unicorn hunt interviews recently (casually looking at interesting opportunities, currently pretty happily employed)
"Understand what kind of problem it is" could be reworded to "Find out what the interviewer wants from you, and don't make unstated assumptions", and could be the subject of its own post.
The biggest problem in technical interviews is when the candidate doesn't know what the interviewer wants from them. Maybe they want unit tests, maybe a rough functional spec... maybe what they really want to see is how you'd explain your algorithm to a junior developer.
If, as a candidate, you think you've been given an egotistical interviewer that really just wants to see if you can read his mind, mentally reframe it as a test of your ability to not make unstated assumptions. I've had interviews when I've tried to clarify whether I need to do things a certain way or provide something like unit tests, and met with the response "I don't know - do you think that's the kind of thing you should do?" If you get this as a candidate, the best solution is to talk a briefly about what you'd do in a real-world scenario (where you have context, tools, connectivity, time and teammates). If that doesn't reveal anything, explicitly state an assumption and why you're making it and move on.
If you give technical interviews, I implore you: when the candidate asks what you want from them, don't be coy or sneaky about it with the justification that figuring it out is part of the interview. Tell the candidate what you want. If what you want them to do is role-play a scenario where they extract requirements from you, tell them so. If you just want the damn FizzBuzz code so you can move on, tell them so.
> If you give technical interviews, I implore you: when the candidate asks what you want from them, don't be coy or sneaky about it with the justification that figuring it out is part of the interview. Tell the candidate what you want.
Man, this is so true. I've had great conversations in interviews where it was stated up-front that the goal was to cooperatively dig into ambiguous specifications. This is (often) an actual part of working as an developer. Speaking with someone who's being deliberately vague about what they want is not, unless that's what you think of people "on the business side," in which case you've got a bizarre understanding of how this industry works that would be a big red-flag for me as a potential colleague.
How uniform are tech interview questions, in others' experience? I've had questions all over the place, often entirely unrelated to the position at hand. A while back, interviewing for a gig at Microsoft on a server related position, I was asked questions about triangle rasterization algorithms and z-buffers, by an entirely unrelated group. What is the point of these off the wall questions, and how or should one even prepare for these sorts of things?
It's always been pretty random for me. I've been asked puzzle questions, to come up with my own idea and implement in their codebase, had interviewers who couldn't answer questions about their own puzzles, and been given automated code tests with invalid test cases.
Tech companies conduct interviews like 5-year-olds play soccer - everyone chasing the same prize with the same myopic strategy. And it's not that it can't be done better, but that everyone is afraid to take any _risk_ in order to improve it (if we don't chase the ball, someone else will get it and we won't!). No matter how broken the current system gets, we muddle through somehow and chalk it up to necessity (how else would you find good engineers?). Then we try to forget the whole thing even happened until we end up looking for a job again.
As a junior CS student - I haven't heard about these before... Kind of scared - Should I know about these kind of advanced things before I get out of school? I'm not attending a particularly 'rigorous' university for CS
It seems rather ridiculous to ask graphics-programming questions of someone interviewing for a server side position. I don't think any kind of preparation would help you with that kind of questions.
I asked the recruiter I had been working with about it, and her response was along the lines of: 'We only hire engineers who are capable of tackling any problem faced by the company.' ...
There is one kind of preparation: having graphics programming as a hobby, or failing that, an interest in everything under the sun and nonstop studying.
If you read an algorithms book, like Sedgwick's, you should be mostly set. Usually they're trying to figure out who actually understands how pointers, memory, and complexity work. (A lot of devs don't know basics at all, like binary search or even how to do am in place reversal of an array or something).
I wouldn't expect a very genre specific question (like graphics) unless they provided enough info that you could figure it out from first principles.
And sometimes they just wanna make sure you can think it through, even if you don't find the most optimal solution. A lot of devs simply give up with an "I don't know", without indicating that they have any ideas on how they'd figure it out.
I wouldn't worry about it too much. You're expected to have some holes in your knowledge, especially as a fresh graduate. Be prepared to talk generally about different data structures, and it's good to know the big-O time complexity of the common operations/algorithms.
But the bottom line is that developers are in such high demand that you'll get a job somewhere. After you work there a couple of years, your experience will be worth more than your degree. (Though the degree is still valuable, if you learned the theory/concepts well)
I wish that it were more like you've described here, but unfortunately, my experience is that the interviews will be very challenging, that you will need to know data structures very well, and that it really won't be enough to talk generally about these things. It might not even be enough to talk generally in a way that shows you understand how to use a data structure to solve a problem and sketch out a bit of code. It depends on the company, but to get an offer, you may need to write more or less accurate code at a whiteboard that solves a problem efficiently. Some minor syntax errors aren't a big deal, but overall, the code will need to be pretty tight and be close to working. Again, this is in my experience (I have interviewed at amazon and google, as well as smaller startups that seem to do the same thing).
I'd highly recommend "cracking the coding interview", and make sure you can handle even the moderate to difficult problems in about an hour at a whiteboard. Before you go to that, though, go back to your data structures and algorithms book and make sure you can do basic list, stack, queue, binary tree, hash, and binary operations. In other words, you should be able to build and print a linked list or binary search tree without much thought - if you can't do this, there's no way you'll be able to solve unanticipated whiteboard problems that use linked lists, trees, or other core data structures in a more elaborate way.
Your experience will be worth more than your degree, eventually, but you probably will still need to pass the technical interview/exams when you change jobs, even at more senior technical levels.
I'm not saying this is good, just saying this is how it is.
My experience in the midwest is much different. I know of a number of folks who were hired as developers with no coding/whiteboarding required.
That said, I would expect an interview at Google or Amazon to be tougher. Given their name recognition, they can afford to be choosy. The vast majority of companies cannot.
I've already worked 2 years as a intern for a tech company (full stack programming, webmaster duties, etc), so I feel like I'm in a good place. I just want to get a good tech job in the Northwest US and as far as I understand it is competitive
Edit: Thanks for the response - I'm enjoying learning about data structures and advanced things with data structs
Fairly random, though they generally break it into sections. Typically something to do with a high level overview of something, then digging into some finer details of it, then off to whiteboard some very unrelated code (fizz buzz, fibonacci terms, etc). Sometimes (not as often as I'd like) want to talk about my background and prior projects.
Do senior software engineers actually have to write code in interviews these days?
I have no problem brainstorming on a whiteboard with their CTO or senior architect, but I would consider it silly to do puzzle programs or write java with some middle-manager lurking over me
Unfortunately so. A ten minute chat with the HR drones who are able to answer virtually nothing about the role followed by a three hour hacker rank challenge or something similar. I even wrote a small application an stuck it n Heroku as an example of my work.
I used to be good at those kind of tests 15 years ago. Now I am orders of magnitude more competent at designing implementing and deploying systems I have way more knowledge in all of those areas, but I get tested on that nonsense. I hardly ever write algorithms (occasionally), as I will look for an appropraite library first.
Employer can't always make assumption that ones title match ones capability right? I do agree puzzle is silly, but some sort of programming question is required. To my understanding most senior SDE still need to write lots of code, and it's quite important check their code quality. Personally I've seen senior engineer made unnecessary type conversion which brings down production servers. I've even seen lead engineer write really shitty code with duplicate nested if statement and redundant for loops.
Yes, I interviewed with Facebook, LinkedIn, Google, Trimble, Qualcomm and Apple in the last 18 months for senior or staff engineer positions; all required white board coding.
In general the coding was not the most important part of the interview, just a check for experience and competence. For contrast, when I got my job with NASA 10 years ago the interview was almost entirely coding, and coding minutia in multiple languages. Maybe 30% design and algorithms and 70% code over 3 days of interviews.
Some great advice in this article. In general I'm a huge fan of the content on Interview Cake. Lots of good problems to work through with increasingly valuable hints to step you through if you get stuck.
My impression from interviews is that interviewers only care about Big O Notation and number puzzles. Nothing else matters. 30 seconds to come up with the optimum solution or else they tell you you're not a good fit. Hours of whiteboard coding goes fine and they say if you don't do the little puzzle then you don't know anything about algorithms. Thanks Facebook.
Practice is the key. Without practice, even communication isn't easy when you're being judged.
For core or senior engineering roles at big Internet companies, you're generally competing with candidates who have practiced for months. So unless you happen to have an astronomical IQ or you happen to get lucky, it pays to practice.
Parker is awesome and I love InterviewCake. If you want to come do more bootcamp-style intense practice, feel free to reach out to us: http://InterviewKickstart.com :-)
I like asking a refactoring / functional programming question in JavaScript like this one http://glebbahmutov.com/blog/functional-js-interview-questio... trying to make the candidate work through several small steps. At each step (step itself is pretty simple) I am looking for clarity and the candidate being able to explain the logic and the solution.
A good developer would be smart to realize that this is a part of the project of finding a great new job, and would apply themselves fully to the subtask of preparing for and succeeding at an interview.
I think that, in the same way it is a necessary frustration to make sure the site performs well on IE8, a good developer recognizes the task as essential, and does what is necessary despite the perceived lack of significance.
Of course there is a limit to this lack of significance -- I am not advocating that people become professional interview-ees. But embracing the frustrations of a profession can give you a huge edge over those who don't.
If I were to be seeking employment right now, my first step would absolutely be to sign up for resources like this one, and dedicate a couple hours a day to honing my interview skills. It would be fun, and would develop a skill that opens a lot of doors.