Originally published at deepu.tech.
This topic has been discussed and debated for a long time and there have been countless articles written about...
For further actions, you may consider blocking this person and/or reporting abuse
I wish it didn't matter but I'll preface this comment with the fact I'm a woman, just in case. I don't mind whiteboard, in fact I prefer them over take home assignments. Live coding I've never done so I don't have an opinion.
Of course I don't enjoy stress but HR has to see if you have the skill needed to fit in the team and the mentality. How you handle the stress of a whiteboard (or an oral examination) that's also a good skill to assess. It's not true that you won't ever code with someone looking over your shoulder, pair coding for example has someone literally next to you, watching you code. You need a certain level of stress resilience, especially if you'll have sprints and releases to make. If you have to explain to a senior what you did you need to be able to explain your logic as you go along, or code along. Not having Google or your IDE means that you rely on your logic and reasoning capacity, which is a hard skill, without the crutches of your IDE.
I see it a bit like an IQ versus a math test. You can use memory when it comes to math evaluations, so IQ test try to filter this out when measuring the logical-mathematical type of intelligence.
Combine hard skills with a solid soft skill set, such as being able to explain while you reason, humour if you get stuck, finding workarounds such as writing something in pseudocode and saying you'll google the syntax later, all those are good pointers of how you'll be when faced with hardship and less than optimal conditions.
Personally I've had brain-blanks on interviews where I had no idea what to do anymore. When that happened, after trying to fumble through it at first, I came clear to the recruiter about what was happening and explained the situation, had a discussion about impostor syndrome, expectations etc. It gave me feedback on how to better prepare, even if it was a disagreeable experience, it was a "good" one in the sense that it helped ace my future interviews.
Thanks for the response. I guess you are mistaking general stress with performance anxiety. If you are a good developer you are not gonna feel stressed when pair programming coz you know that you are working with your peer, a fellow human with flaws like you, who might make mistakes like you. Its not the same when an interviewer is looking over your shoulder and you know that your mistakes might cost you the job, so you start getting anxious ending up making even more mistakes. So I'm talking about people who will perform well during peer programming but cannot do anything during a live coding (I fit into that category and dare I say, I'm a pretty good developer according to my peers) so no I don't agree that evaluation of stress is necessary in anyway. Also lets be realistic you won't face situations that induce performance anxiety in your day today work and if you do then I would consider that a toxic work environment and I would run far away from there.
I'm not trying to discredit your experiences. They are of course valid for you but doesn't mean you should expect them to be valid for everyone and the process shouldn't be unfair to others who cannot cope with these practices. A fair process should cater to the lowest denominator.
I think there's a major difference in how we view the issue. The issue is performing poorly under performance anxiety. You seem to say that interviews shouldn't put you in situations where you experience performance anxiety. I say you should find ways to deal with performance anxiety.
Well you are entitled to your opinion but I don't agree. My point is there is no need to put someone through that in an interview as it doesn't measure anything that is required for you to be a developer. Having even extreme performance anxiety doesn't affect your development quality in real world jobs so what is the need to do it. If you just accept the status quo and move on nothing will change and I for one would like to see change and want to attack it at the root
Being able to successfully manage your emotions (whether that's anger, anxiety, feeling down) I think is a very important soft skill - in your job and private life. If you realise you struggle with performance anxiety, it's a good idea to look at why that is and where that comes from. It might liberate you in other areas, or make it clearer for you in which environments you thrive or not.
Of course if you can work on thats fine but doesn't mean others get to incite that. Same for other emotions, you can try to control them but wouldn't you prefer that no one makes you angry or sad especially at work. Also unlike anger, anxiety is not easy to control and often requires medications with powerful side effects or phychotherapy
While I agree with many of your points, as I've said on now dozens of these posts, there's one problem you're overlooking: we have to be able to verify your skills!
Live coding is the only way we can get to know how you approach coding! It's not just about getting code running; it all comes down to how.
We owe it to all our employees, and to you if we hire you, to actually make sure all hirees can code. Believe it or not, there are applicants who are actually just clever disguised outsource brokers, and others who cannot code but apply for jobs whose minimum requirements are many miles beyond their abilities.
Rather, a good interview involves live coding something practical, and the interviewer should know how to account for nerves.
Personally, I like pairing the take-home and live coding together, for a few reasons.
I actually appreciate take-homes, even when I'm doing a lot of applying myself, because it gives me a taste of what that job's coding is like. I can self-eliminate myself in some cases; in the least, I learn something I can use later.
If the live coding builds on the take-home, it's less "surprising". The applicant knows the code; they wrote it. (And if the applicant outsourced the code, it becomes immediately apparent.)
A real job will have naturally occurring high-pressure situations, not by conspiracy of an evil boss, but because stuff happens. Prod goes down. The product is late. A bug has shipped. Whatever the situation, it's helpful to see if someone can still think critically if they're nervous. No, their performance won't be at its peak, but a good interviewer can account for that.
In eight years, I've learned that if someone's bravado is so strong, they can march into a final interview and go through the whole thing without any nerves, they've got an ego the size of Ontario, and will not be an asset to the team. Nerves tell me there's a real human there. (Seriously, I second-guessed this for years, only to discover it was entirely accurate.)
By the way, in the near decade I've been doing this, very few female applicants (maybe one in eight years) or minority applicants (less than a quarter, same as for white males) actually struggle with the live coding. There are plenty of candidates, in roughly equal proportions for the different demographics, who self-eliminated from the process, because the take-home made it clear to them they weren't ready for this yet, so it saved us both time.
But, all that aside, yes, nuke the whiteboarding and fizz-buzz. Take-homes and live coding are good, I'd even argue, utterly indispensable for hiring well, but only if they're based on an original, practical, job-related premise.
Unfortunately, if you were to tell developers to just walk out on any company that uses live coding, you can almost guarantee that the job they'll get will be with an unvetted team, which they will almost certainly wind up having to carry.
No you don't. You need to be able to measure the interest somebody has in the job. You have to measure how your candidate can adapt. The knowledge of today will be different from the one tomorrow, so what the point to measure something which will change?
Another question: how do the candidate evaluate the company? 'cause you know, it doesn't only go in one sense.
Even if the candidate is a liar, as you say, you can still ask him some questions he won't be able to answer. Example: what's an interface, or whatever other construct in the language of your choice.
Even better: there is the trial period. Or a trial day. The candidate can see how the company work and see if he or she likes it; you can see how he or she adapts to your real work. Win win. You have to pay him or her, of course.
The go home stuff: I'm sick of them. Spending hours, not payed, on tests? Not my thing, thanks. Especially if, on the other hand, people who interview the candidate learn some stuff from his or her test. It's called working for free.
I'm not even going to take the time to respond to your points. While I will not make any assumptions or comments about you as a person or your intelligence, as to the ideas outlined here, there is nothing even approaching a rational proposal in your entire post. I would strongly encourage you to get some practical experience hiring; after a few years of seeing things from the other side of the table, you'll understand why your proposals are altogether irrational from any stance: practical, interpersonal, or logistical.
I have some practical experience hiring, and it works quite well.
Well, I'm glad you've apparently been lucky to only ever get qualified, honest candidates and work for companies with boundless time and money, who can take on the significant costs and legal risks of "test hiring" all these candidates. Count your blessings; very few (if any) people in hiring get to work under such perfect circumstances.
Meanwhile, I've never gotten a complaint from anyone, including from the diverse set of employees who later got to participate in and give feedback ON the hiring process, nor from anyone in the career services departments of the universities I work with. Seeing as the way I'm doing things was developed over years, with exponentially more care, compassion, and attention to the interpersonal components than you imagine (read "accuse"), based on what worked and what profoundly did not, I'll stick to what actually works.
For everyone else reading: I urge everyone NOT to take Matthieu's advice about what is acceptable in hiring into account when job hunting. From someone who fights long and hard for compassion, communication, and diversity in tech, I assure you, the hypothesis he forth is based in utopic ideals, not the daily realities of business. Burning a bridge at one company can close many good doors elsewhere. Don't burn opportunities just because you don't want to put in a couple hours of unpaid effort into the process (the company is already spending a lot of time and money just to consider you), or because you're paranoid they'll "steal" your take-home work (baseless: we already have a solution long since written for it, and you're probably not Donald Knuth). It's reasonable to set boundaries for yourself, but the hard reality is skills must be verified somehow, out of respect for you AND the rest of the team!
Job searching is hard on both interviewers and interviewees. Hiring managers are not automatically malicious bad-actors. We don't know you from Adam. Expect to prove yourself, to the same degree you expect us to prove ourselves. That's how this works in any skills-based industry, and tech is no different.
For somebody who speaks about compassion, your post seems a bit... aggressive. I'm sorry if you misinterpreted my opinion, I was just saying what I was thinking.
I'm an idealist for sure, but, as John Lennon was saying, I'm not the only one..
Nice, 😄, But what is correct process to evaluate Software Engineers then ? Also what do say about Algorithms and Data Structure Questions in a interview, is it really required ?
IMO the focus should be on evaluating ones logical skills and reasoning along with ability to learn. So short coding assignments (which doesn't take more than few hours) would be fine along with a discussion with the candidate where you just talk about technology architecture and so on. Algorithms and data structure can be part of the discussion if those are in scope of the work
Totally agree on that. I would try to determine as well some soft skills, like the ability to speak about ideas he doesn't agree on.
As a second step, I like trial day / morning trial day (payed, please), where the candidate:
The company can see:
Tried it in 3 different companies, it works very well.
Another thing: if the candidate as enough code online, skipping any coding challenge should be possible
Yes, the onsite day works well as long as it doesn't contain supervised coding. I enjoyed such sessions when the focus was on discussions.
Totally agree. How the team works together (and how the members communicate) is really important, maybe even more than the technical skills. I believe adaptability and willing to learn is important too.
It depends of the company of course, but I mean if you're maintaining a CRUD application, I don't see the point to have highly skilled engineers capable of writing a Fibonacci recursion in 12 languages.
I'm interested in this too.
I'm in a "position of power" - our old process was using pen & paper to answer pre-set riddles. So I changed it to a take-home code sample (use your own setup, fulfill these vague 7 requirements to write a CRUD application with 3 data entities, acceptable answers can be done in an hour, but take a week if you like).
That's just for seniors, juniors get "tell me how to fix these two bugs, and optimise this one algorithm." The bugs are just missing colons, and the algorithm is designed so that you CAN'T get it right - because for a junior, I only care "do you know the language, and how quickly do you ask for help?"
So, how can my hiring process be improved? Genuine answers will be IMMEDIATELY implemented (and I'll give the next few days of candidates as much notice as I can).
@deepu105 , any thoughts?
That's a bit flawed logic, isn't it?
I'm a hired worker, I've been coding professionally for a couple of years. I've never had anyone sitting behind my shoulder watching me coding at work (unless we agreed on pair programming).
Based on that it seems that I am able to provide certain value to my employer without having to let people sit next to me and watch me write code.
So why the ability to code with someone sitting behind my shoulder should determine whether I am suited to be a hired worker?
For now, I write mostly on my blog about foundations and soft skills, but sometimes I just think going full blown into this problem.
I'm coding professionally for 10 years, and for 10 years I had to endure these interviews. People were globally happy to work with me. Nobody really complained about my skills. Some companies would love me to come back.
I'm not the best, but I like what I do. It pushes me to learn more, to try to be better, to try to help my peers. But I'm so useless in interviews. I'm so tired to code the usual fizzbuzz or to balance binary tree. To me, it only indicates that the team I will work with is composed of people who were hired based on random tests, and that the company has no idea how a developer can bring value.
The last company I applied for, they asked me to pass a test for 4 to 5 hours. Not payed, of course. Another one: coding test of one hour on Hackerrank, about algorithms they would never use. I have hundred of examples like that.
This was my rant. I wrote an article more or less related some time ago, if you're curious.
I'll check it out. thanks
That was a great article. thank you for sharing
No, I cannot when someone is looking over my shoulder on a whiteboard. And I'm not a junior developer, look up my profile. This has nothing to do with seniority its about performance anxiety. I can however can write even complex code a notepad when I'm at my own comfort. Also release deadline is not same as having to do something in a live coding session.
I've been a hiring manager as well as a developer forced to do these whiteboard sessions which I like to refer to as coding performance art, I find them generally useless and absolutely stress inducing. I think they are perhaps useful if your hiring some one what will be presenting technical designs to an audience but really they don't have much place in an engineer hiring decision. I have seen good developers struggle with this practice and hired them anyway and their performance has proven that this method is invalid.
Great article, I Think you are right that as a group developers need to push back on this sort of practice and pass on the interviews or request another form of evaluation. I for one no longer accept this sort of interview either and I have a number of peers that decline them as well. It's up to us to make the change!
Great to hear that. This is the kind of change I'm talking about. Btw even to present technical design and stuff to audience you don't really need this evaluation. I have been in pre sales presenting tech design and solutions to clients for many years and I'm also a public speaker who have done around two dozen conference talks many of which included live coding. But I'll still tank a whiteboarding session.
Well, where I live its still an employee market. Also, that doesn't matter even if its an employers market we can still try for change.
you are oversimplifying and overgeneralizing the issue IMO. First of all I'm not talking about the outcome of these interviews, I'm talking about putting someone through unwanted anxiety. Not all hiring managers are like that and even if they are it gives them no right to put someone through unwanted pressure. The person applying for the job might already be having many issues (Jobless, desperate, family issues, money issues, and so on) why add more stress to that?
Nice. Exactly when someone is staring at my screen I cannot write code. Another problem with Coding Platform problem statements is that most of them are pseudo-problem statements. Home assignments are good as we can finish those without any pressure.
I wasn't over generalizing by saying everyone goes to through Anxiety and pressure. I clearly said it only affects some people (and I would assume those are at least half of all devs from what I have seen and heard) but changing the process can't be done conditionally so yes for that I was generalizing. And your comments about if I know how the job works and about hurting feelings are bit ridiculous and I'm not gonna respond to that. If you want to know you can look up my profile and judge if I know how "jobs" work
So everybody should work long and hard to be able to succeed in interviews, like you did, because... ?
If people look over your shoulders and judge you constantly everyday at work, like managers do during interviews, asking you questions every 5 minutes "to see how you think" and breaking your flow, on tests which has nothing to do with the real job, you should definitely find another company.
It's not how it works. People support each others at work. They learn from each others. They build something real and (hopefully) useful. Interviews are completely different.
From interviewer's perspective, I enjoy doing live coding. It gives me an opportunity to not only see the candidate's coding skills, but also to understand their thought process, and to see their communication skills - can they explain me how they plan to solve the problem? If they get stuck, can they explain me what is the issue?
In order to make this process as comfortable for candidates as possible, I asked them to either bring their own laptop, or tell me they preferred language and IDE so that I could prepare it for them; we used a laptop + large TV, so that I didn't have to sit behind the candidate, they were looking on the laptop and I could see the code on the 2nd screen; candidates could use any online tools available when writing code.
It worked for some candidates, and it worked quite well. I must admit though - there were cases where people I knew people failed because they were stressed. I had one candidate literally look at me scared and say "oh, you're going to sit here and watch me coding?!". So I agree with you that this is not a great way to test candidates. Being good at live coding is not the same as being good at software development.
Eventually I think the take-home exercise (+ a follow-up discussion during live interview as next step) was a good balance between giving candidates environment that allows them to show their best skills, and my need to evaluate their skills and to determine whether we should be working together. You're right that these exercises might take some time, but it's an investment on both sides - my team prepares the exercises, we review the code, talk to the candidate, finally if we reject the candidate we provide written feedback on what went wrong. I think it's a fair deal - both sides invest some time (and I always check with candidates how much time they took to complete the task, so that I can limit the scope for the next candidates if I underestimated the required effort).
Great to hear that. I hope you switch to sort take-home assignments for future candidates.
@deepu105 : Nice article. I could relate to this very well unfortunately. Sometimes like 4 or 5 interviews or even more each of which is around 1 and a half hours long and all of them live coding of some sort. I am thinking part of the reason for this kinda of interview process in the industry is that it gives a process; a deterministic mechanism whereby given 200+ applicants you could choose the one (or maybe few) and probably works well and quickly compared to other methods (such as take home).
Also I feel I am spending more time on interview preparation (reading books like "Cracking the Coding Interview") rather than actual coding which is sad. Imagine if it's 5 interviews with the same company I do this preparation 5 times; it's anxiety before interview; at the interview and also after the interview if you know you are progressing to next round. Although having gone though this over and over again I feel I am getting used to them. However I also feel I have gotten better at "interviewing" rather than "coding" which is sad 😄
I don't hate this kinda interviews but I wish it would change to something better in the future but for now it is what it is I guess. 😄
Yes exactly developers are being evaluated for anything other than development skills
I agree with some of those points the interview hiring process is quite broken and convoluted to the point of driving a sane person crazy. It needs an almost complete rework because let's face it there are dozens of highly skilled unemployed developers out there who are more than capable of working. And I find it ridiculous that many companies have job descriptions listing many skills that are not even required on the job.
All it does is scare people away from applying for the role leading to imposter syndrome when you think you are not good enough when really they are looking for just 1 or 2 skills. And then these companies complain that they can't find the right candidate or that hardly anyone applies for their roles.
some times you need a time machine to meet the 12 years K8S experience. Or you need to have the 100% skills for the unicorn role.
I have been offended by the offer of a contract role instead of permanent because they were not too sure about the role. They arent hearing from me anymore and i will be sharing my thoughts on Glassdoor!
Well seems like you clearly don't have any idea of what I'm talking about and also pair programming with a peer is not the same as someone watching over your shoulder for the sole purpose of evaluating what you do. Also, I'm a hired worker for the last 10+ years (I never had any issues getting jobs or passing interviews) and none of my jobs had live coding/whiteboarding (coz I rejected such interviews as its not worth my time, regardless of the company) and my work colleagues and OSS colleagues know about my skills so what is your point?
Also your response gives me a feeling that you really don't get what I'm talking about which means probably you are among the lucky ones who don't get performance anxiety or imposter syndrome. Good for you. But it also means it will be hard for you to imagine what the rest of us go through.
Good for you but unfortunately its not easy for everyone to get over anxiety. If you were someone who faced it, I'm surprised that you are unable to sympathize with others facing the same.
Yes, I would consider such a workplace toxic and I would be running far away from there. If you feel forced to work in such a toxic environment I would be working hard not to overcome anxiety but to improve my tech skills to find another job