When a professional comes in, he expects to be treated like one. Most people learned to solve basic coding problems when they were at the university like 15 or 20 years ago. Today, 20 years later you should be discussing other things. Otherwise, you're basically starting a dialogue implying the guy slacked off for 20 years inviting him to prove otherwise. It's just no way for two grown-up professionals to approach things.
On a side note, try this: make a appointment with a highly reputable dentist (like weeks or months in advance) then go and try asking him some basic questions implying he might not know his stuff. You'll be shown the door in about two minutes, and possibly you'll get a lifetime ban in that establishment.
Why should software developers accept to be treated differently? And yes, there are lots of incompetent dentists and doctors of all kinds. Why do they have more respect for themselves than software specialists?
You may be asking about things because you genuinely need to learn/understand something, in which case doctors are often eager to explain their stuff.
Or you may be asking questions trying to figure out if they know their craft, have run into difficult cases or complications to assess their level of expertise. That's a different story.
I once made a mistake of doing the latter, though I did it because I was facing an op and was quite disconcerted perhaps even frightened. At some moment the doctor looked at me with a special look and told me to go consider what I learned today and decide if I was ready for the whole thing. Then I knew I asked too much and all the wrong questions. Given that he was a very experienced specialist, was the chief doctor of that establishment and overall well recommended, the mistake was mine.
But in the end it all worked out rather nicely with no grudge-holding.
I think that is ridiculous. Last time I had a mild dental surgery I asked my dentist how many such operations she had performed and how many she had botched up. She not only very patiently and willingly answered by questions but also told me that she had a failure rate of 12% which was industry standard.
If dentists, car mechanics and your local gun dealer refuses to answer question there is the good chance they really dont know their own shit.
But yes, if I were considering dental surgery, I'd certainly want to know that number...
How do I know if the person I'm talking to is one of your "professionals," without asking these questions? I need to weed out the pretend professionals.
If you need a whiteboard or tests, to tell they are a professional then you may be doing something wrong. I can talk to a person and within 10 minutes tell you if they are a good developer or not. Perhaps it's a gift, but I suspect not, what I suspect is people focus on the wrong parts of what makes a developer a good developer.
People focus on the mechanics of development. Do they know syntax? Do they know the API?
In my time I have forgotten more syntax and API's than I know, I used to be a top notch Pascal developer and could be again in 2 weeks same with Delphi, but today I would be hard pressed to write a line of it. But people get hung up on this, they think a whiteboard, disconnected from information, somehow simulates reality; meanwhile we all use Google, before that it was the development library at your company, Barns and Noble and a host of other printed material. The reality is memorizing little used portions of a languages API is a waste of time (the platform is going to change). For 80% of applications built you are going to use the same simple patterns in whatever platform is being used.
The key is to focus on what you are realistically going to have them do. If you are hiring a CRUD developer they should have a good handle on Data access, Relational or NoSQL theory and web/mobile technologies. Don't ask them to write an algorithm that factors prime on the whiteboard when no one is ever going to write that and even if they are, they are certainly not going to do it in a disconnected environment.
I look for three things, intuition, an inquisitive nature and motivation. Those are the three things that cannot be taught. It has yet to fail me other than the above mentioned anomaly.
People can't talk the talk about specifics of industry experience if they haven't walked the walk, and that will become obvious in normal discourse around the matters of job role itself and their related experiences. You can be inquisitive, but starting off with CS101 quizzes is just condescending and wildly irrelevant to the actual position.
When I'm being interviewed, I respect the interviewer for demanding hard data, instead of just checking who talks the talk.
People have personal projects, accounts in social networks, personal blogs. Make a short list of candidates than go digging. You can soon get a good idea of their abilities and how far they are progressed on their professional evolution path.
That research will also quickly tell you if someone is a jerk. Read what they say and how they are saying it and you will learn all you need to know about their social skills. It's a more precise test than an artificial environment of a face-to-face interview when everyone tries to play an all-around nice person. But the thing is, you can't be a nice person 9-to-5 and a complete jerk in your off-hours. A jerk is always a jerk. Better observe them in the wild when they feel nobody's watching them and they can behave naturally.
It also works the other way. I sometimes encounter overall rude people online who share in passing what company they are employed at. I always try to remember the name to not mistakenly end up there.
It's entirely possible that the person who has gotten that far in the process literally cannot code Fizzbuzz. It's not an insult to be asked to do these things. It's a reality caused by the fact that some people can BS their way into anything, the hiring process at most companies is deeply flawed, and usually not the fault of the people you are talking to in the interview.
Obviously anyone who is that offended by this has never seen the other side of the equation where you've hired someone who turns out to be completely incompetent despite appearing to be very knowledgeable and smart in the interview, and now you've invested a whole lot of time and effort and money even if you are able to cut the person loose quickly. It happens. A lot. And it's often not because the hiring managers and other interviewers are idiots or otherwise failed to interview the candidate well.
Academic institutions generally don't teach people to code. It's always a personal quest. You can tell a lot about somebody who's graduated but never gone any extra mile. That should be the basic filtering criteria.
I too have seen people studying at CS departments who were useless at coding. I even helped some mates with their assignments so that they wouldn't get thrown out having invested several years already, though our field of study was not purely CS but more the hardware side of things so graduating as a bad programmer wouldn't be a terribly bad thing. Yet I know for certain none of them ever planned to be looking for a job as a programmer. And if you investigated their programming accomplishments you would quickly find out they should be passed on.
I also noticed that people who are smart and even brilliant do graduate with real programming skills but without personal projects of any sort. The thing is, they may join in as an ordinary programmer but do not plan to stay there long, meaning to quickly move into management or a business branch. You probably don't want them either.
Some preliminary research is always the right thing to do. You won't believe how many times I arrived at an interview and watched the HR turn over my resume to the interviewer for the first time ever, so he had to quickly scan it to get an idea what to discuss. With that approach not much can be accomplished on the hiring track.
Also, many are simply not comfortable with the situation and too stressed to be engaged in any kind of intellectual activity.
That's not to mention that most cannot do thinking and verbally document the process at the same time. It's either or.
But also on a fucking whiteboard! You're thinking about your handwriting, trying to form shapes you've probably never written (like curly brackets). You can't copy/paste and move things around when you notice you made a mistake. You have to remember syntax and stdlib APIs, which is not everyone's strong suit (especially in languages with inconsistent naming like Python and PHP).
It's just totally insane to say that whiteboard coding is anything at all like working as a coder.
The main challenge is that you have to write what may be incorrect in order to get to what is correct in most problem solving. When you have people watching and potentially judging you, you try to program in your mind which is difficult. Then it shakes you because time is passing and you haven't written any code. They're drinking beverages and you're sweating, haha.
I will say however, that the company that had me do a whiteboard was very professional in how they handled disarming all these things you mentioned from my mind when they sensed them.
I got offered a job but I had several other offers. But I still had the sense that they were a good company.
I don't think whiteboards are fair, but I also don't think it's fair to write a company off for using them in their interview process.
If you're going to do them, inform the candidate ahead of time and also help put them at ease when you sense the inevitable anxiety. Let them know that you really want to see the approach not the end result and writing bugs is ok.
Sure, it's an extreme, but that's how most of these sorts of stories are taken by the interviewee, especially for a position that was advertised around very specific credentials or experience.
My keys lessons are:
1. Whiteboard coding is not actually about coding. It is about talking with interviewer, coming up with examples and demonstrating a clear cut though process and of course then showing that you can convert idea into code.
2. All this requires very good communication. I always made sure I asked many questions to my interviewers, cares about what problems they solved and treated him as "fellow developer who took time to help me out getting a job" rather than someone who is a judge trying to judge me.
3. What really struck me about OP's rant is that he probably did not invest time in researching how he would be interviewed in first place. All the recruiters who contact you are absolutely clear in telling you what to expect. You were supposed to know what to expect.
4. If the interviewer was rude or indeed "threw" the resume on face, I would strongly recommend informing your recruiter about this. Such person should not be allowed to interview anyone else.
5. As an interviewer you are supposed to help the person get a job by convincing yourself that he could be a good fit in the company. This is not very hard. It is an exercise for you too. You just cant say "write DFS on whiteboard". You must drive the person in right direction, giving hints and even if the person lacks intellect/experience you must make him feel comfortable and good. Even though that person does not get the job eventually you must help him become a better interviewee as he leaves that room.
> you're truculent, uncooperative and insist on being the smartest asshole in the room, you will not be finding work with my team today
Can not agree more. Often really smart people tend to be humble and love challenges than insisting "this is not the good way to interview me". An intelligent and curious person will not run away from a mentally taxing activity, he would face it bravely and even enjoy it in the process.
So many fallacies there. You're assuming that intelligent and curious people can't also suffer from social/performance anxiety. What if the person's just very introverted? They could still be an invaluable member of your team, but you'd never know that if you insist on interviewing them in a manner directly contrary to their strengths. What if the person's female, and doesn't want you staring at her butt even more while she writes on the board. Yes, that s* happens.
Even worse is the way you use "bravery" to equate distaste with cowardice. I'm sure there are programmers who have exhibited more bravery in more contexts than you ever will, but might still balk at jumping through hoops for you when they could be engaging in more empirically-proven interview methods instead.
~25 times interviewing, on either side of the desk, is not much of a sample. Look to people who have been there hundreds of times individually, thousands of times collectively. You might find that there are more techniques, more pitfalls, and more kinds of people involved than you had ever thought of before you made your appeal to authority. Whiteboard interviews might have their place in some very limited circumstances, but making them a default part of the process is just lazy and sets up a generally unhelpful competitive/hierarchical dynamic. An intelligent and curious person will not run away from other methods, but will face them bravely and enjoy them in the process.
To really learn about hiring, you'd have to interview those people and find out how well they do, but also how well the rejected applicants do. You can't test your assumptions if you can't compare the people you hire with the people you didn't.
And, for the record, I (and several of my colleagues) have interviewed almost 100 people each over the course of our careers -- more than 10 per year. We still don't have a secret sauce. Some filters work and some don't. Google has been famously working on this problem using extensive data analysis, and they still haven't cracked the secret of always hiring the best coders.
I've been on both sides and the key lessons the parent laid out are good. They're related more to being a professional in interviewing and whiteboards, not key lessons to ensure you hire the best people available which is what you are discussing.
Being a good developer requires the ability to write logical, maintainable code of course, but equally it also requires having the ability to talk to other developers, to work with a team, and to explain technical problems to non-technical people. Those are soft skills.
That's a non-credible excuse. If it's really about how you deal with adversarial situations, there's no reason for coding to be involved at all. There are plenty of other scenarios you could role-play that are more realistic and/or more informative wrt what software engineers actually do. Why don't people do those things instead? Generally, because it was never really about communication skills or reactions to stressful/adversarial situations. That's just the rationalization that people who actually did intend to measure coding skill come up with when they're forced to admit that the tool they've chosen is spectacularly ill suited to that purpose. Nobody wants to admit they've wasted so much of their own and others' time.
...and the rest of us are supposed to read his mind? Since we're talking about communication skills here, I submit that good communication skills might include stating one's meaning more clearly.
There's more to talent than writing code. It amazes me, this attitude that testing for social skills and fit is seen as insulting. Believe me, it's for the candidates benefit as much as the potential employer.
The original poster and you responded you do similar things. You meant something different I guess.
I agree very much with a coder is not supposed to only code; I guess we agree if you take away the specific 'I had to code on a whiteboard without even a computer present' of the OP.
But yes what you suggest here is what we do. And that is actually fun for the coder (if not highly anti social) as well as it is for the team too.
There seems to be very little basis for characterizing the OP that way, so now thousands of people reading this on HN get to associate that phrase with your name. What was that about soft skills?
It is actually a great chance of engaging in a meaningful conversation and hear more about their experience. I like people that can think for themselves and can be diplomatic.
I've had similar using live coding tests, barely minutes in and the candidate is clearly not coding what was specified. Asked why, they offer criticism of the interview process and an explanation of why their thing (usually a game or some graphical doohickey) is better.
This is an instant fail. These tests are as much about interaction and personality as they are technical skill. Which is why your GitHub profile is not relevant until afterwards.
You can have a profile full of great looking code, but if you're truculent, uncooperative and insist on being the smartest asshole in the room, you will not be finding work with my team today.
Soft skills, people.