Hacker News Reader

>And if someone can explain well what a piece of code is doing, then of course that person can also write code. How can you read without knowing how to write? [...] Reading and writing are two sides of the same coin.

I'm not so sure about that. I can read assembly code but I can't write it at a competent level that an employer would require. Reading code is often easier than writing it.

Maybe an analogy is reading vs writing a movie script. A lot of us can read the actors lines and set directions and can then explain what the movie is about -- but most of us are not skillful enough to write a movie script.

The deciphering-vs-generation divide happens in human languages too. Many times, a person learning a foreign language can understand what someone is saying but if asked to generate a sentence to express a thought, they often will be flustered and halting in their speech as the brain struggles to find the next correct word to say.

The reading vs writing skills don't seem to progress equally.

Similarly, it took a few months of learning to read Haskell before I felt comfortable writing more than just a couple lines.

I like the idea of code reviews in an interview though! Seeing how someone approaches a new code base would be a really pragmatic way to evaluate them. Having them make a targeted change to a smallish unfamiliar program would be informative as well.

Makes sense, It is also easier to read and understand a book than it was for the author to write it. You can also think you understand something while you read it and later realize that you misunderstood it.

In short, it takes a longer time to read code than to write a simple snippet.

Because you may not know the syntactic sugar syntaxes while being an expert at the language / field. They also may not know libraries that's been used by the code without researching beforehand.

OTOH, stripping the code to read from libraries and syntatic sugar syntaxes will reduce the code quality and sometimes making it harder to read / maintain. It doesn't reflect your tech stack in the company.

While writing code will guarantee that it's something the interviewee knows, with tolerable typo and syntaxes, and IMO it's more suitable for the interviewer to ask for written code than vice versa.

And if someone can explain well what a piece of code is doing, then of course that person can also write code.

I can read and understand many mathematical proofs and explain why it's true, but I could never have proven it myself. I can read and understand most of the great novels ever written, and even try to explain their greatness, but I could never have written any of them.

That being said, I agree that listening to someone explain and critique written code probably gives at least as good insight into their coding ability as having them whiteboard a leetcode problem.

I feel like this is a bad analogy. Mathematical proofs often require some deeper insight that is being communicated. While this can be applicable to code, this is in the space of inverting a binary tree type questions.

Most code we're writing is more akin to seeing if you can read a newspaper.

One of the best interviews I've had involved coming in and just sitting with the lead dev and we then spent an hour grabbing a fairly low hanging bug that was in their system and he just had me drive and allowed me to ask questions about the folder structure or conventions they used.

He could see I understood how software worked, could reason about their style and approach, and I could fix the issue. I learned about their style and approach and got at least a feel for if their code base was going to be a nightmare or not.

With that said... it's hard to time your hiring interviews with when you have outstanding bug tickets that you can time box to an hour or two and don't require so much esoteric implementation details that it's a waste of time. Koans are GREAT but they do fall short on being a piece of the project that the applicant will be working on, so you miss out on seeing how the applicant reacts to your codebase and he misses out on sticking his toe in it.

I use code reviews in interviews for a similar reason.

If they're not able to critique the code and explain what it's doing, why it's changing, and what a better option might be they're going to struggle working in our environment where code reviews are emphasized as a huge part of the SDLC and not just the rubber stamp at the end.

Well said. Jr Devs almost always face pre-existing code bases. All college courses have undergrads always starting from scratch for their project. Simply put one of the things they are least experienced with is reading someone else's code.

Completely agree. I have interviewed and hired a number of people and a simple one page reading code test (“What do you think the code does and are there any bugs?”) worked wonders.