Hacker News Reader

> Being a software engineer is about way more than just knowing what algorithm to apply to solve a clearly-stated problem.

Actually I think this is exactly what a software engineer is. Knowing what datastructure to use in which situation because of its implementation details is important! Yes, it's not the only aspect of the job, but it's hugely important.

It can be as simple as Arrays vs. LinkedLists; where Arrays have zero cost access and LinkedLists have high indexing costs, but low constant time insertion costs where you don't know the content length. This can have huge effects on the performance of an application.

This is important to applications, and no, you don't have to implement the datastructure, but knowing which to use when and why can save you the time later from having to find all your performance problems.

I was interning at a pretty successful software company in The Netherlands. I have never heard anyone there discuss about whether to use Arrays or LinkedLists.

In the binary education system in The Netherlands there are two types of universities, that which prepare people for industry jobs and that which prepare people for research. I went to both, the former has only a small focus on algorithms, complexity and datastructures. The latter has specific courses about those topics.

I think in practice you can often reach good enough performance without worrying about which algorithm or datastructure to use or what the complexity of your code is. There are many exceptions where those kind of skills are actually required, but it's easy to forget that software is a huge market and that a large portion of that market is people developing fairly uncomplicated applications.

You can create an incredible amount of value in the software industry without knowing much of computer science, but you are dependent on people who actually have that knowledge to create your tools, dependent libraries, used services, etc.

Sounds familiar. I had only the former kind of education. Often I'm pondering if I should pursue a masters degree in anything CS related. It's not that I really need it for my work. So, my options are to either do a CS master, and have to catch up on a lot of math and CS fundamentals, do some master in a totally different field such as business administration (useful since I have my own company), or do nothing at all :). Any advice from your perspective about this?

I loved my time studying for a masters degree, and after graduating I started with a PhD in Japan which has been an amazing experience. If you want to learn many new things, meet interesting people from all over the world and you don't mind going back to taking classes I would definitely recommend it. Don't worry too much about the math and CS fundamentals. The stuff you need to know to do a master's in CS is quite useful in practice, so it's valuable to learn about that anyway. Some specialisations in CS require more math than others, so keep that in mind.

If you don't know whether to do CS or business administration, you might be able to do something in between, e.g. business administration with a IT specialisation.

(I got master degrees in Computer Science and Business Information Technology from the University of Twente and am currently a PhD student in Empowerment Informatics at the University of Tsukuba in Japan)

You're making an assumption that "performance problems" are important. Sometimes they are. Often times they simply aren't. In my experience, outside of certain components of a game engine, scientific/numerical computing, very large (e.g. Google scale) systems and a certain class of real-time systems the difference in performance between one data structure and algorithms that operate on it or another simply isn't worth worrying about.

It's far more important that the code be simple, readable, and integrate easily with other teams' work.

You left out a really big, significant sector: finance. Minimal latency is king (at least in trading). This often means little or no heap allocation (if there is any, it's often done up-front). User-space network stacks to avoid the user to kernel context switches. Web devs think that sub 10ms response time are good. In finance, often anything over 10 nanosecs (for example when responding to an IOI - indication of interest) is trash.

Yeah, sure, in some domains latency isn't terribly important, but there certainly are a number of domains where it is.

Yes, we are in agreement (except for what I perceive as a derision toward "web devs", which by the way I am not and didn't even mention, so I'm not sure why you even mentioned it). I also left out specific kinds of some very resource constrained domains in general; a terrible omission on my part. I'm sure there are others as well that I didn't call out specifically. Not having experienced every single kind of programming problem type I rather think it would be silly and pretentious of me to try to enumerate them all.

> except for what I perceive as a derision toward "web devs", which by the way I am not and didn't even mention, so I'm not sure why you even mentioned it

I didn't read it as derision. I read it as an indication of a different focus between two areas of development. Microseconds don't matter in most cases. Milliseconds matter more often. Something optimized for microsecond-ish timing will make a tradeoff somewhere else (like code readability, generalness, etc).

often anything over 10 nanosecs is trash

Are you sure you don't mean 10 microseconds?

He probably means 10 microseconds, even if he's talking about HFT. The state of the art for FPGA's seems to be around 700 nanoseconds. [0]

[0] http://stackoverflow.com/questions/17256040/how-fast-is-stat...

Sometimes you have to wonder how much we are suffering "death by a thousand cuts" though. This is still quite noticeable on mobile and in certain applications.

>It can be as simple as Arrays vs. LinkedLists; where Arrays have zero cost access and LinkedLists have high indexing costs, but low constant time insertion costs where you don't know the content length.

But then in the real world, arrays can still be faster than lists even when you're inserting a lot...

https://www.youtube.com/watch?v=YQs6IC-vgmo

Yes, if you can afford the allocation of the memory upfront Arrays are always faster :)

