Hacker News new | ask | show | jobs
by sorbits 6136 days ago
I realize the notes are for preparing a potential employee for a Google-style job interview.

I am curious if there are any employers out there with tips for follow employers about how to screen candidates.

I find that a vital skill is understanding good code design, that is, placing the responsibilities with the correct code, keeping dependencies down to a minimum, proper encapsulation of the complex stuff, separation of concerns, etc.

I recently hired someone who is a decent coder and problem solver, but I regularly have to “correct him” when he starts new submodules because he still doesn’t master the “design” aspect of coding.

That is, he might do some rudimental analysis about how to structure things and what the API should be, but if I don’t stop him, it always ends up being more complex than need be, and I honestly don’t think he knows how he could do it better, because it is really the same things I say to him over and over.

Since I will hire more people down the road and since I am tired of having to point out the same design flaws over and over, I am interested in tips for “testing peoples design skills” and also book recommendations about how to master big software projects without it ending up as tightly coupled components with arcane code — which sadly seems to be how most projects do end up…

3 comments

Complexity can sometimes be a perspective thing. I recall a discussion at one point with a co-worker were we were each arguing that the other persons approach to a particular problem was more complex. After much contemplation I was able to see both perspectives.

Also with some problems there seems to be a conservation of complexity notion. It's inherent in the system and depends on where you push it.

For the book, you might want to check out Large-Scale C++ Software Design. Unfortunately it's at home so I can't crack it open and double check, but it seemed full of suggestions on structuring code and layout a large software project.

Yes, I agree that a lot about how to structure code is subjective, which is also why I am very interested in having better terms to describe this — thanks for the book suggestion!

Giving it some more thought, I think it boils down to realizing when one is solving more than one problem, and then being able to write the code so that each problem is solved in isolation, yet without introducing complex APIs between the different pieces of code.

Often though the sub-problems are subtle and hard to predict, plus realizing that two problems are being solved is not in itself enough to figure out how to actually split it up (sometimes splitting things up contributes to the perceived complexity)…

My favorite book of this type is Thinking Forth, available online at http://thinking-forth.sourceforge.net/. You will get a large dose of the Forth mindset, but it's mostly higher level design tips and not as specific to Forth as, for example, How to Design Programs (read: Functional Algorithms in Scheme). It's a fun read, and a great way to get a perspective on design that is different than what you get from the usual object-oriented or functional language centric sources.