I’ve been a professional developer for 20 years and have never had to recite CS algorithms or solve obtuse problems.
My last three jobs I had to whiteboard an architectural diagram of a system, come up with a 90 day plan to create a software development team (I didn’t know I was applying for a lead position), and describe how I would introduce Devops, redundancy, traceability, etc into a system
The closest I came to a CS style interview was my second job out of college when I had to explain high level different data structures. That was actually important since we were writing cross platform, C that had to be highly optimized.
I’ve gone on lots of interviews with only two rejections - the rest I took my name out of the running once I got the job.
I came up as a traditional computer geek - learned how to program in Basic and assembly on an Apple //e in middle school, fell in love with C, spent way too much time on comp.lang.* groups etc.
One of my best friends who I worked with across three jobs graduated from one of those infamous for profit schools, for years wouldn’t know an algorithm if it hit him in the face, but spent a lot of time on side projects, reading best practices from books, etc. and is one of the best architects I know.
That said, for algorithms (e.g. sorts, etc), understanding what the options are and trade-offs is certainly more useful than knowing how to implement them, since there's a good chance someone has implemented it already in your language of choice.
My brother worked in a company that was doing circuit board design (simulating crosstalk, etc). Their work was highly theoretical, but they had electrical engineers doing the research (and were actively collaborating with a university). His job was 99% implementing code.
I feel that programming is more about handling complexity than it is about solving other problems. You sometimes dip your toes into solving problems in other domains, but the biggest value you can give as a programmer is in creating a code base that is both simple and sustainable (and keeping it that way). This is the hardest problem I've ever worked on by far. It dwarfs any of the other problems I've tried to solve. I sometimes get a bit depressed that others don't consider it a "hard" (and therefore interesting) problem.
The most complex thing I have heard of is someone who wrote a kalman filter thing for some part of a nuclear reactor. To me it seemed hard since I don't understand the math, and apparently people around him was happy with his solution.
Also here in Sweden I don't think the CS algorithms are very important at all when getting a job. I have just not seen it that much, which is sane since nobody seems to really need it anyway...
I had to implement a quadtree from the ground up, because existing solutions didn't work, when working as an SAP consultant on some dashboarding tool (I also had to know what a quadtree was!)
I now work in a generic unsexy role doing release engineering. About half my job is generic software engineering, but the other half is comparatively academic. I was reading academic papers on Aho-Corasick derivatives last week and writing statistical tests in jupyter notebooks this week.
And my interview questions are generally inspired by problems I've had in my work, just normally somewhat simplified since the way I phrase them justifies the need for a specific class of solution much more clearly than whatever nonsense I encountered in the first place.
I'll see your twenty and raise to 38 on the same basis. In fact no one I know has ever had to solve the algorithm problems that seem so common now (in the US at least). The nearest I came to it was in a previous career as an electronics engineer where the interviewer gave me the circuit for a simple common emitter amplifier and asked me to describe it's characteristics. He was very apologetic afterwards and said that experience had taught him that recently qualified electronics graduates often had so little practical experience that he could not afford to employ them as it took them too long to get up to speed; so he used this simple test, and it was very simple, to sort out those who could be gently shown the door immediately to avoid wasting his and their time.
I had a three year earn out, finished that and decided to get back into the workforce and get a job at a senior or above level (thinking Director, Manager, etc). Guess what, not only did my age hinder me (I'm 53), but my lack of CS math background seemed too in an interview process. Various interviews had me solving what I consider not only impractical, but almost silly puzzles / math problems that not only didn't apply to the company I was interviewing with, but didn't apply to anything real-world -- it felt like it was a way to:
- Weed me out because of my age - Make the company seem like their vetting process was "Google like" and "trendy" - Make the interviewer feel entitled or the company be "elite" in their process
Part of me realizes that some of this is to see how well someone problem solves. I get that. However, I had one interviewee actually bungle up the questions, in fact, I had to point out at one point that it appeared that they described the problem wrong. When I got my answer wrong, and then asked for the answer, the interviewee clearly realized he setup the whole problem incorrectly.
Oddly enough, this is the part that bothers me the most. I've been asked many times for my GitHub. I have lots of solid examples to see my work. I've also been asked to do a programming challenge, which almost always I nail 100%. But it's always these "trap" CS challenges that I feel are used to eliminate someone based on either HOW they solve it or a way to justify them out and not hire them based on other factors (age, fit, etc.)
I actually had one that was a whiteboard session where the CTO asked me to solve the problem on the board "using code of your choice", so I stated, "Look, since I know multiple languages, I'll use pseudo code to walk through the problem and explain the answer"
When he described what he wanted me to solve (badly I might add), I wrote the pseudo-code on the board and described the problem as being solved by using regression. Which was 100% the right answer but because I chose to use pseudo-code not say, Python or JavaScript -- he told the recruiter, "he couldn't solve the problem I was looking for him to solve." When pressed by the recruiter about the solution, he gave a link to the problem in his Github, which of course was verbatim of what I described but in Python -- using regression.
What I've learned from this is that I should contract and consult. Most of these smaller companies want what they want in the way of an employee and are seeking the 10X developer, culture fit and someone in their own age group...
If you deviate from the rather arbitrary requirements you will be considered a no-hire.
Other industries have a formal study, exam, and professional certification process. Developers don't. [1]
In the absence of that, these interview play-throughs are treated as an ad hoc substitute. They're a passable fit for generic ass-in-chair juniors, but a very poor fit for anyone looking for good seniors or a CTO.
[1] In the UK you can become a Chartered Engineer via the British Computer Society. I don't think there's anything equivalent in the US, and I'm not sure how many shops in SV even recognise Chartered Engineer as a professional qualification.
Recently I joked with the interviewers over Skype screen sharing that I probably wouldn’t be fast enough to get a pair programming exercise done with 3 of them watching me. And that often these things you either see right away or struggle with. They all laughed and agreed.
I wanted to test a particular function after setting everything up, installing jest etc. But was told not to because deconstructing xpath was an implementation detail. No one could see what was wrong with my working and all three of them said it’s the way of working and not if you happen to get the answer on the day.
Of course they failed me saying I was too weak at programming. I won’t be doing coding over Skype screen sharing again and with more than one person in the room, it’s just too stressful and random.
So yeah, I've focused on the executive level, CTO, VP, etc, But with that, you have to either give up coding and just manage or go to a tiny company to be the "key player", but then you're typically at a smallish company with little to no funding. I've been doing that lately, I'm at a small start up running engineering, but I'm an "employee", not a founder.
There seems to be a clear bias with VC companies against someone my age and background. Not to say I don't have a network I could probably work and get funding, I could. But I also wanted to get back to square one and work with people again and NOT have to deal with things like Healthcare, stock options and "hey, that person needs a week off because their cats sick." -- I'd rather just CODE and learn more, enjoy the art of buildings things without the pressure of an investor looming over you.
I've made enough money to be comfortable, but I still need to earn a living -- I haven't made that "FU" money and my wife laughs and jokes that for as much success we've had, even if I did get the "FU" money, I'd still want to work 70 hours a week and write code... ;-)
About your Skype coding comment. Yeah, new trend is to "pair" with someone online in an interview process and go through programming challenges. I'm OK with that, but I don't work well that way. I work better in a situation where I can think and spend the time myself on the problem. My brain isn't wired for "fast and rapid", it's more of a "trial and error" until I get it working, then later on optimize and make it better. I do terrible at that first pass, always been more of an interactive developer who starts with something that works and then over time perfects it. That style SUCKS on a pair programming exercise.
The crap I was asked was pretty insane to be honest.
