[hanlec]

As many other parts of an interview, I've always found the blackboard coding session extremely strange. When was the last time you coded in TextEdit with no docs around, no time to think, standing up, and being watched over the shoulder?

[brianwawok]

I have pseudo-coded on blackboards many times, which is really what a blackboard coding interview should be. If you get a ding for writing .foreach instead of .forEach, that seems a bit picky ;)

However I realize I may have a bias as I do ok on most blackboard coding interviews I have done.. maybe been stumped 1 time out of 15 or so in my life? Some of it is a skill, that the more you do the better you get at it, but being good at it does not make you good at actual coding.

[istorical]

It's exactly like being good at academic test taking.

I'm very good at memorization (of facts, ideas/concepts, and procedures/algorithms) and that allowed me to do well in my younger years and in standardised testing, so I always just scoffed when I heard other people complain about how it was a poor proxy for knowledge / abilities.

Of course, now I'm terrible at pretty much all the standard ways of interviewing developers (...here's where you say I'm probably just a bad developer) and now I have all this past-due empathy for those I disregarded before.

[vonmoltke]

> I have pseudo-coded on blackboards many times, which is really what a blackboard coding interview should be. If you get a ding for writing .foreach instead of .forEach, that seems a bit picky ;)

In my experience, some interviewers, particularly Amazon interviewers, get really anal about putting correct code on a whiteboard, sheet of paper, or bare text document. I personally do not when giving interviews.

My bigger problem, and I seem to depart from the vocal majority on this, is that my preferred normal workflow does not use whiteboards for anything besides task lists and diagrams. In 13 years[1] as an engineer I have never written actual or pseudocode on a whiteboard outside of an interview. I rarely do it on paper. I have never worked with anyone who did this very much, either.

[1] Granted, four of those were as an EE, but I still had to deal with code from time to time

[dpark]

> In my experience, some interviewers, particularly Amazon interviewers, get really anal about putting correct code on a whiteboard

I had that experience with an Amazon interviewer. The guy who told me he expected perfect code also gave me zero feedback as I worked (despite me literally asking if I was headed in the direction he expected) and spent the entire time staring at his laptop. He'd apparently forgotten that he was scheduled for an interview, and also his manners.

[odonnellryan]

I was asked recently by a big company to code some classes in Python, on paper. They then questioned my indentation, syntax, and case-sensitivity multiple times!

A valid question, but paper-code?

[brianwawok]

Hah that is pretty terrible. In fact, I don't think Python is a very good language to code on paper due to the indentation side of things. Maybe graph paper would help?

[odonnellryan]

Maybe! Or just understand it isn't easy for anyone to indent things on paper haha.

[jpeterson]

In 15 years as a software engineer at companies large and small, I have never seen anyone code on a whiteboard (outside of interviews, anyway), nor have I.

[collyw]

I usually get a pen and paper out if I have something algorithmic to work out.

[recursive]

Approximately weekly, when explaining something to another engineer.

[vonmoltke]

As I mentioned in another post here, I don't think I have ever written code on a whiteboard when explaining something. Explaining code has always happened in front of someone's computer, in an actual editor or IDE. Where I currently work, we typically pair on really hairy code.

[jasonlotito]

Why don't you give yourself time to think? Why don't you use documentation?

Edit: Oh, and how do you version control the white board?

[EliRivers]

how do you version control the white board?

We have a magic white board that can print out a big piece of paper showing everything on it. We also take pictures of it (and lesser white boards) to record designs agreed. Those pictures generally get put into a formal design document that is reviewed, signed, approved and all the rest of it.

[recursive]

> Why don't you give yourself time to think?

Explanations work better without lengthy pauses. Ideally, I can explain the thing without stopping too long.

> Why don't you use documentation?

I do if it's necessary. Sometimes it's not necessary.

> Oh, and how do you version control the white board?

I don't.

[giaour]

You can snap a picture of a filled board with your cell phone.

[jasonlotito]

And you put the picture in version control?

[giaour]

There should be a time stamp in the exif data, so you could track progression from one photo to the next as a very primitive form of version control.

My original comment was mostly meant as snark, but I've had an interviewer take photos during a whiteboard exercise for this reason.

[mixmastamyk]

Not often, but I've taken a handwritten diagram and converted it to paths in inkscape, andd cleaned it up a bit.

The resulting svg or png can be then added to the docs folder of a project. Works well with sphinx, etc.

[nulltype]

TextEdit would be an upgrade. Try inserting lines on a blackboard.