Programming without being able to insert lines is not indicative of real programming. To me that's the bottom line.
Engineering whiteboard interviews: yay or nay?
111–120 of 370 posts
Re: Engineering whiteboard interviews: yay or nay?
#112Earlier quoted context omitted.
I've seen a respected engineer that I worked with for years, be told by an outsider that he was incompetent because he couldn't fizzbuzz an interview. Yet, they had no problem acquiring the project he designed and wrote. So yeah.
Why couldn't he do fizzbuzz?
"Why couldn't he do fizzbuzz with someone else watching his every move while he wrote on a blackboard with no interpreter to test his solution or catch his mistakes?" seems like the better question.
Re: Engineering whiteboard interviews: yay or nay?
#113A regular viewer of my daily Twitch programming stream (link is in my profile) asked me to solve a problem he was asked to whiteboard. He wasn't asked to draw diagrams or write pseudo-code so they could learn how well he communicated. He was asked to write the code and it was heavily implied that it must compile and run -- even though whiteboards don't do that.
Here's my attempt: https://youtu.be/6LHqrxrC6Uo
I solved the problem, with an IDE and a compiler. I communicate during the entire exercise. It takes me over 2 hours. Granted, I debug it, so that takes extra time. (Can't debug on a whiteboard!) I had to take one break. On top of this, I've solved this kind of problem before and it still took me more than the 45 minutes you're likely to get in a whiteboard interview.
And I try to cover all of the "hot topic" points I know the interviewer is thinking about: size .vs. time tradeoffs, iterative .vs. recursive, etc.
If I had to solve this problem on a whiteboard, in 45-60 minutes, with the bar being "it must run"....I would fail.
I guess that makes me a poor programmer. Instead, I'm a grumpy old man who is really tired of all this fraternity hazing bullshit.
Re: Engineering whiteboard interviews: yay or nay?
#114Whiteboard as a communication tool in interviews is great. Sometime it's easier to write things down, draw diagrams, and list technical points than just talking about it. Writing it on the board provides an outline to talk about stuffs.
Whiteboard as writing programming pseudo code or steps are fine. Just don't be a human compiler and demand perfect syntax.
Re: Engineering whiteboard interviews: yay or nay?
#115Earlier quoted context omitted.
VPE at Eaze here (the original author of the quote above) - You're 100% correct. We give our candidates the choice between working through a problem at the office (on the spot as you say) or doing a take home project asynchronously. Not everyone has the time to do homework, but not everyone wants to do an in person coding interview either. We try to stay flexible.
How do you compare the resulting apples & oranges? I can do a lot more at home (especially if I cheat on time, which everyone who really wants your job and can afford to do will do)
We're less concerned with the resulting code than we are about your ability to explain the code that you wrote and your ability to prove to us that you have good judgement when making technical decisions.
Also, we're growing fast enough that we're rarely comparing candidates. If we can hire both the apple and the orange (assuming both candidates are evaluated to be good for the role), we will.
Re: Engineering whiteboard interviews: yay or nay?
#116Earlier quoted context omitted.
>I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low. I think it's safe to say that being put on the spot in front of people you don't know who are judging you is quite different from being put on the spot in…
We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them. This is meant as more of a conversation, we're less concerned about getting to the "right, fastest, or most optimized" answer. Not a hard problem, no mindgames, no syntax rules, and no complicated pre-known algorithm work other than an if and a loop. Let's just talk about some…
That sounds like a much better way of handling a whiteboard problem.
In my most recent on-site interviews, my interview would be in a room with full floor to ceiling glass windows, the next interviewer would come in, ask one or two personal questions, and then either cut me off after a couple minutes or just simply say "we're going to move on to the whiteboard now, do this". Meanwhile people are walking by staring into the room, looking at the whiteboard, etc.
Which is just too rigid, IMO.
When I interview a candidate, I want to know that they'll be able to work together with myself and my current teammates as a team. So I would rather do something similar to what you described.
Re: Engineering whiteboard interviews: yay or nay?
#117A regular viewer of my daily Twitch programming stream (link is in my profile) asked me to solve a problem he was asked to whiteboard. He wasn't asked to draw diagrams or write pseudo-code so they could learn how well he communicated. He was asked to write the code and it was heavily implied that it must compile and run -- even though whiteboards don't do that. Here's my attempt: https://youtu.be/6LHqrxrC6Uo I solved…
It makes you someone that can't listen. The most important part of communication is listening. When the interviewer asks you to whiteboard a problem, they aren't asking you to "solve it". Obviously, you only have a whiteboard and you only have 15 minutes max. You might throw out some comment about size vs. time (eg) but make the decision and move on, quickly. The interviewer might decide to latch on but if not, you have to cover this in 15 minutes so you limit the depth so as to do that. Stub out all the deep functionality and then dig into each part of it as time permits and as the interviewer leads you in those directions.
As an experienced and good programmer candidate, the most important part of an interview is for you to evaluate the company. So the whiteboard is a great way to see if they understand what can be accomplished in 15 minutes on the whiteboard.
If they don't get it, you can end the interview short. Time saved today as well as the next several years working for a shite company.
I love the whiteboard interview.
Re: Engineering whiteboard interviews: yay or nay?
#118I'd propose a supplement for interviewing. If your company has at least one open-source repository: 1. Have a senior engineer chat with the candidate for an hour about a few bugs/features in the repository, and how the candidate would solve them. 2. If the candidate is promising, give the candidate a week or so to fix the bugs or implement the features. I think this would be a more relevant test than just giving them…
This basically filters out those who already have a job or getting multiple offers. Most candidates don't want to spend more than a day on an interview.
Re: Engineering whiteboard interviews: yay or nay?
#119I'll stop short of saying whiteboard interviews, with or without coding, are suboptimal. I will say that any interview question which attempt to see how I think is suboptimal. How I think when on the spot does not reflect how I think on the job.
Speaking for myself, I like pair programming interviews.
Re: Engineering whiteboard interviews: yay or nay?
#120I love these kinds of post. It's like saying:
"Highways: Yay or nay?"
"Food: Yay or nay?"
"Air: Yay or nay?"
Hate on whiteboard interviews all you want, but that attitude is going to put you a massive disadvantage in the current rigmarole of software engineering interviews. It's not a thing 99% have any interviewees have control over. Nor is there a way to tell the interviewer: Hey, I prefer not to do whiteboard interviews. It doesn't work like that.