5 ms·
Max Howell, creator of Homebrew, expressed this quite nicely: "Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary
by donw 10y ago
Max Howell, creator of Homebrew, expressed this quite nicely: "Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off."
This is not to say that computer science (CS) skills aren't important -- they are! But far too many companies base their hiring process around "are you a recent graduate from a top-tier CS school" rather than "can you do the work that needs to be done here?"
Being a software engineer is about way more than just knowing what algorithm to apply to solve a clearly-stated problem. You need to know how to build automated test suites, how to make software which is easy to deploy and maintain, and how to deal with the real world, where Things Go Wrong All The Time.
Having worked as a consultant for many years, with a large number of teams, I can say with some certainty that I would rather hire a person that had mediocre-at-best CS skills, but was otherwise a rock-solid software engineer.
Because the amount of time they will spend implementing graph-traversal algorithms is asymptotically close to zero.
They will instead spend pretty much all of their time needing to write code that other people can maintain.
Why would I spend the majority of the interview process focused on the former, rather than the latter?
Admittedly, this has given me quite an edge as a manager when it comes to hiring.
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.
- bluejekyll 10y ago> 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.
- flor1s 10y agoI 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.
- bramd 10y agoSounds 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?
- flor1s 10y agoI 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)
- paulddraper 10y ago> 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.
- Cofike 10y agoYeah, I got to see that first hand at my last company. Very difficult to judge someones capabilities without some technical test or something.
- cstejerean 10y agoWhen 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.
- jdietrich 10y agoUse 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.
- paulddraper 10y agoOh 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.
- 10y ago
- rebootthesystem 10y ago> 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.
- rimliu 10y agoWriting code or typing in code? If the former I believe developers spend amount of time significantly different from zero.
- rebootthesystem 10y agoIt 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.