Well, these code/rpad/lity/rank sites are no different in terms of types of tasks... The problem is not only with a medium (whiteboard or *pad/lity/rank website) but also in what kind of problems you get to solve... Are these problems relevant to job? Is the condition/situation similar to what you'll be doing on the job? etc...
I thought I disliked whiteboard coding, until I recently had an interview on a provided laptop running one of those JavaScript IDEs. It was miserable. Extreme unusable OS X mouse acceleration, an awful keyboard, an unfamiliar hotkey setup in the text editor, and a tiny 11 inch monitor split into 4 sections which means my editor was maybe 10 lines tall. I failed miserably at a relatively short and simple challenge that I am confident I could code on a remotely familiar and sane computer setup. Heck, I would have preferred writing valid JavaScript on a whiteboard. At least I'd be able to see a lot more lines at a time, which it turns out is pretty important for my ability to code.
Sounds like a company to avoid if they throw the improper tool for the job at you and expect you to do it with that, even if a pen & paper would be better.
Some guys I've met, with different occupations and age, sincerely believe that smaller screens are more usable. Like small windows on 14" CRT when everyone had 17/19". Now it's guys that claim that 11-13" ultrabook is enough for them and they don't want more ever. This honestly baffles me every time.
I use only a small part of screen when writing code, because it somehow forces me to write shorter, cleaner functions. Although debugging is terrible experience on small monitors, because I need more windows open at the same time - watches, callstacks, ...
If you feel you didn't accomplish much at your last job(which would be a pretty common reason for quitting), then a question about it would be pretty stressful, since the company is evaluating you based on work you didn't find to be your best.
> Behavioral questions don't tend to freak engineers out.
Speak for yourself. I'm far more relaxed when diving into a technical question than when playing a guessing game about what social signalling I'm supposed to be doing at that moment.
You're not supposed to be trying to be someone you're not. If you have to put in that much effort during your day job then you won't be happy. You just need to relax and be yourself, it not only makes everyone more comfortable but it lets you and the company start to evaluate whether or not you're good cultural fits. You'd be pissed off if they mis-represented the culture there during the interview process, and they have just as much right to be pissed if you act completely differently (in a negative way) when you start working.
A terminal does not replace a whiteboard. I know some force candidates to code on whiteboard but that's not what it's specifically good for. A person to person discussion with a white board is the best communications platform for conveying technical ideas, IMO. You need the whiteboard, so both of you can define symbols, then discuss the meaning of these symbols by pointing at them, drawing arrows from them, expanding them, etc. The symbols can include fragments of code, of course.
So, yes, if someone wants to force another person to code on a whiteboard then certainly, they can do better, but it's like asking someone to draw with an axe on the stone floor. Waste of good axe and floor.
Hi. I'm the guy that made CoderPad. I bootstrapped the product out of nothing because of terrible candidate experiences older purely textual collaborative environments provided. I sincerely believe CoderPad gives you much more room to breathe than many alternatives. There are a few reasons for this:
1. You get to introspect the environment. I've had lots of candidates forget whether certain objects support simple methods (map, sort, join etc). CoderPad lets you perform quick tests to make sure.
2. You get to debug how you would normally debug. Whiteboard interviews basically rely on the interviewer saying something "Are you suuuuure there's no bugs on, say, lines 10 through 12?". I find this incredibly stressful as both the interviewer and candidate. CoderPad lets you run the damn thing yourself and see if it says what you want it to say.
3. Compared to probably the next most relevant comparison, graded homework assignments, I think CoderPad's free-form format is much more forgiving. As a candidate, I've definitely wasted hours trying to get some hidden automated test suite to pass with no feedback as to what sort of failure was encountered. CoderPad blends code evaluation with live feedback from the interviewer.
Yes, social pressure can be daunting for many candidates. I don't think this is something you can avoid in a live interview in general. I think you can get pretty good signal from project submission from candidates, but at the cost of greatly increased time spent by both candidates and interviewers. For many people this may be a worthwhile trade and I think additional options are good, too.
Regardless of how much your software has made me sweat, I still think it's great software. My comment was more about the interview process, not your software. Good job creating it. I wish it was free... Haha...
More specifically, I would say "interview pair programming" isn't really "pair programming." When pair programming, it's not one person evaluating the other, under an artificial time constraint.
I would like to see a compilation of companies that aren't requiring a "coding project" as part of their interview process. I much prefer to write on a whiteboard as part of an onsite interview than to do a "coding project" for every single company that "might" be interested in me.
My experience lately has been an immediate request to complete a coding project right after speaking to a recruiter but before speaking to anyone technical. And perhaps the height of absurdity I have even had automated emails saying "thank you for you interest we invite you to complete this coding challenge/project."
Are you really expected to do one of these now for every single company you send your CV?
The whiteboards seems far more respectful of people's time at least.
Presumably a lot fewer people send in completed coding projects, so you are competing against fewer other candidates.
If you are good at selling yourself, whiteboard interviews are awesome.
If you are nervous in interview situations, starting with a project could be an advantage.
Edited to add: coming in for a whiteboard interview will also take few hours of your time (or longer if you need to travel). A sample project can be done whenever you want.
I don't think that this is a proper justification for sending coding projects to everyone who submitted a CV. This is a big imbalance in time investment from both sides and quite disrespectful from the applications point of view.
It's not disrespectful for a company to ask you to write a little code for them. They're just as invested on the time front as you are since they have to read and analyze what you send them.
Now, if you were to tell me that nobody ever looked at the test after you sent it in, then it becomes disrespectful. I had several companies do that to me a few months ago.
Not that it matters much. I don't think code tests will stick around. It's too time consuming for the hiring managers.
A little time is fine but last time I was applying for developer jobs almost all of these tasks would take at least an hour to complete, probably more like two or three to do it in a way I'm willing to show to someone screening me on that basis.
By requiring these tasks you're implicitly screening not only people who can't code but also people who don't have three hours to spend on applying to your company. If all you want is 20-somethings with no other responsibilities then continue as you are, but if you'd like to see a bit of diversity then you're going to have to compromise.
But this is an endless cycle. At some point, the company has to apply some test to see if the candidate is appropriate, IE, can code to the required standard. That will require a time investment from the candidate.
You could simply get rid of the take home test; that will shift the burden to the resume and cover letter, to the advantage of humanities graduates like me.
You could mandate a full day on-site, which will bias against people from out of town who want to relocate and people in delicate situations at their current employer.
For the time poor candidate, there is always the whiteboard exercise... Whose biases we are gathered here to moan about in the first place.
I always feel in these threads that people think hiring is 'broken' and it can be 'fixed' with the proper application of 'one weird trick'. But then all the comments actually have contradictory complaints. So obviously it can't.
I'm not really advocating for getting rid of take home tests entirely. There's a lot of value in seeing how someone approaches a known problem and being able to compare that to other solutions.
What I am asking is that companies don't ask me to invest hours of time before they decide if they're even interested in talking to me. At the very least I want to have had a phone interview and the chance to assess whether I'm even interested in working for you. That's particularly relevant when looking for remote friendly employers, I've had several calls in recent days from recruiters responding to me saying I'm looking for remote work which I stopped on finding out what they meant was "at least three months fulltime on site, and then maybe we'll talk about some remote work".
>"What I am asking is that companies don't ask me to invest hours of time before they decide if they're even interested in talking to me."
I feel like this is the crux of it as well. I am not against projects or tests to show I am technically qualified. But this should be after talking to some potential team mates to see if there is even a fit, personally, work culture-wise, technical interest or any number of factors that you could glean by speaking to potential colleagues for 20 or 30 minutes.
An hour of time for a homework is completely fine. A whiteboard interview would consume much more of both party's time. Just travelling there and back can easily take an hour of applicant's time.
I used to invite people for an interview without any prior testing, but it was generally such a big waste of time for both me and applicant. What's more, quite often I can see from CV that someone is underqualified, but I do not want to reject them immediately without giving them a chance, so I send them a homework. Finally, you would be surprise how often even people with good CVs turn out to be quite bad.
Hmm. One of the best exercises I ever had to solve took me almost a day. [1] I have actually rewritten it twice, once in the manner they said they would have wanted it (same repo) and once in Python. (I didn't get the job, they didn't like the style I was using.)
I don't mind long coding exercises, it's what I do all day anyway. Better than watching yet another episode of NCIS or what have you :)
If you're hiring backend engineers, code tests can be easily automated away on the correctness and efficiency aspects. Add lint on top and and an engineer eyeballing the style for a few minutes. Voilà, 4 reports per employee hour.
If it's automated, or direct from a recruiter - chances are the company hasn't even read my CV. Or looked at any of the previous work I've included. Of course it's disrespectful.
>"Why would a company look at your CV? At best, it's full of exaggeration. At worst, outright lies."
So by your reasoning CVs are not meaningful at all. Should we get rid of them? Why stop there though, should we not even discuss past projects we have worked on in interviews since those are also likely exaggerations and possibly outright lies?
To the people who say spending "4 hours is more like 6-8 hours and it is unreasonable":
- How is this any different than spending an unreasonable amount of time studying balancing binary trees and similar trivial whiteboarding problems?
I'm of the opinion that studying all these variations of the algorithm problems is a bigger time-sink and waste of time than getting into the habit of problem solving a take-home project.
Yea but the process is never just coding project... It's either just whiteboard interviews or a coding project and then whiteboard interviews. There's never a reduction in time here
> The whiteboards seems far more respectful of people's time at least.
Some companies will happily bring you on site for a full round even though they have no idea whether there is an open position for you (infamous example, you can pass Google's hiring committee and then be told there's no headcount). And you've just wasted one day off.
On the other hand, take-home projects can be used in a way that saves everyone a lot of time. I don't disagree with you, they shouldn't be used for screening though.
>"Some companies will happily bring you on site for a full round even though they have no idea whether there is an open position for you (infamous example, you can pass Google's hiring committee and then be told there's no headcount)."
In practice though this is kind of rare especially for the larger SV companies. I'm not saying it's never happened but that Google incident sounds like an anomaly.
How do take home projects save time if they take between 4 - 8 hours? That's the same time as an onsite takes. The difference being that before a company brings you onsite there has probably been at least a technical phone screen or two so the candidate has ben "qualified" to some extent no?
Not everyone lives in the SV. If you interview at a satellite branch of a company that has a big and generic interviewing pipeline, it can definitely happen.
I can do a 4 hour[1] assignment on my own time, assuming I'm not given an unreasonable deadline. For a full round of interviews on site, I need to take a day off. That's a huge difference to me.
[1] I've rarely been given any assignment taking more than 2-3 hours, I would flat out refuse anything that can take more than 4.
Edit: oh and I can give you a very long list of companies that thought I was "qualified" after 1/2/3 phone screens, wasted a lot of my time afterwards, and ended up deciding I wasn't :)
I am interested in this too. I recently failed netflix code review because I used java 7 instead of java 8 which apparently showed them I don't keep up with new technology (even tough the question asked me to pick any language on jvm.) Other reasons given to me were that i used maven instead of gradle.
> all my open source code is written in java 8 for him to look
That completely defeats the purpose of a small, self-contained assignment like the one you were given. And your code isn't even in Java 7 (no diamonds), I think it was a legitimate remark.
Do you have any examples of companies that have asked this of you? I'd actually really like to apply; that seems like a fantastic way to gain some experience outside of my daily job.
Zalando, Bloomberg(you won't get to speak to anyone, immediately asked for code), Soundcloud(speak to a recruiter but nobody technical and then asked for a code project before)
These are just off the top of my head, however theres no shortage.
Am I the only one who thinks the pressure a whiteboard adds is actually something valuable? In my last job there were a lot of situations where you had to solve a real problem under extreme pressure. People who couldn't handle it simply weren't cut for the job.
I don't think all interviews should use it but for us it was good for filtering out candidates who would not perform in those situations.
In my experience, if you're regularly coding under extreme pressure, something is wrong.
Whiteboard coding is also a different kind of pressure. I can't imagine a situation where someone who already knows the answer is watching over your shoulder critiquing you while you work on a problem.
> In my experience, if you're regularly coding under extreme pressure, something is wrong.
right? unless you are in downtime mode, there's really something wrong with your schedule/deliverables/tasks.
writing code is not a race, it's more of a marathon where you have to be at a healthy pace to get to the end, otherwise you will not be able to finish.
What on earth were you doing that required solving software problems under extreme pressure?!
This sounds like an incredibly toxic working environment, where developers are either being allowed to create fires on production systems, or management is completely incompetent or both.
Also, being able to "handle it" has nothing to do with anything in this discussion. I'd much prefer to hire someone capable enough to not need to "handle it" than someone proud of the fact that they often s*it the bed but are willing to jump up and do the laundry under pressure.
Toxic or not it's the reality for many companies. You speak like everyone has unlimited resources. For us it was a combination of legacy code and working with big external parties that set the rules (government APIs etc).
I personally enjoyed it but it's not for everyone.
I find the pressure of significant code on a whiteboard to be very different even from producing under pressure.
I think it comes down to expectations - in an interview I have to focus on impressing my audience and that's always there. In real life, I can focus fully on the actual problem being solved.
I agree, although I prefer a physical computer or shared session to whiteboard. I always tell interviewees that they can use pseudo-code or make up functions as long as they explain what they are intended to do. This takes the pressure off of knowing specific language constructs and leads to better overall assessment in my experience.
As a follow up to the first interview, we give promising candidates a quite simple task to solve at home and then send back via email the next day. This is used both for some basic evaluation of developers skills (whether they actually solved the problem, did they catch the small oddities hidden in the data set, did they document and write tests, etc.) and as something to discuss during the second interview, in which the candidate talks to one or two developers.
I also did a second code test, which I got to do alone on an offline laptop. The test had a time limit and it was designed in a way that you should NOT be able to finish it on time. This was communicated to me several times before I actually sat down in front of the laptop. The goal with this test is to see if a person can solve problems under stress, and if the person writes decent code that works, or just hacks something together and moves on to the next step - leaving a trail of bugs.
Overall, I think this has worked out great for us, but it might not be a good process for everyone.
Some time ago somebody mention in HN a process which sounded pretty good and fair. For promising candidates:
1) Meeting where you are presented a problem and asked to immediately give your thoughts on how you would approach it.
2) Some days, for example weekend, to work on the problem. Candidate gets a monetary compensation for this time.
3) Next meeting where you present the solution.
Yes, there's always a risk that somebody will get somebody else to write the code, but having to explain before and after reduces the risk. Paying for the work shows you are serious about the recruitment.
You expect people to write documentation and tests for an interview coding challenge? I sure hope you mention that expectation or at least strongly hint that you're looking for a production-ready coding mindset. It would never in a million years occur to me to write documentation or tests for an interview coding challenge.
This honestly surprises me. The coding challenges are pretty much always simple enough for a junior to complete. The only way I've ever seen to set yourself apart from the bottom half of applicants is to include tests, comments and even documentation. I also wouldn't expect that to be in the instructions, otherwise everyone would do it and you'd be harder pressed to find candidates to eliminate. I'm curious to know if completing the challenges without tests etc is commonplace. Does anyone else think it's an odd thing to expect?
So the company gives you a limited amount of time and no access to the internet and expect you not to hack something together?
If I have a problem to solve "under stress", usually it's just a one off to fix something in production until I have time to write it, refactor it, put a unit test around it, and a code review.
Yeah why not just ask a surgeon to perform in a janitor's cupboard. No gauze? No problem, improvise with a mop. Remember, the aim is not to actually perform the procedure, just see if you solve problems under stress.
I'm responsible for hiring developers at our company based in Berlin, Germany, and found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. I never understood the whiteboard hazing/CS trivia that are so widely discussed on HN since it seems extremely disconnected from the actual work that's being done.
That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of.
We worked with an HR consultant to develop a interview guide in the form of certain questions that we make sure to hit during the interview in order to be able to compare between candidates and make an informed decision.
However, we're small and not in the US. Anyone have experience with other companies in Germany/Europe? How does the typical interview work over here?
"found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. "
When I've been job hunting in the past I've also found that these have been the best situations for me. I find coding questions beyond fizbuzz totally silly and when something more is requested of me my attitude shows this.
> found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved.
This. I advocate this method of interviewing here in the states every chance I get. The most common form of push back I get is from hiring managers terrified of being hoodwinked into making a bad hire. It's like they don't trust their own judgement enough to be able to tell apart those who know what they're talking about from those who just talk a good game.
> I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of
Junior engineers, I assume? I had problems with those questions when I first started out. It's hard to say with a straight face that the thing I was most proud of at that point in my career was creating a very simple templating system in PHP. Of course, the interviewers rolling their eyes and saying 'is that all?' didn't help.
> It's like they don't trust their own judgement enough to be able to tell apart those who know what they're talking about from those who just talk a good game.
Which is usually the case in larger companies, I assume. The person doing the hiring in that case is far removed from the people and work actually connected with the candidate.
> Junior engineers, I assume?
You're right, that's surely part of it. Not only, however - sometimes you get the feeling that work is something that happens to people, not something they seek out and try to get better at. Which for many positions is completely fine.
I'm not sure why there is such extreme hate for the whiteboard. Yes it has plenty of caveats when it comes to actual coding and recruiters should not expect any candidate to write precise code on that medium.
I do use the whiteboard for trivial CS questions limited to 5-10 minutes. Think fizzbuzz and string reversal. Candidates have the option to use my laptop (not ideal because the keyboard has a US layout) but they are welcome to use their own computer as well (if they thought about bringing it). It weeds out candidates who can't even produce basic code. And yes, a candidate with 2+ years of experience should be able to write a basic function on a whiteboard, a napkin, or whatever. If not, the interview is not lost but the candidate will have to prove his skills another way.
For most candidates, we also give a longer technical test which is to be done at home and takes 2 to 4 hours to complete. Candidates are given as many days as they want to complete it.
Whiteboard is an excellent medium however when discussing architecture and higher level ideas. It's also a tool that I've used during day to day activities with colleagues. Software based tools don't come even close.
Interesting! I actually love using the whiteboard to sketch solutions and architectural decisions. I believe the hate comes from having to code on a whiteboard - which is justified, since no one ever coded on a whiteboard except in an interview.
I believe the hate comes from unprecedented and hard CS questions asked on the whiteboard.
I recently went to an interview that asked me to balance a binary tree on a whiteboard. It can be done, and I can do it. Thing is when you go to interview for that company that has 2 developers(small team, small company) and ask you that kind of question it puts you off thinking that those guys won't be great to work with (arrogance etc comes in mind).
I am fond of simpler questions, like you said fizzbuz etc. Obviously if you are interviewing a guy that has 2+ years of experience, he has to be able to pass the fizzbuzz test.
When you are interviewing someone with 5+ years of experience for a higher up position I guess you do have to ask some harder question, but I personally think just speaking to the guy and asking him stuff about his past projects etc will give you a hint on if he has the skills he is talking about or not. Asking him to outline a hard task he took part and how he solved it is an amazing start. As a 5+ years guy personally would rumble about a few things and it would take me days talking about them. (That will give you an understanding if I've worked before or not on the things outlined on my CV).
This can also be an education problem. There can be big mismatches in what is easy and hard
If you're coming from a more FP background things like flipping a binary tree are silly obvious. If you spend a lot of time with C++, of course you know how to write a linked list with memory management. Python devs are probably way better at slicing and dicing data
There's a certain expectation of what's easy and hard, but it's really easy to have a mismatch given the diversity of education out there.
It's also that coders tend to... err... "offload" memory for the stuff they aren't immediately using on a daily basis, and only remember the general terms and names that would be enough to find and remember the details shall they be required.
Last time I've had to do something with the trees implementation details (IIRC, that was AVL trees) was, like, 5 years ago. Right now, I don't exactly remember anything about AVL trees except for they have that nice O(log n) for lookups, insertions and deletions. Would I need to code them from scratch (or remember their internal workings for any other reason, like debugging some core dump), I'd go find the algorithm description (or particular implementation's source) and do so.
At the same time, last time I've worked with balanced trees was just a few days ago, but that was Erlang's `gb_trees` module that did all the stuff and I just had to freshen my memory on the syntax details.
All I would be able to do on a whiteboard is stare for a minute, trying to remember stuff, then probably say "uh, sorry, I don't remember this stuff - haven't did that in a long while". Yes, that makes me a worse programmer, I guess, but are interviewers actually looking for those who remember everything in their head and write code on whiteboard? Looks like a weird case to me that doesn't have to do anything with reality.
I've been coding for about 25 years. The last time I had to write any code related to binary trees was in school, 15-16 years ago.
Given enough time and debugging I'm sure I could do it. I'm not going to be successful on a whiteboard though. If I actually had to do it I'd look it up instead of wasting my time figuring it out.
Unless you're interviewing for a position where they'll have to implement binary trees you shouldn't be wasting time asking about code for them. Questions should be relevant to the position.
Additionally: Nine times out of ten, you shouldn't be implementing the binary tree in the first place. There are already tons of tested, robust libraries out there that will do it a lot better than you can, handling all conceivable edge cases, available in a variety of license flavors. Many languages' standard libraries include support for binary trees.
You want candidates who can work through the buy-vs-build tradeoffs.
Reminds me of when I was asked to implement a filesystem API in C or C++ with file manipulation and path parsing and whatnot. The best answer I can think of is usually "With no weird constraints given (is this an embedded system, for example?) just use boost::filesystem and move on with your life." Not impressed with this answer, the interviewer would continue with "assume you can't use Boost!" Next answer is: "There are a variety of filesystem abstractions already written, far better than I could whiteboard. I'd go through each one and pick the one most suitable to the project." I thought it was a trick question at first. You really DO NOT want candidates who hear that question and launch into writing code!!
It's obvious that they're not going to use the code you wrote at an interview in production. So "just use a library" is not a relevant answer. The question was probably posed to give you an interesting engineering challenge to work through with the interviewer so that they could see your problem solving process. Instead you just argued with the interviewer.
The GP's point (which I supported) is that it's a waste of time to take a candidate through scenarios that are not at least similar to what they'd actually encounter doing the actual job.
But the point is that if you cant do something so simple, like traverse a tree, then you probably don't understand how trees work to begin with.
Similarly, I've never had to implement fizz buzz for real, actual, work. But I wouldn't trust a programmer who was incapable of doing fizz buzz without importing a fizz buzz library.
But the earlier comment wasn't talking about _traversing_ a tree, it was talking about _balancing_ it, which is a much harder problem and one I wouldn't want to do without google either.
It took me 5 minutes on my laptop at home to code out a problem that I danced around for an hour on a whiteboard being stared down at by 2 engineers in silence. Yes, I had the benefit of hindsight, but unless you've actually done a whiteboard interview yourself where your livelihood is on the line for an hour, don't act like a trivialising nonce.
What is the field you hire coders for? Because for the mine (iOS) your ability to code fizzbuzz have little relevance. The knowledge of APIs, common patterns, ObjC vs. Swift, common means to handle dependencies, etc. etc. is impossible(?) to fake if you do not have relevant experience you claim you do.
As an iOS developer, I would still get whiteboard questions ranging from "reverse this string" to "find all the anagrams in this array and print them in this specific fashion", usually with iOS specific trivia about view controller lifecycle, UIKit (whats the diff between frame and bound?), etc. sometime before or after the whiteboarding
Sure but if you cant program fizz buzz, that means you don't know what an if statement is.
Fizz buzz tests for "does this person know what a function is, what an if statement is, and the modulo operator". And frankly, I'd give the modulo answer away for free if the candidate asked.
All programmers should know what a function and an if statement is.
> I do use the whiteboard for trivial CS questions limited to 5-10 minutes. Think fizzbuzz and string reversal.
Why do people keep saying string reversal is easy? Text is one of the hardest things out there. Unless you expect your programmers to support ASCII only?
Why not reverse a list or an array? That does sound like something that is doable in 5-10 minutes.
Thank you. A great response to "reverse a string" is "What's the encoding?" If it's anything but ASCII, you're in for a long white boarding session. If the interviewer doesn't know what you're talking about, back away slowly......
what makes other encodings hard ? The two things that come to my mind are byte length and comparison function. If the encoding had a fixed-length byte length, then it should be just swapping n-bytes at a time instead of 1-byte. What else is difficult about non-ascii encodings ?
Some examples: If you're dealing with UTF-8, which is very common, you need to handle variable-length characters. If you're working with UTF-16 you need to handle surrogate pairs. Neither are the end of the world, but the basic "array walking" string reversal methods you'd expect from a white boarding session wouldn't work.
e.g. in UTF-8 a codepoint is encoded in varying byte lengths (so you have to split into codepoints and then reverse), and, a lot more difficult, a sequence of multiple codepoints can be combined to form a symbol. Simplest case would be something like "ö" encoded as "o" (U+006F) followed by a combining diaeresis (U+0308).
Other fun special cases: 🇺🇸 is U+1F1FA REGIONAL INDICATOR SYMBOL LETTER U, followed by U+1F1F8 REGIONAL INDICATOR SYMBOL LETTER S and should if possible be displayed as a US flag (otherwise falls back to text "US"), should reversing it create 🇸🇺 (replacing the flag with the characters "SU"), or still show the flag? (I'm not even sure if there isn't a case where both are valid country codes and it would change to a different flag?)
Similarly, Emoji can be formed from a sequence with combining characters inbetween, which don't display correctly if reversed codepoint by codepoint.
This is why I like the question. As an interviewer, I will leave that matter open and see if the candidate asks for clarification. If so, bonus! But I will tell them to just
solve for ASCII.
The worst-case scenario is a "self-hazing" where someone
sees the encoding difficulties and freezes up instead of
asking for clarification. I've never seen that happen
though, in my experience though, everyone -- even the good ones -- just assume ASCII.
Well, OK, if you are using C or something, and traversing through binary it is hard.
But if you are in python, and given a string object, and told to reverse it without using the reverse method.... Yeah, that's easy. You should be able to do that.
Also from Europe, and we have a similar approach, discussion with the candidate about previous work, interesting problems, any public code they've written, etc. Just to figure out what kind of challenges excite them, and get to know them better.
We also do a coding challenge after that, basically the candidate behind a computer, with all the resources they want accessible to them, implementing a simple example directly relevant to the type of work they'll be doing, while the interviewers are in the room and debate with them if needed.
To me, the most important quality in a candidate, once we determine that the basic skill level is good enough, is their ability to learn, quickly find the resources needed, and rely on the team when they need help. Whiteboard interviews don't seem to select for any of those qualities.
> That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of.
I have trouble recalling the details of things I worked on even say a week ago sometimes. I also don't find most of the work I do that interesting as I've been coding along time solving the same kinds of problems. However to play the game i would of course brush up for questions like that, and be quite convincing.
> I have trouble recalling the details of things I worked on even say a week ago sometimes.
No problem here, it probably wasn't very exciting but have you never encountered something which stuck in your mind? Or that you could at least recall some part of a project if someone asked "So, you've written here that you've worked on project xy and did this and that, can you tell us a bit more about it"?
Asking about project xy is different though, it's more guided. I think it's much easier to answer than the really open ended ones that ask you to pick an incident from all 10-15 years of your work history: the field there is so wide that unless I've specifically considered the question in advance I'm likely to sit there going ummm for a bit.
In general I think the question format favours people with a good memory for anecdotes and story telling ability.
> That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of.
It could be that this technique favors people good at telling stories.
Personally, I'm a horrible storyteller. If you were to ask me what I did over the weekend, I'll offer some facts like "oh, went swimming in a river and Bob lost his hat, but we found it later. The water was nice." Whereas Bob could easily regale you with stories about the epic hunt for his hat and throw in a punchline in the end.
If I didn't know that you'd be asking for solutions I'm proud of, I might draw a blank at that moment. Granted it's an interview setting and these are the questions one needs to prepare for. But if given the choice between speaking about myself or whiteboarding, I'll take the whiteboard.
I've always preferred math over history for that matter. It's easier for some of us to apply processes than to recite chronologies.
Good point. When I notice that people are struggling with finding something, I usually just pick one thing from the resume and try to go more in depth about that.
Companies differ, and what they are asking of software engineers.
I was working with a brilliant guy in the same company. He was very technical and you could say that easily he was programming all day long non stop. His intelligence and technical expertise amazed me. Thing is he wasn't good with people skills, hence he wouldn't fit the company I am currently working for.
There are companies that hire devs to solve a problem and give them time, space etc to go all hardcore.
Then again there are companies that require from their dev's to be able to communicate with the rest of the team, and take part on meaningful theory-crafting meetings.
So neither whiteboarding, nor tell me a story question is wrong.
I just find it that whiteboarding difficult questions should be asked from the very technical jobs, and I've found whiteboarding difficult questions when interviewing for a company that wants to move out of wordpress to their own website in angular.
I think many will be able to tell the story if it is a story about something they care a lot about.
Also, there is an opinion that good developers are good communicators.
> > That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of.
> It could be that this technique favors people good at telling stories.
Or people who think they're impressive. I know I would've been able to point out many problems and solutions I found interesting and were impressed with when I was 15. Today, not so much. The more I know, the less impressed I am with myself, and more and more stuff just feels "routine" and nothing special.
At this point in my career I'd have to say I agree. Many of my team are at the start of their careers. I find it really interesting the number of times they seem impressed by something I did that I'm just "meh" about.
Oddly enough, the opposite is true as well. I'm constantly impressed at the level of ability they have at this point in their career as compared to my ability at the same point in my career. They just simply know more. Of course, there's more to know these days but still, I find it impressive.
I'm not a "look at me!" kind of person, but here's what has really helped me with these kinds of interviews.
Keep a daily journal of what you work on. Nothing fancy, just stop by once a day religiously and add a few notes on what you did, what meetings you attended, who you spoke with, etc...
Save your evaluations and especially any award packages you or your team might get submitted for. At least where I work both are your supervisor's attempt to make you look as good as possible.
Then, when you're job hunting review your notes and bullets and collect the ones that sound the best and perhaps ones that have numbers assigned to them (size, savings, productivity, etc..)
Preferably you'd memorize these few stories about yourself, but if you must you could also bring a notebook with prompts to remind you.
If someone brought along an notebook full of problems they'd experienced and how they'd solved them to an interview I was conducting I would be very impressed!
My grandfather used to do this. He had notebooks filled with what he did every day of his career. It's really cool to be able to go back and look through his notebooks and see what he was doing in April of 1971.
My notetaking is not as rigorous as my Grandfathers, but I do something similar. Every month I make a new manilla folder with the month and year on the tab. Each week I write down every project I'm working on and every meeting I have. If someone brings me a new project I put it on the sheet. Every note I take a meetings and during projects goes in that folder.
At the end of each week I go through the notes from that week and write down anything interesting on that week's note sheet. At the end of the month I go through all the notes and write what I accomplished on the front of each manila folder.
It makes it really easy to keep track of everything you've done, without consciously keeping a journal in the moment. It's also a really easy organizational system. When someone asks, "What did we do for [x] in the past", all I need to do is flip through my folders looking at the front for anything that rings a bell, rather than trying to keep up with a tagged organizational system.
This probably doesn't work if you don't have a file cabinet though.
This is great advice, thanks. In the past six months, I've been better about keeping notes. Not specifically for this, but this is definitely another benefit of journaling.
> If I didn't know that you'd be asking for solutions I'm proud of, I might draw a blank at that moment. Granted it's an interview setting and these are the questions one needs to prepare for.
The key word there is "prepare". These are standard interview questions that you just have to have a prepared, rehearsed answer for that you can rattle off without thinking. There are tons of these types of "behavioral" questions. Tell me about a project that you worked on that failed. Tell me about a time you had to deal with team conflict. Talk about a struggling project that you had to help turn around. You can get a book full of them. Be ready with canned answers for as many as you can and practice them in front of a mirror.
Yup, whiteboarding and reciting tried and true stories are inevitable routines when interviewing. However, you'd also be surprised at how many people don't know how to prepare for this. My main concern would be the possibility of turning a great candidate down just because they didn't happen to interview well.
> My main concern would be the possibility of turning a great candidate down just because they didn't happen to interview well.
Too bad (for candidates) that that concern doesn't appear to be shared by... well almost everyone in tech hiring these days. The general wisdom of the day seems to be "it's better to eliminate 100 false negatives than hire one false positive."
Probably because it's "easier to hire than to fire".
I worked with some really great folks that had trouble getting hired and it was because of the flawed interview process. One person writes concise and clear Rails code that's easy to read, and makes some of the wittiest comments on Slack (subtle puns that go unrealised for two minutes, then you finally get it and makes you smile). But he stutters a bit. And because of that, interviews are difficult for him. Which is a real pity, because in less judgmental situations, no one would think twice about that.
(Don't worry there's a happy ending and he's now at a good company.)
I learned after my first university job fair the necessity of being more outgoing during these situations, but there's great engineers out there who still live by the myth of "they'll know me by my work".
Generally speaking, someone's ability to recall things is very dependent on how they're feeling. If you're happy, it's easy to recall positive things, if you're depressed it's practically impossible.
A lot of developers also have imposter syndrome. After I've solved an interesting problem, within a few days i'll probably have dismissed it as not being a big deal and started to forget about it.
These kind of questions are useful, but candidates should be preparing their talking points, because the risk of forgetting the story that's going to get you hired is too high
Yes. I read about this idea a few years ago (tell a story about a project you liked) so I had to make an effort to focus on ONE story and tell it well. I've been doing it a couple dozen times so far (I'm a contractor who likes small projects, six months is starting to get too long) and I've had significant success with it.
(When I think about the problem "objectively", all I did was use SSDT to simplify deploying database changes from QA to production without having to shut down either. No big deal. However, it was something that the company had been doing manually for years, spending three error-prone days each month, and they were extremely happy with my solution.)
We are currently hiring. Denmark. We received i think few hundreds applications, picked 20, discussed internally, picked 5. Those 5 received invitation for homework, simple functional Javascript exercise. We dropped 2, the rest received invitation for UI Javascript exercise, vanilla btw. Then we talked with them. Picked one. In my previous gig in UK we had 3 homeworks and then chat. Sometimes we did drop the third when candidate was exceptional. So far only one candidate refused homework next stage, but the first stage result was bad enough for us to not consider him anyway. All top candidates and hires were eager to do the homework.
So true.. and this is a great interviewing technique. I basically ask one question during an interview: what was the hardest problem you ever had to solve? It may sound stupid at first glance, but it gives you insight into not only the breadth of their technical knowledge (since that problem may not be germane to the position you're hiring for), but also the depth of their abilities. The way they answer this question reveals quite a bit about the person. Not only technical, but also their interpersonal abilities.. how they manage their place on a team, how they manage expectations up and below, etc. I can glean quite a bit about the person based on how they answer this one question. Only asking questions about your particular domain doesn't necessarily indicate how good they'll be at solving those types of problems, only how much they happen to know about them. Of course, you can say that perhaps they shouldn't be interviewing for a position they may not be qualified for, but frankly the best people I've ever hired had very little experience in problem sets that were specific to my day-to-day responsibilities, but delving into details about things that they've done told me a great deal about how they solve anything. It may not be the best way to hire, because it requires a breadth of technical knowledge of the interviewer, but it definitely has worked for me. Asking someone to solve a ridiculous puzzle on a whiteboard..when they're obviously nervous about being there in the first place seems kind of dumb to me. However, digging into a problem that they've solved immediately puts them at ease.
I'm not a huge fan of this question. I've been programming for 20 years (professionally for 13). Is the hardest problem some noddy maths i worked out at 15 to convert real coordinates to screen coordinates? Is it the first app i wrote out of college when i learned that servlets aren't thread safe? Is it what i worked on last year to design my current company's authentication/authorization system?
I find it very hard to interpolate between these examples. And none of them are "hard"! I haven't written an OS or a more efficient linked list. All I've done is plugged away at something until it works.
Interesting. I've done a fair number of interviews for my last few companies, and while I've found that whiteboarding isn't terribly useful, likewise I've found that I really do need people to do some coding. I've definitely encountered people that talk a great story but don't have the chops behind a keyboard.
My usual process (which isn't to say it's perfect, but it's a process I regularly edit to address problems I see) is to give a few, simple problems, and have them actually code it on a system.
* I know that the computer and environment are unfamiliar to you, so I expect there to be chopiness and typos
* I know that most people are nervous during interviews, so I don't fail people if they freeze on one of the questions or miss a concept
* I don't give "trivia" questions - the problems tend to be fairly easy ones that cover your ability to approach basic problems. Example: "here is a nested data structure (like an array of objects). Write a method to pull these sorts of elements out."
* I'm actually hoping you'll screw up - I'm far more interested in seeing how you deal with a bug than if you can dash out an algorithm flawlessly. Nonetheless, I keep the questions simple because I want to minimize the impact of nervousness
* I inform people they are absolutely allowed to use Google, StackOverflow, etc - I'm trying to mimic the actual work experience as much as I can. I WILL judge people on their searches, but I'm pretty loose - I can only recall one person that I dinged for searching, and that's because they went to about.com and copied the answer there without trying to understand it (and it subsequently didn't work). Usually this ends up GIVING people points, because if they demonstrate comfort with finding solutions, I expect that we can hire them and know they'll improve over time.
Despite this, I still ask a few questions that are purely verbal. I want to see if you are someone that will force your preferences on others or are willing to bend. (I'm not looking for a doormat, but I've never met one, so that's a bit moot) I want to see that you are continuing to learn things, because the skills you have now will just not be the skills we need in a year or two.
but overall - I have to judge candidates based on the limited info I can glean in an interview. Of:
* resume
* whiteboarding skills
* discussion skills
* coding skills
...I find the latter to be the best measurement of the options, even allowing that it won't be fully accurate.
Hi JonasVP, a little late but regarding your original question...
We were building a tech team at a start-up in Germany.
Our hiring process evolved and stabilized into the following process, which worked exceptionally well for us:
1. Review of written documents, accepting any kind, any style and any medium.
2. Telephone interview with recruiter from HR about motivation, personality and the formal aspects of education and experience.
3. Personal interview with VP of engineering. Future employee is asked to bring some of his or her source code to the interview, any language any style any form is good. We don't copy the code, we don't keep it, we don't use it in any way. This is the only technical interview.
4. Interview with the CTO, immediately following. This is the most important social interview, and it also contains the main salary negotiation.
5. Decision.
Between any of the steps, we would briefly exchange our impression of the candidate, and it turned out that it is wise to sleep a night before taking the decision.
My function was VP of engineering and lead architect, and I would conduct the interviews of step 3. My principles are as follows:
- Keep the candidate at ease as much as possible. We want developers to crack hard problems with "feet on the table" as the Dutch say, most of the time. Stress distorts things, and I want to see the undistorted version.
- Get to know the candidate, and what makes him or her tick. This requires respect, tact and genuine interest in the person and his or her achievements.
- Estimate the fit with team and company. I can talk a lot about this---but in the end it either feels right or it does not.
- Gauge the technical capabilities of the candidate. For this I let the candidate choose a piece of the source code at will and have her explain what it does, and why it is the way it is. For all our hires, some form of dialog on software architecture in general emerged. This usually takes between 10-30 minutes.
- Do your best to get the candidate interested in the company. For this I do not advertise the benefits of the company but simply explain what the company does, what the software we create does, which languages and systems we use and maybe even demo some of it live. Also I explain the risks of working for a start-up company to the less experienced candidates.
I don't do programming exams of any kind. Interactive exams exhibit dangerous positive feedback: you start with something in the middle. If the answer is good you make it more difficult. If the answer is bad you make it easier. Repeating this quickly converges to either extreme, which means you missed the chance to learn something more profound about the candidate, and even risk loosing suitable candidates at split-second blackouts. I don't like take-home exams either, although they are all the buzz these days. A take-home exam is a large investment for the candidate, and most of the people I hired never even touched the programming systems we were using (Erlang, Python, Ocaml, GLPK to name few). All hires did exceptionally well after a few weeks, and with a little bit of guidance. So what could a take-home exam tell me? Even worse, take-home exams are supposed to reduce the risk for the company, at the expense of the candidate. But do they actually do that? At what price? In addition, the large German probationary periods provide an easy way to correct mistakes later, which I had to do only twice so far.
I'm seriously tempted to make one of our technical interview questions "you're creating a technical test for role XYZ, how would you structure it" and see what the candidates come up with!
It really is terrible. Companies need to accept this.
You're sitting behind me. Or beside me. I can smell your breath. Or you're on a webcam. It's voyeuristic. You've already solved this problem. Perhaps you even designed it. Your talking is breaking my concentration. This is not how I work. It's probably not how you work either, and if it is, I think we're done here.
Now, if a company insists on an adversarial process, there are better ways to do it. The nature of the problem is given in advance. Both the subject and the evaluator go in blind, and they both do it.
You know what I call it when a coworker is reading off a document and harassing me for not knowing the thing they're clearly looking up as they go along?
A toxic work environment.
Of course, I believe a significant number of those "interviews" are hazing meant to find excuses not to hire or perpetuate H1B scams.
I was in our spare room coding one day. My girlfriend arrived home and sat on the sofa behind me. I couldn't concentrate just knowing she was behind me and asked her if she could leave.
The problem with whiteboards, is they're not reflective of real life. When was the last time you can honestly say you used a whiteboard to solve a programming problem instead of Googling and ending at a StackOverflow question with a great answer? I've never used a whiteboard for programming. I've used plenty of whiteboards for things one level back; planning, prioritising and visualising task related things.
The reality of programming is, these days everyone Google's their problems. Sometimes you end up at StackOverflow or sometimes you find yourself on a random blog or official documentation. Occasionally you ask a coworker for help, but the ego a lot of developers have to be smart means most feel intimidated to do so. And sometimes you just bang your head against your desk until things start working.
Whiteboard and highly technical interviews that expect you to know high-level computer science concepts are tilted in the favour of graduates who are freshly minted from whatever respective educational institution they graduated from.
> The problem with whiteboards, is they're not reflective of real life. When was the last time you can honestly say you used a whiteboard to solve a programming problem instead of Googling and ending at a StackOverflow question with a great answer?
Yesterday. Although, usually I pull out a notebook instead, and work things out with colleagues (or on my own) on paper at my desk. That happens several times a day.
I scribble in notebooks a lot too, but it's very rarely anything resembling pseudocode or any representation of the actual algorithm I'm working on. It's usually just a todo list, with occasional things heavily underlined so I don't forget them. I often do something similar at the end of the day if I need to remind myself where I left off. For me, it's not at all comparable to whiteboard coding.
Last week. I have to admit that I used a whiteboard for solving a programming problem a few times. But most often, if I have to note down the problem (structure), I'll use a notebook or texteditor.
Then on to the Googling.
The thing is, the timelines are completely different -- in real life, we usually write the problem down, work out obvious details and a plan of attack, then come back to it hours or days later when people have had time to research and think. Never have I had a coworker interrupt me after 15 seconds to "say what I'm thinking about" any time I pause narrating.
In real life, going "hmmm" and taking a couple minutes is acceptable. And you have people being constructive during those times, instead of interrupting you.
Tech interviews are not reflective of real life regardless if there's a whiteboard present or not.
Whenever I've had a whiteboard programming interview, it's always been a trivial problem that's a smoke test for "can this candidate actually write code or is their CV faked". I think it took somewhere between 5 to 15 minutes, which I consider to be rather well spent time compared to spending hours or days on a take home project or anything bigger.
The only time I've been given a take-home assignment I refused to do it because I was extremely busy at that time (finals at uni). The employer gave me an offer anyway. Someone else made a better offer, though (based on a whiteboard session).
The whiteboard is not a good way to assess the level of programming skill of an individual. But it's a good binary indicator of whether they possess any coding skills. If the result is yes and their resume is good, experience is relevant and maybe there's some GitHub or other code they can share, that should be enough to consider a person to be an able programmer.
Like any tool, the whiteboard can be misused. The task should be rather trivial and the time should be short. The purpose should be to weed out the people who have faked their resumes or are applying to programming jobs even though their talent is something entirely different.
> Whenever I've had a whiteboard programming interview, it's always been a trivial problem that's a smoke test for "can this candidate actually write code or is their CV faked". I think it took somewhere between 5 to 15 minutes, which I consider to be rather well spent time compared to spending hours or days on a take home project or anything bigger.
That sounds pretty reasonable, but I don't think it's the norm. I had an interview over two afternoons with 5 or 6 different whiteboard coding challenges, each around half an hour and each much more substantial than a smoke test. They were things like parsing and evaluating a string with a simple arithmetic expression like "2+3*4+5" or taking a phone number and enumerating every possible alphabetic representation (2 is "a" "b" or "c", etc.).
Google has example whiteboard interview questions on YouTube, and one of them was writing a function in C++ that takes an array of integers and a target integer and calculates whether some subset of the array sums to the target integer.
Not the most difficult things ever, but hardly smoke tests, and pretty annoying to whiteboard in my opinion.
I completely agree with you. Once you go past the 15 minute mark, the whiteboard is no longer a good way to do programming aptitude testing. It's a good smoke test, but doesn't really work beyond that.
Of the three examples you mention, I think only the phone number alphabetic representation is a reasonable one to do on a whiteboard.
All the 5 to 10 whiteboard interviews I've had over the years have been smoke tests. This is in Europe, and I got the impression from this thread that it's a common smoke test in Europe and Americans tend to have longer whiteboard interviews.
> But it's a good binary indicator of whether they possess any coding skills
Also: can you discuss technical issues with them? Code quality feedback, finding bugs, explaining their thought processes, acknowledging mistakes, etc.
Imagine they're part of your team, and you come to them with a problem you're stuck on. Do you come away with a positive experience, and closer to a solution?
"Whenever I've had a whiteboard programming interview, it's always been a trivial problem"
I've had a few, and it's never trivial problems. Here's a trivial problem:
- Write a method that takes 2 parameters - an Integer, and a list of Integers - and return a boolean indicating if the int param is in the list of Integers.
Instead of something actually simple like that, it's trick questions designed to appeal to the interviewers desire to appear smart and clever.
> The problem with whiteboards, is they're not reflective of real life. When was the last time you can honestly say you used a whiteboard to solve a programming problem instead of Googling and ending at a StackOverflow question with a great answer?
Programming problems, not so much. Domain problems, almost daily.
Everything depends on the project (e.g. programming games is different than making web apps), but:
> When was the last time you can honestly say you used a whiteboard to solve a programming problem
Every time there is some interesting hard problem which I want to share with the team. We used whiteboards almost daily.
> Googling and ending at a StackOverflow question with a great answer
I google like 5% of stuff I do, because:
* a lot of time is spent on debugging and you just can't google why your program crashes on in file X on line Y
* a lot of stuff is too easy and there is no need for me to google it
* architecture - you usually can't google "how do I architect system X"
Not whiteboard, but I do doodle on paper to find a solution to a problem all the time. It's silly to assume that the problems that I deal with have already been dealt with by somebody else. Who needs programmers anyway if you can simply Google everything? How can you justify the wages of programmers who can't solve new problems on their own?
I get it, some companies go to rather silly lengths asking algorithmic questions when it has nothing to do with the job even remotely. Knowing how to implement an auto balancing search tree probably doesn't have much signal how well you can implement a Rails CRUD application.
A skilled interviewer can come up with a good algorithmic interview, when he/she is genuinely looking for how people deal with hard problems and not knowing the algorithms themselves is fine. A less skilled interviewer will just get some question from the internet and accept only one answer as a correct one, and so on.
But at the same time, some people have a prima donna-like attitude towards interviewing, and it is often counter-productive.
Hiring people is hard. Spending time in poor interviews sucks. But let's not make a circle-jerk out of interviewing :)
It's funny, whiteboard interviews really would be a better discriminator for founders than employees. They test confidence rather than competence (or technically, competence + confidence). The former is incredibly important for founders, but the latter is probably what you care about more for employees. And yet founders almost never do a whiteboard interview, yet it's standard for technical employees...
My view is that you can't have competence at a certain level without confidence - unless you're just an easily outsourced code slinger. I'm often at a whiteboard explaining architecture, ideas, etc. How do you do that without confidence and some semblance of emotional intelligence.
There is really no comparison. Explaining architecture, ideas etc to your colleagues has pretty much no resemblance to a whiteboard interview, where you have several people staring at you and judging you. One is a discussion the other is a test, they compare like having a beer with a colleague is like holding a speech in front of a bunch of stranger.
When I'm the only developer talking to managers, directors, etc. I'm constantly being judged by whether I have good ideas and whether I can be trusted to architect a solution.
May be I am a little overconfident, but I always go into an interview and treat it as a formality to getting the job. By the time I'm in front of the whiteboard, I've already spoken to the recruiter and know what they are looking for, seen the job req to know what technologies they care about, and I've had a phone screen. Why wouldn't I be confident?
Now that I think about it, I wasn't asked a single programming question when I was interviewed for the job I have now. I was asked architectural, process improvement, soft skill questions. That's probably why I chose the job I have over other offers. It was more of a discussion and by the end of the interview, I was joking around with the hiring manager and said something to the effect of "I'm already assuming I'm going to get the job. When am I going to hear back from you?" He started laughing and said soon.
Another interviewer told me at the end of the interview to submit an application and they can get an offer emailed to me by the end of the day. We did a collaborative white board design session and spent a lot of time just talking.
Either all of the job offers I've gotten have been mostly just discussions or I talk tech so much I can't tell the difference between an interview and a typical day at the office.
We've had similar experiences. For the vast majority of jobs across all industries, the last deciding common denominator question that seals the deal is "Can I see myself having a beer with this person?"
Most interviews I've been to have been the same. I was talking about the ones where you have to solve some tricky algorithm questions at a whiteboard while someone is staring at you. I have no problem doing that in front of my colleagues, but find it difficult to do at a job interview.
One thing I've always been curious about is why folks are so afraid of being judged. Most people are judging you all the time, yet recognizing this fact causes a lot of people intense anxiety. I'd rather look at it as a selection filter: if someone doesn't like you or doesn't want to work with you, that's a strong signal that you'd be better off not spending any more energy on them, and instead focusing on the folks who do like you & want to work with you.
Well, for a random employee of a random company there is no motivation to not haze people on the whiteboard, it's mostly a power play for them and oversupply of candidates permits it. They really don't care how good of an engineer they hire and how much value he can bring to the team or to the company.
I don't think that's true, actually. I've been both interviewer and interviewee, almost all my friends do interviews, and in every case I've seen, the interviewer is earnestly trying to make her best determination of whether you can succeed at the company. Most interviewers - both ones I know as friends and ones that have interviewed me - get very, very happy when they find a candidate that they know will meet the hiring bar, because it's such a rare occurrence.
I think that the perception that it's just a hazing process comes from a failure to look at it from the company's perspective. Most people know that they're good programmers (whether it's true or not...), and so they're like "This is bullshit...why do I need to prove my worth at the whiteboard when I know that I'm a good programmer." But the cost of a bad hire is really, really high (both for the company and for the employee), and the applicant pool is skewed through adverse selection, and a company knows nothing about you when you come in to the interview. Many people with stellar resumes can't actually code; some that can code don't actually want to work with you and would be bad cultural fits; and some outright lie on their resume. They're trying to figure out, in a 50-minute hour, whether you'll be productive on the particular problems that that employer faces.
Sometimes it's worth taking action to diminish a perception, even if that perception isn't actually true. Has Google considered the impact of the perception that their interviews are hazing?
Especially in the context of Google's public commitment to increase diversity among their engineers, it strikes me that revamping their interviewing process to eschew whiteboarding ought to at least be considered - it would be amazing PR for Google if they swallowed their pride and innovated in this area. And it would have a real effect outside Google, since so many companies' interview processes mimic Google's.
I'm not certain that an interview process without whiteboarding - or at least some other form of coding test - would actually be able to detect the skills Google needs in their interviews.
I see comments on HN time to the effect of "Why do I need to know how to traverse a tree or sort a trillion 32-bit integers? Why should I care about big-O notation? When will I ever use those skills on the job, when I could just Google for a standard library function?" I used those skills all the time when I worked at Google. When your data set is measure in petabytes, you can't just reach for a stdlib function, you have to actually know how the algorithm works, in depth, so you can implement it across thousands of machines. And any algorithm slower than O(N log N) is not going to work. Even in frontend work, I used tree traversals all the time because JQuery's byte cost was too high to use on Google services.
They have been taking other steps to increase diversity, though, like redacting names & genders on resumes, ensuring that every female candidate has at least one female interviewer, and trying to source candidates from non-traditional (i.e. non-Ivy-league, non-brand-name-tech-company) places.
Has Google innovated much in the interviews themselves in the last, say, 10 years? My perception is No. I get the impression that Google's old-fashioned process is a point of pride that they hang on to because it works (at least, the business is succeeding) and they are afraid of change. But it's a missed opportunity for a technical leader to advance the status quo in our industry.
For example, onsite, Google interviewers will still ask you to write code or pseudocode on the whiteboard. That's something they could re-examine (perhaps by giving an option of whiteboard or computer, and ensuring a level playing field between the options). They could get some good publicity from re-examining this, I think.
Posting a reply for @tsion, who seems to not be able to post at the moment:
I interviewed on-site successfully at Google Seattle about a year ago, and I was given the option between writing code on a whiteboard or in a text editor on a Chromebook, being projected onto the screen in the room, so the interviewers could easily follow without awkwardly looking over my shoulder.
Of course, I picked the text editor. I can't imagine wanting to write code on a whiteboard. However, I did use the whiteboard voluntarily as a thinking and planning aid.
Unfortunately, I also heard that the text editor option was only available at certain offices at that point. I really hope coding in a text editor becomes a universally available option because it's just so much more natural. It essentially put my mind at ease and helped me think more clearly.
On a more general note, my strategy, which seemed to work well for me, was to treat the whole situation like a pair programming task. Even though the interviewer won't directly tell you what to do, they will often comment on things if you question yourself out loud enough.
"I think that the perception that it's just a hazing process comes from a failure to look at it from the company's perspective."
Actually, speaking of looking at it from the companies perspective, in 2010 google and several other big name silicon valley companies were successfully sued because they all agreed with each other not to cold call each others employees to try to recruit them. They actively worked to try to make it harder to switch jobs from one company to another.
Right after that, they started doing whiteboard interviews, which serve the same purpose of making it painful to switch companies, but without the risk of being sued.
It was not really a whiteboard exercise, but I once had an interview at which we went through some of my previous work (code-ish) on a whiteboard. I was mostly for structure, and I think that's a good example. Also there was a good relaxed atmosphere, so it was more a point of discussion. Got an offer.
Main main gripe with whiteboards is that it's hard to add extra lines.
If you're writing a loop for instance, you might code up the per-item logic first, and then you remember you need a loop variable. Which there's now no space for, because in a normal coding environment you can just insert the line where it's needed.
It makes me feel like I need to have solved the whole problem before writing, and that's just not how coding happens.
It looks like many companies in this list use the take-home project approach. The take-home project however is not a replacement to the whiteboard session, as they're not meant to screen at the same level. Once you're given a take home project, you're almost in. It happens when the recruiter really likes the person and wants to dig further with a real life scenario to see how that person would perform.
The whiteboard session is a way to spot people who can't code early in the process.
I personally love whiteboards...but only for discussion of ideas. But interviewers seem to use it only to dock points.
"Oh this guy solved the problem on the whiteboard with good syntax but he uses new and delete. Must be a bad programmer."
I think docking points on whiteboarding just reflects how bad interviewers are at judging skills, possibly because they themselves suck at self-awareness and skills beyond their domain.
I don't see a problem with whiteboard interviews. I've been to a lot of interviews where they will ask me to explain an architecture and I ask them to do they mind if I draw it out while explaining it.
I've spent so much time in my career explaining architecture it's second nature for me to diagram while I'm talking.
During a whiteboard coding session in an interview, I would do some code and some pseudocode.
But at this point in my career if I saw that the interview was focusing more on coding than architecture/development process/automated testing that would be a big red flag.
If it lasts longer than 20 minutes, you're doing it wrong. But more importantly, are we talking about hiring a security expert? Or hiring for a product development team? Or hiring for the devops team? Context is rarely given in the "whiteboarding issue" discussion, e.g. at HN. I currently hold candidate interviews for a solution architect role, and I certainly don't want to hire someone who can't hold a whiteboarding session with a client or their partner's SME.
371 comments
[ 4.3 ms ] story [ 328 ms ] threadIt's nice that you get REPL and a keyboard, but the unnecessary pressure of being watched, critiqued, and timed are all there.
My mind just goes completely blank whenever I am put in this scenario.
Are we programming or defusing a bomb?
But yea that analogy fits coderpad well, along with all the other collaborative code editor + webcam websites.
With a repl I could easily pin myself on some trivial bug that interviewers would ignore on the whiteboard...
Some guys I've met, with different occupations and age, sincerely believe that smaller screens are more usable. Like small windows on 14" CRT when everyone had 17/19". Now it's guys that claim that 11-13" ultrabook is enough for them and they don't want more ever. This honestly baffles me every time.
I can't think of any way to do an interview without pressure. Pressure is unavoidable when someone's future job is on the line.
If you feel you didn't accomplish much at your last job(which would be a pretty common reason for quitting), then a question about it would be pretty stressful, since the company is evaluating you based on work you didn't find to be your best.
Speak for yourself. I'm far more relaxed when diving into a technical question than when playing a guessing game about what social signalling I'm supposed to be doing at that moment.
So, yes, if someone wants to force another person to code on a whiteboard then certainly, they can do better, but it's like asking someone to draw with an axe on the stone floor. Waste of good axe and floor.
1. You get to introspect the environment. I've had lots of candidates forget whether certain objects support simple methods (map, sort, join etc). CoderPad lets you perform quick tests to make sure.
2. You get to debug how you would normally debug. Whiteboard interviews basically rely on the interviewer saying something "Are you suuuuure there's no bugs on, say, lines 10 through 12?". I find this incredibly stressful as both the interviewer and candidate. CoderPad lets you run the damn thing yourself and see if it says what you want it to say.
3. Compared to probably the next most relevant comparison, graded homework assignments, I think CoderPad's free-form format is much more forgiving. As a candidate, I've definitely wasted hours trying to get some hidden automated test suite to pass with no feedback as to what sort of failure was encountered. CoderPad blends code evaluation with live feedback from the interviewer.
Yes, social pressure can be daunting for many candidates. I don't think this is something you can avoid in a live interview in general. I think you can get pretty good signal from project submission from candidates, but at the cost of greatly increased time spent by both candidates and interviewers. For many people this may be a worthwhile trade and I think additional options are good, too.
- Rob, you use Unix! Come quick!
* To disarm the bomb simply enter a valid "tar" command on your first try. No googling. You have ten seconds. *
- Rob?..
- I'm so sorry.
More interesting questions would be like: "which lower-case letters are NOT valid options to GNU ls". :)
My experience lately has been an immediate request to complete a coding project right after speaking to a recruiter but before speaking to anyone technical. And perhaps the height of absurdity I have even had automated emails saying "thank you for you interest we invite you to complete this coding challenge/project."
Are you really expected to do one of these now for every single company you send your CV?
The whiteboards seems far more respectful of people's time at least.
If you are good at selling yourself, whiteboard interviews are awesome.
If you are nervous in interview situations, starting with a project could be an advantage.
Edited to add: coming in for a whiteboard interview will also take few hours of your time (or longer if you need to travel). A sample project can be done whenever you want.
Now, if you were to tell me that nobody ever looked at the test after you sent it in, then it becomes disrespectful. I had several companies do that to me a few months ago.
Not that it matters much. I don't think code tests will stick around. It's too time consuming for the hiring managers.
By requiring these tasks you're implicitly screening not only people who can't code but also people who don't have three hours to spend on applying to your company. If all you want is 20-somethings with no other responsibilities then continue as you are, but if you'd like to see a bit of diversity then you're going to have to compromise.
You could simply get rid of the take home test; that will shift the burden to the resume and cover letter, to the advantage of humanities graduates like me.
You could mandate a full day on-site, which will bias against people from out of town who want to relocate and people in delicate situations at their current employer.
For the time poor candidate, there is always the whiteboard exercise... Whose biases we are gathered here to moan about in the first place.
I always feel in these threads that people think hiring is 'broken' and it can be 'fixed' with the proper application of 'one weird trick'. But then all the comments actually have contradictory complaints. So obviously it can't.
What I am asking is that companies don't ask me to invest hours of time before they decide if they're even interested in talking to me. At the very least I want to have had a phone interview and the chance to assess whether I'm even interested in working for you. That's particularly relevant when looking for remote friendly employers, I've had several calls in recent days from recruiters responding to me saying I'm looking for remote work which I stopped on finding out what they meant was "at least three months fulltime on site, and then maybe we'll talk about some remote work".
Home test is totally fine after a phone call or a two. However, they are not fine at all just after submitting an application and no real contact.
I feel like this is the crux of it as well. I am not against projects or tests to show I am technically qualified. But this should be after talking to some potential team mates to see if there is even a fit, personally, work culture-wise, technical interest or any number of factors that you could glean by speaking to potential colleagues for 20 or 30 minutes.
I used to invite people for an interview without any prior testing, but it was generally such a big waste of time for both me and applicant. What's more, quite often I can see from CV that someone is underqualified, but I do not want to reject them immediately without giving them a chance, so I send them a homework. Finally, you would be surprise how often even people with good CVs turn out to be quite bad.
I don't mind long coding exercises, it's what I do all day anyway. Better than watching yet another episode of NCIS or what have you :)
[1] https://github.com/mdpopescu/public/tree/master/SocialNetwor...
So by your reasoning CVs are not meaningful at all. Should we get rid of them? Why stop there though, should we not even discuss past projects we have worked on in interviews since those are also likely exaggerations and possibly outright lies?
Except in practice it seems that its not a "little code" its a 4 hour project that is usually closer to a 6 or 8 hour project in reality.
- How is this any different than spending an unreasonable amount of time studying balancing binary trees and similar trivial whiteboarding problems?
I'm of the opinion that studying all these variations of the algorithm problems is a bigger time-sink and waste of time than getting into the habit of problem solving a take-home project.
And also take a few hours of time, and possibly more.
Some companies will happily bring you on site for a full round even though they have no idea whether there is an open position for you (infamous example, you can pass Google's hiring committee and then be told there's no headcount). And you've just wasted one day off.
On the other hand, take-home projects can be used in a way that saves everyone a lot of time. I don't disagree with you, they shouldn't be used for screening though.
In practice though this is kind of rare especially for the larger SV companies. I'm not saying it's never happened but that Google incident sounds like an anomaly.
How do take home projects save time if they take between 4 - 8 hours? That's the same time as an onsite takes. The difference being that before a company brings you onsite there has probably been at least a technical phone screen or two so the candidate has ben "qualified" to some extent no?
I can do a 4 hour[1] assignment on my own time, assuming I'm not given an unreasonable deadline. For a full round of interviews on site, I need to take a day off. That's a huge difference to me.
[1] I've rarely been given any assignment taking more than 2-3 hours, I would flat out refuse anything that can take more than 4.
Edit: oh and I can give you a very long list of companies that thought I was "qualified" after 1/2/3 phone screens, wasted a lot of my time afterwards, and ended up deciding I wasn't :)
https://medium.com/@meowlicious99/my-software-engineer-inter...
That completely defeats the purpose of a small, self-contained assignment like the one you were given. And your code isn't even in Java 7 (no diamonds), I think it was a legitimate remark.
I would have dazzled them with java 8 if I knew I was going to be rejected a based on that :D
I was under the impression that this was the usual algorithm/data structure/complexity rigamarole, not show us latest language features.
These are just off the top of my head, however theres no shortage.
I don't think all interviews should use it but for us it was good for filtering out candidates who would not perform in those situations.
Whiteboard coding is also a different kind of pressure. I can't imagine a situation where someone who already knows the answer is watching over your shoulder critiquing you while you work on a problem.
right? unless you are in downtime mode, there's really something wrong with your schedule/deliverables/tasks.
writing code is not a race, it's more of a marathon where you have to be at a healthy pace to get to the end, otherwise you will not be able to finish.
I think it's unlike any real situation, and you're fooling yourself that one kind of stressor is like another.
This sounds like an incredibly toxic working environment, where developers are either being allowed to create fires on production systems, or management is completely incompetent or both.
Also, being able to "handle it" has nothing to do with anything in this discussion. I'd much prefer to hire someone capable enough to not need to "handle it" than someone proud of the fact that they often s*it the bed but are willing to jump up and do the laundry under pressure.
I personally enjoyed it but it's not for everyone.
I think it comes down to expectations - in an interview I have to focus on impressing my audience and that's always there. In real life, I can focus fully on the actual problem being solved.
I also did a second code test, which I got to do alone on an offline laptop. The test had a time limit and it was designed in a way that you should NOT be able to finish it on time. This was communicated to me several times before I actually sat down in front of the laptop. The goal with this test is to see if a person can solve problems under stress, and if the person writes decent code that works, or just hacks something together and moves on to the next step - leaving a trail of bugs.
Overall, I think this has worked out great for us, but it might not be a good process for everyone.
1) Meeting where you are presented a problem and asked to immediately give your thoughts on how you would approach it.
2) Some days, for example weekend, to work on the problem. Candidate gets a monetary compensation for this time.
3) Next meeting where you present the solution.
Yes, there's always a risk that somebody will get somebody else to write the code, but having to explain before and after reduces the risk. Paying for the work shows you are serious about the recruitment.
In that case candidates should also pay companies to show they are serious about the position
If I have a problem to solve "under stress", usually it's just a one off to fix something in production until I have time to write it, refactor it, put a unit test around it, and a code review.
https://blogs.janestreet.com/what-a-jane-street-dev-intervie...
That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of.
We worked with an HR consultant to develop a interview guide in the form of certain questions that we make sure to hit during the interview in order to be able to compare between candidates and make an informed decision.
However, we're small and not in the US. Anyone have experience with other companies in Germany/Europe? How does the typical interview work over here?
When I've been job hunting in the past I've also found that these have been the best situations for me. I find coding questions beyond fizbuzz totally silly and when something more is requested of me my attitude shows this.
This. I advocate this method of interviewing here in the states every chance I get. The most common form of push back I get is from hiring managers terrified of being hoodwinked into making a bad hire. It's like they don't trust their own judgement enough to be able to tell apart those who know what they're talking about from those who just talk a good game.
> I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of
Junior engineers, I assume? I had problems with those questions when I first started out. It's hard to say with a straight face that the thing I was most proud of at that point in my career was creating a very simple templating system in PHP. Of course, the interviewers rolling their eyes and saying 'is that all?' didn't help.
Which is usually the case in larger companies, I assume. The person doing the hiring in that case is far removed from the people and work actually connected with the candidate.
> Junior engineers, I assume?
You're right, that's surely part of it. Not only, however - sometimes you get the feeling that work is something that happens to people, not something they seek out and try to get better at. Which for many positions is completely fine.
That says a lot about their maturity, not yours.
I'm not sure why there is such extreme hate for the whiteboard. Yes it has plenty of caveats when it comes to actual coding and recruiters should not expect any candidate to write precise code on that medium.
I do use the whiteboard for trivial CS questions limited to 5-10 minutes. Think fizzbuzz and string reversal. Candidates have the option to use my laptop (not ideal because the keyboard has a US layout) but they are welcome to use their own computer as well (if they thought about bringing it). It weeds out candidates who can't even produce basic code. And yes, a candidate with 2+ years of experience should be able to write a basic function on a whiteboard, a napkin, or whatever. If not, the interview is not lost but the candidate will have to prove his skills another way.
For most candidates, we also give a longer technical test which is to be done at home and takes 2 to 4 hours to complete. Candidates are given as many days as they want to complete it.
Whiteboard is an excellent medium however when discussing architecture and higher level ideas. It's also a tool that I've used during day to day activities with colleagues. Software based tools don't come even close.
I recently went to an interview that asked me to balance a binary tree on a whiteboard. It can be done, and I can do it. Thing is when you go to interview for that company that has 2 developers(small team, small company) and ask you that kind of question it puts you off thinking that those guys won't be great to work with (arrogance etc comes in mind).
I am fond of simpler questions, like you said fizzbuz etc. Obviously if you are interviewing a guy that has 2+ years of experience, he has to be able to pass the fizzbuzz test. When you are interviewing someone with 5+ years of experience for a higher up position I guess you do have to ask some harder question, but I personally think just speaking to the guy and asking him stuff about his past projects etc will give you a hint on if he has the skills he is talking about or not. Asking him to outline a hard task he took part and how he solved it is an amazing start. As a 5+ years guy personally would rumble about a few things and it would take me days talking about them. (That will give you an understanding if I've worked before or not on the things outlined on my CV).
If you're coming from a more FP background things like flipping a binary tree are silly obvious. If you spend a lot of time with C++, of course you know how to write a linked list with memory management. Python devs are probably way better at slicing and dicing data
There's a certain expectation of what's easy and hard, but it's really easy to have a mismatch given the diversity of education out there.
Last time I've had to do something with the trees implementation details (IIRC, that was AVL trees) was, like, 5 years ago. Right now, I don't exactly remember anything about AVL trees except for they have that nice O(log n) for lookups, insertions and deletions. Would I need to code them from scratch (or remember their internal workings for any other reason, like debugging some core dump), I'd go find the algorithm description (or particular implementation's source) and do so.
At the same time, last time I've worked with balanced trees was just a few days ago, but that was Erlang's `gb_trees` module that did all the stuff and I just had to freshen my memory on the syntax details.
All I would be able to do on a whiteboard is stare for a minute, trying to remember stuff, then probably say "uh, sorry, I don't remember this stuff - haven't did that in a long while". Yes, that makes me a worse programmer, I guess, but are interviewers actually looking for those who remember everything in their head and write code on whiteboard? Looks like a weird case to me that doesn't have to do anything with reality.
Given enough time and debugging I'm sure I could do it. I'm not going to be successful on a whiteboard though. If I actually had to do it I'd look it up instead of wasting my time figuring it out.
Unless you're interviewing for a position where they'll have to implement binary trees you shouldn't be wasting time asking about code for them. Questions should be relevant to the position.
You want candidates who can work through the buy-vs-build tradeoffs.
Reminds me of when I was asked to implement a filesystem API in C or C++ with file manipulation and path parsing and whatnot. The best answer I can think of is usually "With no weird constraints given (is this an embedded system, for example?) just use boost::filesystem and move on with your life." Not impressed with this answer, the interviewer would continue with "assume you can't use Boost!" Next answer is: "There are a variety of filesystem abstractions already written, far better than I could whiteboard. I'd go through each one and pick the one most suitable to the project." I thought it was a trick question at first. You really DO NOT want candidates who hear that question and launch into writing code!!
Similarly, I've never had to implement fizz buzz for real, actual, work. But I wouldn't trust a programmer who was incapable of doing fizz buzz without importing a fizz buzz library.
Fizz buzz tests for "does this person know what a function is, what an if statement is, and the modulo operator". And frankly, I'd give the modulo answer away for free if the candidate asked.
All programmers should know what a function and an if statement is.
Why do people keep saying string reversal is easy? Text is one of the hardest things out there. Unless you expect your programmers to support ASCII only?
Why not reverse a list or an array? That does sound like something that is doable in 5-10 minutes.
Other fun special cases: 🇺🇸 is U+1F1FA REGIONAL INDICATOR SYMBOL LETTER U, followed by U+1F1F8 REGIONAL INDICATOR SYMBOL LETTER S and should if possible be displayed as a US flag (otherwise falls back to text "US"), should reversing it create 🇸🇺 (replacing the flag with the characters "SU"), or still show the flag? (I'm not even sure if there isn't a case where both are valid country codes and it would change to a different flag?)
Similarly, Emoji can be formed from a sequence with combining characters inbetween, which don't display correctly if reversed codepoint by codepoint.
The worst-case scenario is a "self-hazing" where someone sees the encoding difficulties and freezes up instead of asking for clarification. I've never seen that happen though, in my experience though, everyone -- even the good ones -- just assume ASCII.
And I am happy enough if they do it correctly.
But if you are in python, and given a string object, and told to reverse it without using the reverse method.... Yeah, that's easy. You should be able to do that.
People are usually expecting the latter.
We also do a coding challenge after that, basically the candidate behind a computer, with all the resources they want accessible to them, implementing a simple example directly relevant to the type of work they'll be doing, while the interviewers are in the room and debate with them if needed.
To me, the most important quality in a candidate, once we determine that the basic skill level is good enough, is their ability to learn, quickly find the resources needed, and rely on the team when they need help. Whiteboard interviews don't seem to select for any of those qualities.
I have trouble recalling the details of things I worked on even say a week ago sometimes. I also don't find most of the work I do that interesting as I've been coding along time solving the same kinds of problems. However to play the game i would of course brush up for questions like that, and be quite convincing.
No problem here, it probably wasn't very exciting but have you never encountered something which stuck in your mind? Or that you could at least recall some part of a project if someone asked "So, you've written here that you've worked on project xy and did this and that, can you tell us a bit more about it"?
In general I think the question format favours people with a good memory for anecdotes and story telling ability.
It could be that this technique favors people good at telling stories.
Personally, I'm a horrible storyteller. If you were to ask me what I did over the weekend, I'll offer some facts like "oh, went swimming in a river and Bob lost his hat, but we found it later. The water was nice." Whereas Bob could easily regale you with stories about the epic hunt for his hat and throw in a punchline in the end.
If I didn't know that you'd be asking for solutions I'm proud of, I might draw a blank at that moment. Granted it's an interview setting and these are the questions one needs to prepare for. But if given the choice between speaking about myself or whiteboarding, I'll take the whiteboard.
I've always preferred math over history for that matter. It's easier for some of us to apply processes than to recite chronologies.
It's an alright proxy for other things, but there's a ton of good developers that leave their ego at the door, and their work at work.
I was working with a brilliant guy in the same company. He was very technical and you could say that easily he was programming all day long non stop. His intelligence and technical expertise amazed me. Thing is he wasn't good with people skills, hence he wouldn't fit the company I am currently working for.
There are companies that hire devs to solve a problem and give them time, space etc to go all hardcore. Then again there are companies that require from their dev's to be able to communicate with the rest of the team, and take part on meaningful theory-crafting meetings.
So neither whiteboarding, nor tell me a story question is wrong.
I just find it that whiteboarding difficult questions should be asked from the very technical jobs, and I've found whiteboarding difficult questions when interviewing for a company that wants to move out of wordpress to their own website in angular.
It does, but then again, maybe that's what they're going for (even if subconsciously).
A story is entertainment not work communication.
> It could be that this technique favors people good at telling stories.
Or people who think they're impressive. I know I would've been able to point out many problems and solutions I found interesting and were impressed with when I was 15. Today, not so much. The more I know, the less impressed I am with myself, and more and more stuff just feels "routine" and nothing special.
It could be that I'm just not impressive. At all.
Oddly enough, the opposite is true as well. I'm constantly impressed at the level of ability they have at this point in their career as compared to my ability at the same point in my career. They just simply know more. Of course, there's more to know these days but still, I find it impressive.
Keep a daily journal of what you work on. Nothing fancy, just stop by once a day religiously and add a few notes on what you did, what meetings you attended, who you spoke with, etc...
Save your evaluations and especially any award packages you or your team might get submitted for. At least where I work both are your supervisor's attempt to make you look as good as possible.
Then, when you're job hunting review your notes and bullets and collect the ones that sound the best and perhaps ones that have numbers assigned to them (size, savings, productivity, etc..)
Preferably you'd memorize these few stories about yourself, but if you must you could also bring a notebook with prompts to remind you.
My notetaking is not as rigorous as my Grandfathers, but I do something similar. Every month I make a new manilla folder with the month and year on the tab. Each week I write down every project I'm working on and every meeting I have. If someone brings me a new project I put it on the sheet. Every note I take a meetings and during projects goes in that folder.
At the end of each week I go through the notes from that week and write down anything interesting on that week's note sheet. At the end of the month I go through all the notes and write what I accomplished on the front of each manila folder.
It makes it really easy to keep track of everything you've done, without consciously keeping a journal in the moment. It's also a really easy organizational system. When someone asks, "What did we do for [x] in the past", all I need to do is flip through my folders looking at the front for anything that rings a bell, rather than trying to keep up with a tagged organizational system.
This probably doesn't work if you don't have a file cabinet though.
The key word there is "prepare". These are standard interview questions that you just have to have a prepared, rehearsed answer for that you can rattle off without thinking. There are tons of these types of "behavioral" questions. Tell me about a project that you worked on that failed. Tell me about a time you had to deal with team conflict. Talk about a struggling project that you had to help turn around. You can get a book full of them. Be ready with canned answers for as many as you can and practice them in front of a mirror.
Practicing algorithms for a whiteboard interview sounds a lot more fun.
Too bad (for candidates) that that concern doesn't appear to be shared by... well almost everyone in tech hiring these days. The general wisdom of the day seems to be "it's better to eliminate 100 false negatives than hire one false positive."
I worked with some really great folks that had trouble getting hired and it was because of the flawed interview process. One person writes concise and clear Rails code that's easy to read, and makes some of the wittiest comments on Slack (subtle puns that go unrealised for two minutes, then you finally get it and makes you smile). But he stutters a bit. And because of that, interviews are difficult for him. Which is a real pity, because in less judgmental situations, no one would think twice about that.
(Don't worry there's a happy ending and he's now at a good company.)
I learned after my first university job fair the necessity of being more outgoing during these situations, but there's great engineers out there who still live by the myth of "they'll know me by my work".
Pride is a very strong word, especially for those of us with impostor syndrome...
A lot of developers also have imposter syndrome. After I've solved an interesting problem, within a few days i'll probably have dismissed it as not being a big deal and started to forget about it.
These kind of questions are useful, but candidates should be preparing their talking points, because the risk of forgetting the story that's going to get you hired is too high
(When I think about the problem "objectively", all I did was use SSDT to simplify deploying database changes from QA to production without having to shut down either. No big deal. However, it was something that the company had been doing manually for years, spending three error-prone days each month, and they were extremely happy with my solution.)
I find it very hard to interpolate between these examples. And none of them are "hard"! I haven't written an OS or a more efficient linked list. All I've done is plugged away at something until it works.
My usual process (which isn't to say it's perfect, but it's a process I regularly edit to address problems I see) is to give a few, simple problems, and have them actually code it on a system.
* I know that the computer and environment are unfamiliar to you, so I expect there to be chopiness and typos * I know that most people are nervous during interviews, so I don't fail people if they freeze on one of the questions or miss a concept * I don't give "trivia" questions - the problems tend to be fairly easy ones that cover your ability to approach basic problems. Example: "here is a nested data structure (like an array of objects). Write a method to pull these sorts of elements out." * I'm actually hoping you'll screw up - I'm far more interested in seeing how you deal with a bug than if you can dash out an algorithm flawlessly. Nonetheless, I keep the questions simple because I want to minimize the impact of nervousness * I inform people they are absolutely allowed to use Google, StackOverflow, etc - I'm trying to mimic the actual work experience as much as I can. I WILL judge people on their searches, but I'm pretty loose - I can only recall one person that I dinged for searching, and that's because they went to about.com and copied the answer there without trying to understand it (and it subsequently didn't work). Usually this ends up GIVING people points, because if they demonstrate comfort with finding solutions, I expect that we can hire them and know they'll improve over time.
Despite this, I still ask a few questions that are purely verbal. I want to see if you are someone that will force your preferences on others or are willing to bend. (I'm not looking for a doormat, but I've never met one, so that's a bit moot) I want to see that you are continuing to learn things, because the skills you have now will just not be the skills we need in a year or two.
but overall - I have to judge candidates based on the limited info I can glean in an interview. Of: * resume * whiteboarding skills * discussion skills * coding skills
...I find the latter to be the best measurement of the options, even allowing that it won't be fully accurate.
We were building a tech team at a start-up in Germany.
Our hiring process evolved and stabilized into the following process, which worked exceptionally well for us: 1. Review of written documents, accepting any kind, any style and any medium. 2. Telephone interview with recruiter from HR about motivation, personality and the formal aspects of education and experience. 3. Personal interview with VP of engineering. Future employee is asked to bring some of his or her source code to the interview, any language any style any form is good. We don't copy the code, we don't keep it, we don't use it in any way. This is the only technical interview. 4. Interview with the CTO, immediately following. This is the most important social interview, and it also contains the main salary negotiation. 5. Decision.
Between any of the steps, we would briefly exchange our impression of the candidate, and it turned out that it is wise to sleep a night before taking the decision.
My function was VP of engineering and lead architect, and I would conduct the interviews of step 3. My principles are as follows: - Keep the candidate at ease as much as possible. We want developers to crack hard problems with "feet on the table" as the Dutch say, most of the time. Stress distorts things, and I want to see the undistorted version. - Get to know the candidate, and what makes him or her tick. This requires respect, tact and genuine interest in the person and his or her achievements. - Estimate the fit with team and company. I can talk a lot about this---but in the end it either feels right or it does not. - Gauge the technical capabilities of the candidate. For this I let the candidate choose a piece of the source code at will and have her explain what it does, and why it is the way it is. For all our hires, some form of dialog on software architecture in general emerged. This usually takes between 10-30 minutes. - Do your best to get the candidate interested in the company. For this I do not advertise the benefits of the company but simply explain what the company does, what the software we create does, which languages and systems we use and maybe even demo some of it live. Also I explain the risks of working for a start-up company to the less experienced candidates.
I don't do programming exams of any kind. Interactive exams exhibit dangerous positive feedback: you start with something in the middle. If the answer is good you make it more difficult. If the answer is bad you make it easier. Repeating this quickly converges to either extreme, which means you missed the chance to learn something more profound about the candidate, and even risk loosing suitable candidates at split-second blackouts. I don't like take-home exams either, although they are all the buzz these days. A take-home exam is a large investment for the candidate, and most of the people I hired never even touched the programming systems we were using (Erlang, Python, Ocaml, GLPK to name few). All hires did exceptionally well after a few weeks, and with a little bit of guidance. So what could a take-home exam tell me? Even worse, take-home exams are supposed to reduce the risk for the company, at the expense of the candidate. But do they actually do that? At what price? In addition, the large German probationary periods provide an easy way to correct mistakes later, which I had to do only twice so far.
Would be interesting tbh.
Now, if a company insists on an adversarial process, there are better ways to do it. The nature of the problem is given in advance. Both the subject and the evaluator go in blind, and they both do it.
A toxic work environment.
Of course, I believe a significant number of those "interviews" are hazing meant to find excuses not to hire or perpetuate H1B scams.
The reality of programming is, these days everyone Google's their problems. Sometimes you end up at StackOverflow or sometimes you find yourself on a random blog or official documentation. Occasionally you ask a coworker for help, but the ego a lot of developers have to be smart means most feel intimidated to do so. And sometimes you just bang your head against your desk until things start working.
Whiteboard and highly technical interviews that expect you to know high-level computer science concepts are tilted in the favour of graduates who are freshly minted from whatever respective educational institution they graduated from.
Yesterday. Although, usually I pull out a notebook instead, and work things out with colleagues (or on my own) on paper at my desk. That happens several times a day.
The thing is, the timelines are completely different -- in real life, we usually write the problem down, work out obvious details and a plan of attack, then come back to it hours or days later when people have had time to research and think. Never have I had a coworker interrupt me after 15 seconds to "say what I'm thinking about" any time I pause narrating.
In real life, going "hmmm" and taking a couple minutes is acceptable. And you have people being constructive during those times, instead of interrupting you.
Whenever I've had a whiteboard programming interview, it's always been a trivial problem that's a smoke test for "can this candidate actually write code or is their CV faked". I think it took somewhere between 5 to 15 minutes, which I consider to be rather well spent time compared to spending hours or days on a take home project or anything bigger.
The only time I've been given a take-home assignment I refused to do it because I was extremely busy at that time (finals at uni). The employer gave me an offer anyway. Someone else made a better offer, though (based on a whiteboard session).
The whiteboard is not a good way to assess the level of programming skill of an individual. But it's a good binary indicator of whether they possess any coding skills. If the result is yes and their resume is good, experience is relevant and maybe there's some GitHub or other code they can share, that should be enough to consider a person to be an able programmer.
Like any tool, the whiteboard can be misused. The task should be rather trivial and the time should be short. The purpose should be to weed out the people who have faked their resumes or are applying to programming jobs even though their talent is something entirely different.
That sounds pretty reasonable, but I don't think it's the norm. I had an interview over two afternoons with 5 or 6 different whiteboard coding challenges, each around half an hour and each much more substantial than a smoke test. They were things like parsing and evaluating a string with a simple arithmetic expression like "2+3*4+5" or taking a phone number and enumerating every possible alphabetic representation (2 is "a" "b" or "c", etc.).
Google has example whiteboard interview questions on YouTube, and one of them was writing a function in C++ that takes an array of integers and a target integer and calculates whether some subset of the array sums to the target integer.
Not the most difficult things ever, but hardly smoke tests, and pretty annoying to whiteboard in my opinion.
Of the three examples you mention, I think only the phone number alphabetic representation is a reasonable one to do on a whiteboard.
All the 5 to 10 whiteboard interviews I've had over the years have been smoke tests. This is in Europe, and I got the impression from this thread that it's a common smoke test in Europe and Americans tend to have longer whiteboard interviews.
Also: can you discuss technical issues with them? Code quality feedback, finding bugs, explaining their thought processes, acknowledging mistakes, etc.
Imagine they're part of your team, and you come to them with a problem you're stuck on. Do you come away with a positive experience, and closer to a solution?
I've had a few, and it's never trivial problems. Here's a trivial problem: - Write a method that takes 2 parameters - an Integer, and a list of Integers - and return a boolean indicating if the int param is in the list of Integers.
Instead of something actually simple like that, it's trick questions designed to appeal to the interviewers desire to appear smart and clever.
Programming problems, not so much. Domain problems, almost daily.
> When was the last time you can honestly say you used a whiteboard to solve a programming problem
Every time there is some interesting hard problem which I want to share with the team. We used whiteboards almost daily.
> Googling and ending at a StackOverflow question with a great answer
I google like 5% of stuff I do, because:
* a lot of time is spent on debugging and you just can't google why your program crashes on in file X on line Y * a lot of stuff is too easy and there is no need for me to google it * architecture - you usually can't google "how do I architect system X"
A skilled interviewer can come up with a good algorithmic interview, when he/she is genuinely looking for how people deal with hard problems and not knowing the algorithms themselves is fine. A less skilled interviewer will just get some question from the internet and accept only one answer as a correct one, and so on.
But at the same time, some people have a prima donna-like attitude towards interviewing, and it is often counter-productive.
Hiring people is hard. Spending time in poor interviews sucks. But let's not make a circle-jerk out of interviewing :)
May be I am a little overconfident, but I always go into an interview and treat it as a formality to getting the job. By the time I'm in front of the whiteboard, I've already spoken to the recruiter and know what they are looking for, seen the job req to know what technologies they care about, and I've had a phone screen. Why wouldn't I be confident?
Another interviewer told me at the end of the interview to submit an application and they can get an offer emailed to me by the end of the day. We did a collaborative white board design session and spent a lot of time just talking.
Either all of the job offers I've gotten have been mostly just discussions or I talk tech so much I can't tell the difference between an interview and a typical day at the office.
I think that the perception that it's just a hazing process comes from a failure to look at it from the company's perspective. Most people know that they're good programmers (whether it's true or not...), and so they're like "This is bullshit...why do I need to prove my worth at the whiteboard when I know that I'm a good programmer." But the cost of a bad hire is really, really high (both for the company and for the employee), and the applicant pool is skewed through adverse selection, and a company knows nothing about you when you come in to the interview. Many people with stellar resumes can't actually code; some that can code don't actually want to work with you and would be bad cultural fits; and some outright lie on their resume. They're trying to figure out, in a 50-minute hour, whether you'll be productive on the particular problems that that employer faces.
Especially in the context of Google's public commitment to increase diversity among their engineers, it strikes me that revamping their interviewing process to eschew whiteboarding ought to at least be considered - it would be amazing PR for Google if they swallowed their pride and innovated in this area. And it would have a real effect outside Google, since so many companies' interview processes mimic Google's.
I see comments on HN time to the effect of "Why do I need to know how to traverse a tree or sort a trillion 32-bit integers? Why should I care about big-O notation? When will I ever use those skills on the job, when I could just Google for a standard library function?" I used those skills all the time when I worked at Google. When your data set is measure in petabytes, you can't just reach for a stdlib function, you have to actually know how the algorithm works, in depth, so you can implement it across thousands of machines. And any algorithm slower than O(N log N) is not going to work. Even in frontend work, I used tree traversals all the time because JQuery's byte cost was too high to use on Google services.
They have been taking other steps to increase diversity, though, like redacting names & genders on resumes, ensuring that every female candidate has at least one female interviewer, and trying to source candidates from non-traditional (i.e. non-Ivy-league, non-brand-name-tech-company) places.
Has Google innovated much in the interviews themselves in the last, say, 10 years? My perception is No. I get the impression that Google's old-fashioned process is a point of pride that they hang on to because it works (at least, the business is succeeding) and they are afraid of change. But it's a missed opportunity for a technical leader to advance the status quo in our industry.
For example, onsite, Google interviewers will still ask you to write code or pseudocode on the whiteboard. That's something they could re-examine (perhaps by giving an option of whiteboard or computer, and ensuring a level playing field between the options). They could get some good publicity from re-examining this, I think.
I interviewed on-site successfully at Google Seattle about a year ago, and I was given the option between writing code on a whiteboard or in a text editor on a Chromebook, being projected onto the screen in the room, so the interviewers could easily follow without awkwardly looking over my shoulder.
Of course, I picked the text editor. I can't imagine wanting to write code on a whiteboard. However, I did use the whiteboard voluntarily as a thinking and planning aid.
Unfortunately, I also heard that the text editor option was only available at certain offices at that point. I really hope coding in a text editor becomes a universally available option because it's just so much more natural. It essentially put my mind at ease and helped me think more clearly.
On a more general note, my strategy, which seemed to work well for me, was to treat the whole situation like a pair programming task. Even though the interviewer won't directly tell you what to do, they will often comment on things if you question yourself out loud enough.
Actually, speaking of looking at it from the companies perspective, in 2010 google and several other big name silicon valley companies were successfully sued because they all agreed with each other not to cold call each others employees to try to recruit them. They actively worked to try to make it harder to switch jobs from one company to another.
Right after that, they started doing whiteboard interviews, which serve the same purpose of making it painful to switch companies, but without the risk of being sued.
If you're writing a loop for instance, you might code up the per-item logic first, and then you remember you need a loop variable. Which there's now no space for, because in a normal coding environment you can just insert the line where it's needed.
It makes me feel like I need to have solved the whole problem before writing, and that's just not how coding happens.
Got a great offer from both and accepted one of them.
I strongly prefer a coding project to a whiteboard. It is still a bit artificial, but it is way closer to my actual work.
The whiteboard session is a way to spot people who can't code early in the process.
"Oh this guy solved the problem on the whiteboard with good syntax but he uses new and delete. Must be a bad programmer."
I think docking points on whiteboarding just reflects how bad interviewers are at judging skills, possibly because they themselves suck at self-awareness and skills beyond their domain.
I've spent so much time in my career explaining architecture it's second nature for me to diagram while I'm talking.
During a whiteboard coding session in an interview, I would do some code and some pseudocode.
But at this point in my career if I saw that the interview was focusing more on coding than architecture/development process/automated testing that would be a big red flag.