Personal essays
How do you decide whether or not to hire someone?
You should hire Brent
I don’t know how long I’ve known Brent Simmons, but I can tell you this…
I would hire him without first asking him to stand at a white board and implement a doubly-linked list or to apply some algorithm that he might have found in a book that the recruiter recommended he bone up on before his interview.
By the way, if you want to see code that Brent has written you can always look at his NetNewsWire repository, Sure, lots of developers contribute to open source in their spare time - but this is different. Brent first released NetNewsWire so long ago that I had to check Wikipedia for exactly when it was. It was 17 years ago. He’s gone back and re-implemented the RSS reader for iOS and Mac.
My Apple Watch is probably more powerful and has more pixels than the Mac I first ran NetNewsWire on.
But I digress.
The interview
The last real interview I had was four years ago.
I love working for myself, though a little more contract work is always welcome, and it took a lot to convince me to apply for this job.
The friend who recruited me convinced me that this was a job worth re-locating for. I was skeptical but Kim encouraged me to check it out.
It was one of those jobs where they couldn’t tell me what I was interviewing for or what I’d be doing.
I was careful to describe what it was I was good at and what I thought I could do to benefit the group I thought I was interviewing for.
“Also,” I said, “no whiteboard test. If that’s part of the interview there’s no way I’ll pass and it will be a waste of your time.”
No, they agreed, there won’t be a whiteboard test.
There was a whiteboard test
I went to a building I’d never been to and was shown into a small, windowless conference room where I would spend the next eight hours - minus a bathroom break now and then when I was escorted to a men’s room off the lobby.
Each interviewer came in, introduced themselves, and explained what they were there to determine.
About midway through, the guy showed up who was to give me my whiteboard test.
I told him there wasn’t supposed to be a whiteboard test.
He told me things had changed but it wouldn’t be a big deal.
I shrugged and actually enjoyed the next hour. I didn’t get a lot of his questions right, but I didn’t care. As I struggled with the questions he would push me one way or another and I learned a bunch of cool things.
For those of you who may not know, a whiteboard test is where you stand at a whiteboard and someone gives you one problem after another to tackle and you’re supposed to code the solution on the whiteboard.
There is nothing natural about this.
In real-life when I had worked for this company before, I would discuss problems with my colleagues. We’d bounce ideas off of each other and then one or the other of us would start coding - or we’d go away and work and bring something back later.
I might get stuck or I might implement something so unusual that the other person would say, “that doesn’t feel right.”
Oh, and while I’m coding on my computer the compiler would remind me of mistakes I’ve made. I could look to the docs to find the method I wanted. I could look through the source code and see how someone else had solved the problem and just call their method - why re-implement something that existed and had been tested.
Back to Brent
So Brent described a problem he was given and his solution.
Now this was not a question he was given in an actual interview or at a whiteboard. This is a question in the prep situation he was taking to prepare for real interviews.
He writes, “My style of coding is to break problems into steps and make it super-obvious to other people — and future-me — what the code is doing. I like to write code so clear that comments aren’t needed.”
He then provides code he would write.
Surprisingly, people pushed back on his solution. What if the number he was being asked to work with was forty digits long.
I would think that that would be part of the problem description. But that’s not the point.
You can see the kind of code that Brent writes by looking at his GitHub repository.
I would use the face-to-face interview time to see if he’s the kind of person I’d want to work with.
He is. He’s bright, kind, supportive, resourceful, and actually has shipped products. A test that Brent doesn’t pass is a test that should be questioned.
In a follow-up post he writes that these whiteboard tests are intended to see how you think.
Brent writes, “I usually start with some hazy intuitive approach and start writing code. I code and think at the same time. I revise what I wrote, or even delete it. Then I go for lunch.”
Me too.
Essay from Dim Sum Thinking Newsletter 5. Read the rest of the Newsletter or subscribe