After 10 years of working in web development, I was on the market a few months ago. It was the most humiliating and defeating experience ever. I basically failed all my whiteboard interviews (that includes using things like coderpad). Most of my interviewers didn't even ask me about my experience, just straight to test.<p>By the end of it, I decided I should just apply for Junior positions. I also got the advice that I have to take a couple months off to study for them. So that's what I did. (Not easy to do when you have mortgage to pay and a family to feed)<p>But what I hated most about the process is that there is very little feedback on why I didn't do well. Obviously they had a reason why they didn't like --me-- (edit:my code). I wish companies were more open to giving feedback. I gave you an hour of my time, it would be nice to get 5 minutes of debriefing.
In our technical interviews, we asked the following questions to our candidates:<p>- Find the most frequent integer in an array<p>- Find the common elements of two int arrays<p>- The buying/selling stock question from <a href="https://www.interviewcake.com/question/java/stock-price" rel="nofollow">https://www.interviewcake.com/question/java/stock-price</a> (slightly modified, I removed the word efficient as I only care about a correct solution, not the most efficient one, and we provided a data-set with a correct answer).<p>They were asked to bring their own laptop, and use their favourite editor, with the language of their own choosing, and setup a test environment.<p>It was an eye-opening experience to see how different the responses were, also how few that could actually solve the first two ones, I subscribe most of this to pressure to perform, but I think we at dodged two that was really good at talking, but had never opened their editor for at least a couple of years, despite their resume stating otherwise, and when asked about it they did programming every day.<p>I am all for finding better ways of interviewing for new engineers, and I really like their points about communication, but I am not sure giving them access to master and start hacking around is a fair challenge either, of course that is where the pairing aspect comes in, maybe it is worth a shot for our next round.
Whenever I interview, I pair with the candidate to built an arbitrary thing with a time limit. Often something from r/dailyprogrammer. This helps me understand how the grasp problems, parse the intent in the mind, and put that to something which solves the problem. We can talk about design choices together because if they get hired, we're going to collaborate in very much the same way.<p>I also allow the candidate to take the project home and finish/refactor if they want. I may have a follow up call to review as well. This elevates the pressure of the interview a bit as there is no requirement to deliver in time X.<p>I don't tend to have candidates work on "real" problems because I feel like it comes across as scummy to ask for free work. If I did, I'd make sure to compensate them for their time.<p>Edit: I only use r/dailyprogrammer as a source of challenges, I use the same challenge for all candidates.
What they left out of this pithy marketing pitch is that a recruiter will send you an email with 20 questions in it. Many of them are in depth multiple part questions. Essentially they were asking you to submit an essay before even speaking with a human being. When I responded that I would be happy to answer these questions in a conversational setting I was told that was not an option and I was also told "many people have told us they really enjoy answering these questions." No thanks CircleCI your process seemed DOA to me.
I interviewed with CircleCI years ago, and did an onsite with them, and it was a much preferable way to interview. I got to work with the actual team on actual production code and actual problems, which both gave me a very realistic expectation of what working there would be like, and gave the company a view of what my performance would be like.
I think people often try to emulate policies from large successful companies without necessarily understanding the context for why this policy would make sense for those particular companies, but not for others.<p>In a company like Google or Facebook, it may not matter whether or not you have any experience with technology X, because they have a large training organization that will teach you proprietary technology Y anyway. Their interview process might therefore come across as overly academic, because there's a good chance you might have to "study" and quickly learn something arbitrary as part of the job.<p>In a much smaller organization, it's unlikely that you will encounter any technology or basic problems that haven't been seen before and it's much more important that you have a baseline level of competence in your expected job. It's also less likely that they have an organization dedicated to training software engineers.<p>Logically, these very different types of companies should have very different interview processes, but that isn't always the case.
I've got 30+ years of programming experience and nearly 20 years of web app development experience, and I can't do these whiteboard interviews. They just don't work with the way my brain does. It doesn't matter how many projects I've worked on, how many clients made how much money from things I built for them, or how many people use my open source apps, all that matters is these humiliating stressful interview setups. I'm thinking about giving up on tech and switching to another line of work. It's genuinely breaking me, because I love coding. And I'm good at it.
> This is why you’ll pair with us on a real feature or bug.<p>I always wonder when I see these kinds of statements how they mesh with NDAs at your existing job. It's not as much of an issue here since you aren't getting paid, but it's still work for someone other than your current employer.
A little short on content, here's the main bit:<p>> Whiteboarding interviews are for companies who don’t know what they want. They’ll have you write until your hands are cramped, but all they’ll learn is how well you pseudocode on a wall.<p>Best interviews I've had that involved practical tests is where someone gave me a laptop, didn't bother me for 40 minutes, and had me make a thing (like a todo list app). We then talked about the decisions involved.<p>__Edit__: excellent point from Etheryte re: letting applicants use their own hardware.
Whiteboard is a medium to showcase your skill. People who can think in terms of pictures and demonstrate their thinking on white board are pretty good problem solvers. Not all companies and job roles need whiteboard coding. Companies have whiteboards and engineers use it to communicate with each other. It is a very effective tool. Interviewing is an art and bad interviewers make the process dehumanizing and boring. Do not hate the whiteboard. Some of the ideas programmers have are pretty complex, conversation and writing those are low bandwidth medium not adequate for interviews.
Something just feels inherently broken when the act of just doing the job isn't the same practice (training) necessary to interview for that same job. Why should I have to learn to "crack the coding interview"? I'm not trying to trick teams into thinking than I better than I am or know more than i actually know because I spend the last few days memorizing a few algorithms I never use.<p>I'm certainly not saying that teams don't take into account a candidates experience, OS code or his/her ability to discuss complex, role relevant, topics in great detail -- i'm just saying that no matter how high you rank in all these other areas, at most companies (including mines), it really doesn't matter if you can't reverse a linked list on the spot ¯\_(ツ)_/¯.<p>I just tend to believe that solving algorithms (especially under pressure) is a specific skill just like everything else, not a general test of programing "ability" -- so unless the job requires that you write algorithms every day then we should broaden the traits that we test for. That said, having interviewed a lot of candidates myself, it is truly difficult to consistently identify good well rounded candidates.
Our test is a shortish take home exercise: implement a simplified version our core business solution (a matching engine).<p>I judge candidates on:<p>- choice of abstractions<p>- quality of the tests<p>- readability (very important, reading code is x10 harder than writing it)<p>- knowledge of the language and it's libraries<p>- correctness of the solution<p>I penalize candidates for:<p>- reinventing the wheel (I.e. Roll their own sorting algo)<p>- overengineering<p>- unnecessarily convoluted, 'clever' solutions<p>- premature optimisation
Funny thing is, 18 years after my first programming job, I've yet to do a single whiteboard interview. (the bulk of my career has been contracting or CTO-level work for smaller companies; I've never taken a "startup lottery" job)
> We’ll have you work on actual bugs in our actual code<p>> you’ll pair with us on a real feature or bug<p>Are you paying people who are interviewing with you? Or are you getting them to do real work on your code for free?
We do whiteboard problems.<p>We want to hear what you think about when you write code. The actual amount of writing is pretty minimal, setting up the problems on the board is actually more writing than the solutions. There are certainly other ways to do it, but one of the most important thing we evaluate is whether you are willing to give it a go. If you are standoffish and unwilling to participate that is quite telling of how you will be when you are given tasks that aren't fun. Not all tasks are fun.
As long as I know that coding/algorithmic interviews are part of the process, I prefer whiteboarding. That's because it puts a lot more pressure on the interviewer to spot my bugs, if I have any. At this point, I'm a pretty good whiteboard programmer, and I know how to code to minimize bugs, but it does make things a bit more forgiving.
This essay, which touches on the subject of whiteboard coding, has some good food for thought on the subject: <a href="http://lacker.io/tech/2017/04/05/why-you-cant-say.html" rel="nofollow">http://lacker.io/tech/2017/04/05/why-you-cant-say.html</a>.
From my personal (start-up) experience, any interview that revolves around a whiteboard is a pretty reliable indicator of general incompetence.<p>It should also raise all sorts of flags if you are looking for diversity and innovation. If the hiring manager failed to evolve past the college days, he is most likely hiring identical 'text-book' engineers.<p>I have zero interest in innovating fizz-buzz.
I'm sorry... if you can't reverse a linked list, you should be ashamed to call yourself a hacker. Don't get pissed at me, go learn it right now. Know how? Force someone who doesn't to learn.<p>Edit: I know it's just a recruiting tool masquerading as a position piece.