Hacker News Reader

Comment by BhavdeepSethi | Hacker News Reader

And yet, most coding rounds in interviews are rigorously timed. Almost always, the importance is given to code completeness rather than code design/elegance. I'm sure a lot of talented engineers lose out here.

View on HN

Most interviews I've done have expected me to write code on a whiteboard. This is pretty unnatural for me. I'm a very fast typist, so it's frustratingly slow to have to draw letters manually on the whiteboard.

At least in my experience, the main point of coding interviews has always been to expose and analyze the way that you approach and solve problems, not to see how fast you write code. It's usually better to take a step back and re-evaluate the design of your solution rather than dive into the first solution you create, since you'll usually find a better way to express the solution that is short enough to write down on the whiteboard without pressing against the time constraints.

It's also important to see how reliant people are on their tools.

Why shouldn't a programmer be reliant on their tools? What a bizarre idea.

I like to measure a carpenter's skill based on whether they can build a nice looking bookshelf with just a pocket knife said no one ever.

If you're asking them to design something rather than build something off a pre-existing design, you might like to know that they actually understand the principles of design, and aren't relying on a tool to pretend they do.

It is completely reasonable to rely on a text editor and the language interpreter. Hell, even the language documentation.

This could be an issue with really fancy IDE features, but there's a world of difference between a whiteboard and an IDE - namely, a text editor and an interpreter/compiler.

I don't think the whiteboard interviews expect an executable at the end of the process. It's not a complete test, but a partial one: testing if you can come up with suitable algorithms within a reasonable time - and perhaps how you work/your process. None of which is dependent on any (software/IDE) tools

I joined one of those 7-day coding competitions for a game. I ended up with a framework for making games, but no game. Needless to say, I came in last place.

If you can't write a simple function to reverse a string, or words in a string, in a rather short amount of time, is that a good sign? Sure, everyone can pop out the "well the most elegant is use the stdlib's reverse function". But then you say well implement that as efficiently as possible, and we know the end result is a simple little loop -- what should taking more time mean? Someone that takes 10 minutes to come up with the function makes me a bit more nervous than someone that takes 1 minute. Is that wrong?

> most coding rounds in interviews are rigorously timed

In the real world you will have to work against a deadline. As much as code gardening is fun and does produce better software, in the real world shipped software always wins over well designed software.

Can you get it done, is a more important question to answer than can you make it beautiful.

In the real world, you'll be spending more time on code design than typing it out. The race against a deadline mostly affects design choices. eg. Whether implementing a certain feature yourself with rigorous testing, or introducing a new technology which has been tested before. There are pros and cons of each. You go ahead based on the constraints involved (time, cost, expertise, etc.). I'm not talking about making the code beautiful. I'm talking about the /right/ way to do it.

While that may be true, timing your solution of an issue at a whiteboard isn't necessarily representative of your 'ability to ship on time.'

I find that to a point (and let me emphasize this is to a point), every hour I spend on design saves me 10 hours of coding.

I also find I am a code gardener and a slow programmer but I get told I ship working code faster than most of the fast programmers out there.

Reply on news.ycombinator.com