My point was more that understanding the semantics of the two types is important to how the program will run.

> Because my hiring process focuses on "can this person do real-world work in a real-world context", I usually manage to find rather excellent engineers that other companies overlook.

Ah, if only we could know how well the people do at the jobs they are hired to do.

9 times out of 10 that requires gut feel, subjectivity, biases, etc. Inverting binary trees is measurable and objective.

Yeah, I got to see that first hand at my last company. Very difficult to judge someones capabilities without some technical test or something.

When you have a large volume of applicants and new hires (like Google does) then you can actually start to measure the correlation of the things you can assess in the interview vs long term job performance. Then you can make your decisions about who to hire based on this evidence rather than gut feel, subjectivity, biases or even CS trivia. It's much harder for a small company to do that, so at best they can end up copying the methods of the large ones and hope that their situation is similar enough.

Use a realistic work sample test. It's marginally more time consuming than a whiteboard interview, but it's fairer and more effective. Most candidates would vastly prefer to commit and document a small patch than solve brainteasers in front of an audience. You'll learn a lot more about their practical skills.

Oh 100%.

I give 60 minute programming exercise in a language of choice as the first part of the interview.

I do that part first because it separates the doers from talkers quickly. Measurable and objective.

Certainly measurable, but what are you really measuring? If I gave one of my junior devs a serious problem to research, consider and solve and they came back to me 60 minutes later, I wiuld tell them to go jump in a lake...and I'm certainly not looking over their shoulder while they do it. I always say I do my best development in the shower when thinking about a problem fir a while. Unless you plan on jumping in there with me, you'll miss a lot of where my actual problem-solving happens. Short syntax questions to screen and longer-form 2-dayish take home problems for the win... with practically every other approach you're measuring things that just aren't really germane to how good software is developed.

> Because the amount of time they will spend implementing graph-traversal algorithms is asymptotically close to zero.

Yes. Definitely.

Depending on the nature of the work I could see expanding this statement to include writing any part of the software. In other words, "the time they will spend writing code is asymptotically close to zero". This, BTW, is also the reason I don't care for discussions about text editor efficiency. In certain domains these can be rounding errors in the accounting of the totality of the work surrounding the production of solid, reliable and well documented software and the tools required to test, deploy, support, configure and sometimes port it.

I can't remember the last time I asked a candidate how they would detect a palindrome or traverse a tree. I could not care less. There are books and google for that. I want to know how they think, how they organize projects, what they prioritize, how they approach new problems, etc. I also want to know they understand how business works. I prefer people with entrepreneurial experience, even if they failed...particularly if they failed.

Writing code or typing in code? If the former I believe developers spend amount of time significantly different from zero.

It isn't about the time spent typing. It's about that time in relation to the totality of the job. The fact that coding time isn't zero means nothing.

Depending on project type a team can easily spend 10x more time doing things other than actually typing code. In fact, they should spend 10x more time doing those things, for example, architecture, design, documentation, testing, etc.