14 ms·

“But didn't you write an embedded OS?”

255 points by jimmies 8y ago

humanrebar 8y ago
> And I see the same trend in Machine learning, Big data, AI, Cryptocurrency, Internet of Things, Social networks, Decentralized networks, etc. Everything in life, however trivial or hard, is a nail that can be solved with those fancy hammers. So we can have a tablet juxtaposed on a fridge, a bluetooth speaker integrated to a salt shaker, a subscription model for juicers, and machine learning for all kinds of social problems. I'm frustrated by this as well. I see these days, especially, junior engineers excited about machine learning analyzing data sets that could be tackled easily with learning the problem space and excel or a jupyter notebook. 90% of the work in analysis problem is, usually, identifying data sources and possibly curating the records to a workable data set. So it really doesn't help much to apply ML off the bat. If normal regression and human inspection don't help, maybe then you can iterate on the problem and try some ML approaches. So why are junior engineers trained to think this way? Are their professors and guest lecturers excited about these approaches and teaching the students about their favorite hammers?
- ghostcluster 8y ago
  I'm not so sure when it comes to machine learning. Those techniquss represent such a fundamentally different approach to pattern recognition that it enables the tackling of whole classes of problems that couldn't previously be sufficiently automated with hand-coded heuristics and straightforward statistics.
  - johannes1234321 8y ago
    True. But many many many problems can be solved without that hammer as well.
  - omginternets 8y ago
    This is undeniably true, but consider that 99% of classification problems encountered in the industry can be solved with a logistic (if not linear) regression.
  - gaius 8y ago
    Those techniquss represent such a fundamentally different approach to pattern recognition You are kidding right? With the exception of a few modern breakthroughs like GAN the vast majority of ML is 70s and 80s ideas that Moore’s Law has just taken mainstream.
    - omginternets 8y ago
      The fact that these approaches are now tractable represents a paradigm-shift in what we can do with computers. That's what the parent-poster meant.
    - ghostcluster 8y ago
      70s and 80s ideas that couldn't be implemented at scale due to the lack of massively parallelized GPU architectures with trillions of transistors to simulate the neurel net layers. It was only in the mid-late 90s that simple handwriting / character recognition techniques were able to be used in somewhat real-time.
    - sanxiyn 8y ago
      > With the exception of a few modern breakthroughs like GAN And ReLU (2011). And Glorot initialzation (2010). And He initialization (2015). And Dropout (2014). And Batch Normalization (2015). And Adam optimizer (2014). And distillation (2015). And... None of these were known or used in 70s and 80s and performance difference is enormous.
- pjmlp 8y ago
  The biggest issue is that it is only part of the problem, the other side is that it also infects HR requirements and now everyone needs to be a highly skilled motived engineered with 5+ years experience and several deployed applications to go through the HR filter and interviews driven by those junior engineers.
- qntty 8y ago
  So they can put on their resume that they have experience with machine learning? I don't have any shame about overdoing things when I think it will improve my resume.
- reaperducer 8y ago
  >I see these days, especially, junior engineers excited about machine learning analyzing data sets that could be tackled easily with learning the problem space and excel or a jupyter notebook. Ditto. I watched the entire Google I/O Stevenote, and was surprised how many of the "problems" it's tackling with "AI" have already been solved by other, simpler solutions. To be sure, there were some impressive moments. But much of it was reinventing the wheel with an AI spin.
- currymj 8y ago
  they want to get well-paid, high prestige jobs using machine learning. whereas doing the exact same task with a regression in Excel turns it into low-prestige clerical work. i think they’re acting pretty rationally once you consider their own incentives. (plus of course, the general cultural perception that machine learning is cool, smart, and cutting edge must rub off on them too and how they perceive themselves.)
  - humanrebar 8y ago
    > i think they’re acting pretty rationally once you consider their own incentives Is that even true? Or are candidates and companies just caught up in a cycle of signaling? In my experience, there is amazing demand for pretty straightforward software engineering, and the talented leaders there are coveted and paid very well. Analytics, ML, etc. are desired as well, but are a minority portion of the demand.
    - HumanDrivenDev 8y ago
      If you're in a '2nd tier' first world country like Canada, Australia, the UK, Germany etc, Machine Leanring is one of the only ways you can get a salary comparable to a 'normal' Software Dev in the US. Keep that in mind.
      - kamikaz1k 8y ago
        Which countries are first tier?
        HumanDrivenDev 8y ago
        Not many, Switzerland and Norway are all that come to mind. The real point I am trying to get across is the huge gulf between the career of a US software engineer vs almost anywhere else in the world.
  - goatlover 8y ago
    I thought the well-paid, high prestige jobs required a Phd in the field? Or has machine learning become widespread enough for the unwashed programming masses?
- trisimix 8y ago
  As a student in CS I see myself falling for this simply because other hammers have learning curves.
- nerdponx 8y ago
  It's an inverted approach to problem-solving that is fine for side projects and self study but inappropriate for getting things done. I suspect part of the problem is that people don't really have enough time for self study, so they, consciously or subconsciously, start finding excuses to inject their interests into their work. I know I am guilty of having done this in the past.
- SlowRobotAhead 8y ago
  Definitely applies to all of that and blockchain if you want to separate that from cryptocurrency. “We know what it is - just not what it’s for... yet”
  - netsharc 8y ago
    The other day I read about a company wanting to prevent ticket touting by using... blockchains. Erm, what... the... fuck? The hype around cryptocurrencies is that you can use it without trusting a single entity (a central bank). Only 1 entity determines whether an event ticket is worth anything or not, and that's the ticket checker at the gate. Why the eff would you need blockchain for this? But anyway, the startup probably got some millions of dollars, they're probably smart because they can see how stupid investors are...
    - SlowRobotAhead 8y ago
      I’ve just been replacing blockchain when reading with “mathy database” and yea a lot of context doesn’t hold up.
- staticassertion 8y ago
  Because technology is more than practical, it's also cool.
- bassman9000 8y ago
  So why are junior engineers trained to think this way? For us, it can be a competitive advantage, as thousands of engineers dismiss more traditional techniques in favor of sub-optimal, but fancier ones. And, a few years from now, it will be another powerful tool, as the The Next Big Thing takes over.
  - TeMPOraL 8y ago
    As long as we find other ways to get through HR filters.
- kriro 8y ago
  I'll play devils advocate and disagree. I'll claim that deep learning is the greatest hammer I have seen in my lifetime and it can tackle all nails you throw at it (universal approximation theorem). Additionally it is easy to apply and get very reasonable results. At least for me it's easier to whip up a Jupyter Notebook and use some basic heuristics and a library like fastai than to struggle through Excel. Assuming that the data is available and curated (I'd argue this is a hard and very value creating task).
- mwfunk 8y ago
  I think these are just the normal hype cycles for new technologies. Some technology (maybe new, maybe not) captures the imagination of the industry, and there's a flurry of mostly silly activity where people are trying to figure out what else that technology can be used for. It feels like there's low hanging fruit waiting to be plucked, but no one knows what's actually going to stick. Eventually the hype dies down as a consensus forms on what it is and isn't good for. From a money perspective, there's also a gold rush mentality. VCs are going to be drawn to these sorts of things, even knowing that 99% of it will turn out to be a square peg in a round hole, because somewhere in there, there might be a unicorn. People seeking investment from VCs might also promote the buzzword of the day for their own marketing purposes (to investors, the public, and the press).
  - reaperducer 8y ago
    >I think these are just the normal hype cycles for new technologies. You're not wrong. Remember in the late 90's when everything was all i-this, and cyber-that? Everything was going to be on "the interweb!" Those big mainframes of yesteryear? We don't need them anymore. We have AOL and thin clients! Back in the 80's: We don't need rockets anymore, we have space shuttles! In the 70's: Who needs stereo? We have quadraphonic sound now! Look at old mainstream magazines from the 1950's. EVERYTHING was going to be solved by being "atomic." Too busy to cook dinner? Let your atomic kitchen do the work for you! Spilled coffee on your tie? Let an atomic washer make it clean for you! Little Johnny put in the dunce corner again? Slap an atomic Think-o-Tron on his head and let radiation smarten him up! I'm sure there are a brazillion other/better examples. Feel free to add yours.
- scottLobster 8y ago
  It's Anecdata, but when I was coming up through my Computer Engineering program a few years ago there were roughly three categories of students: 1. The Traditionalists: Students who are fascinated by the technology and what it can do at its limits. These people are disproportionately drawn towards the more arcane/unsexy applications (RF, hardware, high-power, radars, antenna design, IC design, embedded systems, robots, rockets, quantum computing, etc) and research. 2. The New Wave: Students who were inspired by a Steve Jobs keynote, these people were almost exclusively interested in potentially mass-market user-facing applications and have a greater emphasis on image (both personal and professional). 3. The Unmotivated: People who are there "because it pays well" and for no other reason. Not many of them made it to graduation, and the ones that did were "meh" engineers at best. Most of the naive junior engineers you're seeing probably belong to the modern incarnation of category 2. Steve Jobs has been dead long enough for new grads to have been inspired by the next generation of buzzwords. They're fine engineers in general, but they have a sometimes unhealthy fixation on said buzzwords and how "future" they are, because that's what got them into engineering. Most will concede when a simpler solution is presented, but it's uncomfortable for them. Unsexy but effective techniques undermine their aesthetic impulses and, to a degree, their self-image as engineers. A good popular example is Elon Musk refusing to use LIDAR on Teslas, and introducing way too much automation, too fast at Tesla's factory. People, even junior engineers who think they're part of a "ground-breaking" movement often have trouble separating "obsolete" from "tried-and-true".
  - palisade 8y ago
    4. The Savant: Also known as the absent minded professor. You could throw questions at this person in an interview and they will seem completely inadequate and unprepared. But, then apply them to a problem on the job and like a juggernaut they will defeat any obstacle. They will even solve problems your best engineers have been struggling with for years without breaking a sweat. A lot of companies make the mistake of weeding this type of engineer out in the interview process.
    - abhishekjha 8y ago
      I may qualify in this category. Companies reject me because I gave them a brute force solution for finding repeated values in an array. But there hasn't been any single instance with my current job that I couldn't check all of the requirements that were assigned to me, even those which I thought I wasn't prepared for. The hiring/evaluating process needs to get refined.
bluedino 8y ago
How’s the old interview question go? Using the programming language of your choice, sort the strings in this file and remove duplicates. You have 30 minutes. sort foo | uniq
- NullPrefix 8y ago
  Clearly a suboptimal solution. That pipe isn't free. /s sort -u foo
  - my123 8y ago
    Seems to be too little UNIXy. Modern tools sometimes not only do one job. (the z flag might have been kept out of tar too for example) :P
  - emilfihlman 8y ago
    With piping you can leverage multiprocessing for free. Using sort -u alone might actually not be as fast as sort | uniq -u.
- viraptor 8y ago
  If you're using gnu coreutils: sort -u foo.
- amelius 8y ago
  And what if the strings are separated by spaces instead of newlines?
  - flerchin 8y ago
    sed foo -e 's/ /\n/g' | sort | uniq
    - amelius 8y ago
      Yeah, but what if the strings I wanted to sort contain newlines?
bsenftner 8y ago
For those of us who have written an embedded OS in C, the situation is no different. The white board questions are crap like "How is React different from other JS frameworks?" Whaaaaat?
- bartread 8y ago
  To me those sorts of questions are terrible interview questions. I'm looking for a few things when I hire: - What are you like as a human being? Can we work together? - Can you code? [1] - Are you willing, in fact keen, and able to learn? - Can you see beyond the technical issues? [1] This tends to be frowned on in some circles, but given the bi-modal distribution of developer skill, leading to plenty of smart people who aren't good programmers, in my view it's of critical importance. Generally asking somebody to solve a relatively simple problem in a language they're comfortable with and that is also similar to something we use, or pairing together on a problem, works well here. What I don't care about is understanding of specific frameworks or technologies: if you're a good dev you can learn those, and we're happy to invest and give you the time to do so.
  - justherefortart 8y ago
    I just ask them to talk about the projects they've worked on recently and any issues that arose, and how they dealt with them. If they can communicate clearly what happened. I've never had that fail me as far as them being "technical enough" for the position as no one knows everything, can you figure it out is the bigger issue. Then I typically just have them tell me about what they liked and disliked at prior jobs and what environment they would like to work in. After that, what are their goals for their career and how can we help them achieve them. If the interviewee can demonstrate they have anything in those areas, I've never had an issue with someone I've hired. I don't care if you can program everything walking in the door. If you've got a can-do attitude, we can work together to get you up to speed on our crap code and the whys behind it.
- stmw 8y ago
  Right, seems the real issue here is that HR/recruiting misrouted the OP's resume, or perhaps the interviewer did not read it carefully, resulting in a negative experience for both. The real issue is that more senior engineers and managers need to be involved in earlier parts of the hiring process.
_Donny 8y ago
I understand that the article is about how many developers are inclined to use wrong "hammers" for certain tasks. However, it also makes me think about how we actually code. At my university, we learn to sort files, parse data-structures, model various data formats, etc. But in most UNIX systems, we already have the basic building blocks in the form of simple programs that do one thing, very well. Will programming ever evolve from programming languages to more complex building blocks in the form of programs combined with pipes in the bash terminal?
- goatlover 8y ago
  Well, some programming languages encourage that kind of design by emphasizing message passing. You even get piping between functions in languages like Elixir.
- int0x80 8y ago
  Microservices? No bash though
- TeMPOraL 8y ago
  > Will programming ever evolve from programming languages to more complex building blocks in the form of programs combined with pipes in the bash terminal? Fundamentally, UNIX "programs combined with pipes" are equivalent to function calls. sort foo | uniq is equivalent to uniq(sort(foo)); Shell is nothing but a programming language/environment optimized for fast input and immediate, stateful execution. If you seek evolution of programming to higher levels of abstraction, this isn't the place. Command line interfaces work at the same abstraction level as regular programming in a high-level language.
- xboxnolifes 8y ago
  > Will programming ever evolve from programming languages to more complex building blocks in the form of programs combined with pipes in the bash terminal? 1) A bash script or 2) Those are called libraries.
zdw 8y ago
Reminds me of this article, which recounts a book by Knuth where the reviewer comes up with an 6 command shell pipeline equivalent to one of the multi-page examples: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...
- blackbrokkoli 8y ago
  That was a good read, thanks
- samatman 8y ago
  That exchange never sat right with me. I feel, and I hope Dr. Knuth would agree, that literate programming is a good choice for writing `uniq`, that the problem domain was chosen for didactic reasons. In effect, he chose to show off parts of several programs, rather than finishing one. The intention was to teach. That shell script was a tour de force at the time, showing off the Unix Way of small, sharp, composable tools. What Dr. Knuth was (and is) saying: write those small, sharp tools in a literate manner. A real missed opportunity.
  - svat 8y ago
    Indeed, yes exactly. And in fact, later Knuth wrote `wc` (one of the shell programs in the pipeline) as a literate program, and showed that it was better as a result than the one that came with Unix.
mmjaa 8y ago
I think that whats missing in this assessment of HR these days, is that interviews are just as much an opportunity for the prospective employee to evaluate their potential new employer, as it is the other way around - only, we're seriously NOT used to thinking in these kinds of terms. I've been programming since the 70's, and have built systems and subsystems that are still up and running around the world. If you logged onto an ISP in the 90's and early 00's, chances are you were going through a code-path that I was responsible for .. if you took a train in any one of 38 different countries in the world, in the last 15 years, chances are your life is being protected by code for which I was once responsible. I've done a lot of crazy shit; I've done a lot of cool stuff... I say this only to indicate that I'm no newbie when it comes to software systems engineering, and all it entails: I've shipped to tens of millions of people, and I've shipped to a small, localised group. Point is, I've shipped, yo. A few years ago I went to a job interview at a local game development company, since I have a high interest in game engines and have even built a few of them myself, as well as published a few games over the years. I thought the interview was going well, and at first I hit it off just great with the guys doing the interview .. but then as they started pulling in more and more other engineers to meet and greet, and ask questions, I started to get a feel that I really didn't want to work at this place. Mid-interview, I felt like I should just stand up, say "sorry guys, you're not a good fit for me", and left... but instead I decided to sit through the interview. This was a big mistake - they came with the inevitable whiteboard questions, and so on. So, I flunked them all - not because I couldn't work out the A* algorithm on the board, but because I really lost interest mid-interview. It was only a day or so afterwards, having a bit of retrospective rumination time, that I realised that I just really didn't want to work with those guys. They rubbed me up the wrong way, and there was just something about their culture that I didn't feel for .. well, I should've just said something. I should've said "well, you guys have a great company (it seems), but I'm seeing all sorts of warning signs in this interview, so I think I'll just pass on this opportunity - and thanks!". But instead, I stuck around and ended up just degrading myself with stupid responses to their requests. I didn't really feel like I was in power, or had any control - but honestly, I did. I really could have just stood up and said "well, that last guy you brought in was a bit of a wanker, and I don't want to work in an environment of wankers, so thanks for the opportunity but no thanks".. I think this is a real cultural dilemma. We, builders of technology, should really acknowledge our value, and place it a lot higher than the current HR-infected job market implies. Its a double-edged sword of course - nobody wants to be known as the guy who shits on this interview companies - but on the other hand, why do we put up with such imbalance? EDIT: Just wanted to add that this particular line of the article resonated with me: 'He asked, "But didn't you write an embedded OS?".'. That, right there, is a sign that the interviewer has a very, very poor understanding of the subject, and the talent should just get up and leave. I wonder how many of us overlook this fact in our interviews, out of desperation?
a1369209993 8y ago
> "I can do it in two commands chained by a pipe in bash." > any programming language I like I choose Bash.
- paulddraper 8y ago
  Probably depends on what the "commands" are. You could also do it with two Node.js functions (from npm packages). The presumption is that the available library is limited, though exactly how limited depends on the interviewer. Plenty of times I've chosen a language because of a particular function in its standard library, only to be told that function can't be used.
twblalock 8y ago
In defense of the interviewer, if somebody told me they wrote an OS for the Raspberry Pi I would assume they wrote it mostly in C, not mostly in Bash.
- aw3c2 8y ago
  > I made an distro for the Raspberry Pi called Crankshaft Someone who picks up that info and turns it into interview material should be well aware about the difference between making a distribution and writing an OS!
  - PrimHelios 8y ago
    Not to mention that since the interviewer now has a name for said distro, they should have looked it up and found what language it was written in.
- jimmies 8y ago
  No that's the problem. I said I did not write this to bash the interviewer and I really meant it. The idea here is that to achieve something quite useful like a distro ("made an OS") for the Raspberry Pi, the important part is to figure out a problem that needs solving and a tool to solve it. A person who made something cool might be actually quite dumb, and that's alright. A good answer is something that foremost solves a problem. A bad answer is a fancy technology that doesn't do it better. Here I sucked at my Go solution and I deserved to fail. But here it's just a lame fail because my initial solution worked and the rule changed to accommodate the fact that it was not the technology he expected.
daixtr 8y ago
So I said, iL call the snmp API to read the data. Then he said, "no, you need to read the bin file to read the data". I thought, what an idiot he is. I lost respect, lost faith. Little knowledge is a dangerous thing.
im_down_w_otp 8y ago
Given how much of software development itself is often little more than cargo culting w/ strong doses of guess & check stirred in, I suppose it makes sense that hiring/interview practices would mirror that, but it's still depressing everytime I come across stories like this one. It doesn't have to be like this. I don't hire people this way because I've never seen it produce good results, and I have to hire esoteric skillsets for a challenging problem, and without the time or budget that will forgive making bad hires.
rambossa 8y ago
I hate the Cracking the Coding Interview/Leetcode style... studying for these type of interviews is annoying. Trying to find a good video on youtube, where they aren't just naively coding up the bruteForce->optimal possible solutions, especially is irritating. It is literally a landscape of college kids with thousands of viewers who treat these interviews like a standardized test (SAT, GMAT). Even the author of the book produces videos with very little insight or meaningful content. "Find all the subsets in a set that add up to sum" -- "Okay for this we will use the sliding window technique and here is how it is done" -- WTF is this. I get that they want to see problem-solving skills, but this is on a different level requiring the interviewee to have studied and knowledge of the technique, otherwise we are basically trying to develop efficient algorithms from scratch and in little time. --This makes sense for college interviewees who have only studied the past 4 years, but for a professional with experience, why is this adequate?? Does algorithmic programming matter?-- still yes. But the way it is interviewed is absurd and inadequate. I had a production service centered around the stable-roommate-problem. It took me a week or two (mostly research) to develop something out and fit it into our codebase. It then took 1-3 more weeks to actually make it work for us and cover edge cases (i.e. Irving's algo quits after instability -- this isnt an option in the real-world). I read much material on the subject, other's code, had many deep-thinking sessions where I was mostly in my head, wrote unreadable scratch on paper, collab-whiteboarded (sometimes arguing), tested&failed PoCs, and had many breaks in-between it all. How successful was that project?--very, did I need to know and study techniques with lacking/meaningless basis to do it--no.
- zawerf 8y ago
  Recall when you first learned how to program. Something as trivial as iterating through a list requires some thought. What is the syntax for a "for" loop? Do you start with i = 0 or i = 1? Should you end at i < n or i <= n? At some point you stop thinking about it and write "for (int i = 0; i < n; i++)" instinctively. You can now solve harder problems that require iterating through a list without thinking about it. All of algorithms and programming is like this. You unlock harder problems as you learn more problem solving building blocks (whether it's an algorithm, a software design pattern, or some API call). A programmer is someone who can learn these on the fly for any problem of any domain. An effective programmer is someone who has a large cache preloaded with these building blocks already. In that sense I find leetcode style problems to be very fair. They are meant to be solvable in under an hour without thinking once cached into muscle memory. All it is testing is whether you're capable of becoming an effective programmer in some agnostic domain. All you need to do is warm your cache with a small number of standard patterns (which might even be useful for real work). It does suck that even the good programmers need a few weeks to warm their cache. But it weeds out the fakers who can't do it given any amount of time.
jknoepfler 8y ago
I'm honestly tired of programmers complaining about interviews. I don't think the whiteboard blitz is a good gauge of an employee, either, but I don't know of any good "test" of a potential coworker other than working with them. One thing I think people wildly underestimate is how aware the interviewer is of the inadequacies of parts of the process. I will ask basic programming questions for the same reason I write unit tests. Weed out obviously broken candidates with really easy questions. But beyond that, I need people with common sense and a strong sense of professional ownership. I need engineers with spines. I need people who tell me what they think needs to be done, not people who are going to sit in their cubical complaining about how crappy the interview process is. I need people who learn quickly, not people who will be paralyzed by code smell or new tech. I need people who can jump into management roles to fill in gaps because they get how things work and want the team to get shit done. If you don't like the process, fix it yourself on your team. Do better. Teach others. Believe it or not, lots of people have gone down the same rabbit hole, and your "crappy interviewer" is likely one of them.
- scarface74 8y ago
  I'm honestly tired of programmers complaining about interviews. I don't think the whiteboard blitz is a good gauge of an employee, either, but I don't know of any good "test" of a potential coworker other than working with them That's the answer - "you work with them". I create a simple version of a real world class that we have worked on. Each method has comments on what the code is suppose to do and a bunch of failing unit tests and we pair program. The first set of unit tests are relatively easy. I then add a second set of requirements with a second set of unit tests. They have to modify the code to pass the 2nd set of unit tests without breaking the first. But as far as "going down the rabbit hole", I've never gone down that rabbit hole of algorithm type tests. I was drilled on C in an interview in 1999 because they were doing a lot of hard core C work (I stayed on that job until 2008). But since then, most of my interviews have either consisted of the sitting down at a computer and solving problems type or just drawing on the board and explaining architecture. Even though I'm very much hands on, at this point most companies hire me more to help them with architectural issues than just as another coder. My salary requirements filter the just another developer type roles out. No, I'm not bragging about how much I make. I'm still only making the median for a senior software Engineer/architect for my market - if the salary surveys and my anecdotal experience is accurate.
HumanDrivenDev 8y ago
> If his tech model turns out to be relatively successful, a medium-sized company in tech will be able to easily copy his model and out-compete him Does this happen all the time and we don't realise it due to survivorship bias? And if so, how do we account for the successful stories that started from the bottom up and became medium-sized companies themselves?
lucio 8y ago
>I don't intend to write this post to bash the interviewer pun, intended?
103e 8y ago
"Invert a binary tree on a whiteboard" I wonder if you get any points for turning the board upside down.
jernfrost 8y ago
Sitting on the other side of an interview, I was so annoyed with the guy I was doing the interview with because he insisted on these algorithm challenges. I told him these tasks are bullshit, because the job we do doesn't involve coding algorithms EVER. I wanted to focus on the ability to read messed up code and figure out what it roughly does and how to improve it. Turned out we were both kind of wrong, although I would claim my co-worker was way more wrong than me. Our candidates pretty much failed all these algorithm questions. And when my co-worker tried to help it turned out that he didn't have a proper grasp of the problems we presented either. My reading code test didn't work very well either, because these test subjects were fresh out of college and had little experience in reading larger code bases, refactoring and dealing with software engineering problems. Like most people in college they had mostly dealt with toy sized programs. So in the end what proved the best guide was plain old boring interview questions. Our interview was largely a failure but we hired the programmer on a hunch anyway based on her explanation of some theoretical subjects. It turned out that she worked out just fine despite failing pretty much all the tests we had made. That is because a lot of development these days is more about persistence, motivation and ability to google. She was practical, eager to find solutions and eager to google and that made her get stuff done.
- bsder 8y ago
  > That is because a lot of development these days is more about persistence This is true of most technical endeavors ...
andrewstuart 8y ago
The only sound recruiting advice is Joel's, which remains true today: Hire people who are smart and get things done. The interview questions to determine that go something like: "List out your top achievements in programming" "Explain each of them to us in as much detail as you possibly can" I'd look for enthusiasm for this particular job too, assuming they have had time to fully understand it and give it some thought.
deleted 8y ago
[deleted]

255 points by jimmies 8y ago

> And I see the same trend in Machine learning, Big data, AI, Cryptocurrency, Internet of Things, Social networks, Decentralized networks, etc. Everything in life, however trivial or hard, is a nail that can be solved with those fancy hammers. So we can have a tablet juxtaposed on a fridge, a bluetooth speaker integrated to a salt shaker, a subscription model for juicers, and machine learning for all kinds of social problems. I'm frustrated by this as well. I see these days, especially, junior engineers excited about machine learning analyzing data sets that could be tackled easily with learning the problem space and excel or a jupyter notebook. 90% of the work in analysis problem is, usually, identifying data sources and possibly curating the records to a workable data set. So it really doesn't help much to apply ML off the bat. If normal regression and human inspection don't help, maybe then you can iterate on the problem and try some ML approaches. So why are junior engineers trained to think this way? Are their professors and guest lecturers excited about these approaches and teaching the students about their favorite hammers?

ghostcluster 8y ago
I'm not so sure when it comes to machine learning. Those techniquss represent such a fundamentally different approach to pattern recognition that it enables the tackling of whole classes of problems that couldn't previously be sufficiently automated with hand-coded heuristics and straightforward statistics.
- johannes1234321 8y ago
  True. But many many many problems can be solved without that hammer as well.
- omginternets 8y ago
  This is undeniably true, but consider that 99% of classification problems encountered in the industry can be solved with a logistic (if not linear) regression.
- gaius 8y ago
  Those techniquss represent such a fundamentally different approach to pattern recognition You are kidding right? With the exception of a few modern breakthroughs like GAN the vast majority of ML is 70s and 80s ideas that Moore’s Law has just taken mainstream.
  - omginternets 8y ago
    The fact that these approaches are now tractable represents a paradigm-shift in what we can do with computers. That's what the parent-poster meant.
  - ghostcluster 8y ago
    70s and 80s ideas that couldn't be implemented at scale due to the lack of massively parallelized GPU architectures with trillions of transistors to simulate the neurel net layers. It was only in the mid-late 90s that simple handwriting / character recognition techniques were able to be used in somewhat real-time.
  - sanxiyn 8y ago
    > With the exception of a few modern breakthroughs like GAN And ReLU (2011). And Glorot initialzation (2010). And He initialization (2015). And Dropout (2014). And Batch Normalization (2015). And Adam optimizer (2014). And distillation (2015). And... None of these were known or used in 70s and 80s and performance difference is enormous.
pjmlp 8y ago
The biggest issue is that it is only part of the problem, the other side is that it also infects HR requirements and now everyone needs to be a highly skilled motived engineered with 5+ years experience and several deployed applications to go through the HR filter and interviews driven by those junior engineers.
qntty 8y ago
So they can put on their resume that they have experience with machine learning? I don't have any shame about overdoing things when I think it will improve my resume.
reaperducer 8y ago
>I see these days, especially, junior engineers excited about machine learning analyzing data sets that could be tackled easily with learning the problem space and excel or a jupyter notebook. Ditto. I watched the entire Google I/O Stevenote, and was surprised how many of the "problems" it's tackling with "AI" have already been solved by other, simpler solutions. To be sure, there were some impressive moments. But much of it was reinventing the wheel with an AI spin.
currymj 8y ago
they want to get well-paid, high prestige jobs using machine learning. whereas doing the exact same task with a regression in Excel turns it into low-prestige clerical work. i think they’re acting pretty rationally once you consider their own incentives. (plus of course, the general cultural perception that machine learning is cool, smart, and cutting edge must rub off on them too and how they perceive themselves.)
- humanrebar 8y ago
  > i think they’re acting pretty rationally once you consider their own incentives Is that even true? Or are candidates and companies just caught up in a cycle of signaling? In my experience, there is amazing demand for pretty straightforward software engineering, and the talented leaders there are coveted and paid very well. Analytics, ML, etc. are desired as well, but are a minority portion of the demand.
  - HumanDrivenDev 8y ago
    If you're in a '2nd tier' first world country like Canada, Australia, the UK, Germany etc, Machine Leanring is one of the only ways you can get a salary comparable to a 'normal' Software Dev in the US. Keep that in mind.
    - kamikaz1k 8y ago
      Which countries are first tier?
      - HumanDrivenDev 8y ago
        Not many, Switzerland and Norway are all that come to mind. The real point I am trying to get across is the huge gulf between the career of a US software engineer vs almost anywhere else in the world.
- goatlover 8y ago
  I thought the well-paid, high prestige jobs required a Phd in the field? Or has machine learning become widespread enough for the unwashed programming masses?
trisimix 8y ago
As a student in CS I see myself falling for this simply because other hammers have learning curves.
nerdponx 8y ago
It's an inverted approach to problem-solving that is fine for side projects and self study but inappropriate for getting things done. I suspect part of the problem is that people don't really have enough time for self study, so they, consciously or subconsciously, start finding excuses to inject their interests into their work. I know I am guilty of having done this in the past.
SlowRobotAhead 8y ago
Definitely applies to all of that and blockchain if you want to separate that from cryptocurrency. “We know what it is - just not what it’s for... yet”
- netsharc 8y ago
  The other day I read about a company wanting to prevent ticket touting by using... blockchains. Erm, what... the... fuck? The hype around cryptocurrencies is that you can use it without trusting a single entity (a central bank). Only 1 entity determines whether an event ticket is worth anything or not, and that's the ticket checker at the gate. Why the eff would you need blockchain for this? But anyway, the startup probably got some millions of dollars, they're probably smart because they can see how stupid investors are...
  - SlowRobotAhead 8y ago
    I’ve just been replacing blockchain when reading with “mathy database” and yea a lot of context doesn’t hold up.
staticassertion 8y ago
Because technology is more than practical, it's also cool.
bassman9000 8y ago
So why are junior engineers trained to think this way? For us, it can be a competitive advantage, as thousands of engineers dismiss more traditional techniques in favor of sub-optimal, but fancier ones. And, a few years from now, it will be another powerful tool, as the The Next Big Thing takes over.
- TeMPOraL 8y ago
  As long as we find other ways to get through HR filters.
kriro 8y ago
I'll play devils advocate and disagree. I'll claim that deep learning is the greatest hammer I have seen in my lifetime and it can tackle all nails you throw at it (universal approximation theorem). Additionally it is easy to apply and get very reasonable results. At least for me it's easier to whip up a Jupyter Notebook and use some basic heuristics and a library like fastai than to struggle through Excel. Assuming that the data is available and curated (I'd argue this is a hard and very value creating task).
mwfunk 8y ago
I think these are just the normal hype cycles for new technologies. Some technology (maybe new, maybe not) captures the imagination of the industry, and there's a flurry of mostly silly activity where people are trying to figure out what else that technology can be used for. It feels like there's low hanging fruit waiting to be plucked, but no one knows what's actually going to stick. Eventually the hype dies down as a consensus forms on what it is and isn't good for. From a money perspective, there's also a gold rush mentality. VCs are going to be drawn to these sorts of things, even knowing that 99% of it will turn out to be a square peg in a round hole, because somewhere in there, there might be a unicorn. People seeking investment from VCs might also promote the buzzword of the day for their own marketing purposes (to investors, the public, and the press).
- reaperducer 8y ago
  >I think these are just the normal hype cycles for new technologies. You're not wrong. Remember in the late 90's when everything was all i-this, and cyber-that? Everything was going to be on "the interweb!" Those big mainframes of yesteryear? We don't need them anymore. We have AOL and thin clients! Back in the 80's: We don't need rockets anymore, we have space shuttles! In the 70's: Who needs stereo? We have quadraphonic sound now! Look at old mainstream magazines from the 1950's. EVERYTHING was going to be solved by being "atomic." Too busy to cook dinner? Let your atomic kitchen do the work for you! Spilled coffee on your tie? Let an atomic washer make it clean for you! Little Johnny put in the dunce corner again? Slap an atomic Think-o-Tron on his head and let radiation smarten him up! I'm sure there are a brazillion other/better examples. Feel free to add yours.
scottLobster 8y ago
It's Anecdata, but when I was coming up through my Computer Engineering program a few years ago there were roughly three categories of students: 1. The Traditionalists: Students who are fascinated by the technology and what it can do at its limits. These people are disproportionately drawn towards the more arcane/unsexy applications (RF, hardware, high-power, radars, antenna design, IC design, embedded systems, robots, rockets, quantum computing, etc) and research. 2. The New Wave: Students who were inspired by a Steve Jobs keynote, these people were almost exclusively interested in potentially mass-market user-facing applications and have a greater emphasis on image (both personal and professional). 3. The Unmotivated: People who are there "because it pays well" and for no other reason. Not many of them made it to graduation, and the ones that did were "meh" engineers at best. Most of the naive junior engineers you're seeing probably belong to the modern incarnation of category 2. Steve Jobs has been dead long enough for new grads to have been inspired by the next generation of buzzwords. They're fine engineers in general, but they have a sometimes unhealthy fixation on said buzzwords and how "future" they are, because that's what got them into engineering. Most will concede when a simpler solution is presented, but it's uncomfortable for them. Unsexy but effective techniques undermine their aesthetic impulses and, to a degree, their self-image as engineers. A good popular example is Elon Musk refusing to use LIDAR on Teslas, and introducing way too much automation, too fast at Tesla's factory. People, even junior engineers who think they're part of a "ground-breaking" movement often have trouble separating "obsolete" from "tried-and-true".
- palisade 8y ago
  4. The Savant: Also known as the absent minded professor. You could throw questions at this person in an interview and they will seem completely inadequate and unprepared. But, then apply them to a problem on the job and like a juggernaut they will defeat any obstacle. They will even solve problems your best engineers have been struggling with for years without breaking a sweat. A lot of companies make the mistake of weeding this type of engineer out in the interview process.
  - abhishekjha 8y ago
    I may qualify in this category. Companies reject me because I gave them a brute force solution for finding repeated values in an array. But there hasn't been any single instance with my current job that I couldn't check all of the requirements that were assigned to me, even those which I thought I wasn't prepared for. The hiring/evaluating process needs to get refined.

bluedino 8y ago

How’s the old interview question go? Using the programming language of your choice, sort the strings in this file and remove duplicates. You have 30 minutes. sort foo | uniq

NullPrefix 8y ago
Clearly a suboptimal solution. That pipe isn't free. /s sort -u foo
- my123 8y ago
  Seems to be too little UNIXy. Modern tools sometimes not only do one job. (the z flag might have been kept out of tar too for example) :P
- emilfihlman 8y ago
  With piping you can leverage multiprocessing for free. Using sort -u alone might actually not be as fast as sort | uniq -u.
viraptor 8y ago
If you're using gnu coreutils: sort -u foo.
amelius 8y ago
And what if the strings are separated by spaces instead of newlines?
- flerchin 8y ago
  sed foo -e 's/ /\n/g' | sort | uniq
  - amelius 8y ago
    Yeah, but what if the strings I wanted to sort contain newlines?

bsenftner 8y ago

For those of us who have written an embedded OS in C, the situation is no different. The white board questions are crap like "How is React different from other JS frameworks?" Whaaaaat?

bartread 8y ago
To me those sorts of questions are terrible interview questions. I'm looking for a few things when I hire: - What are you like as a human being? Can we work together? - Can you code? [1] - Are you willing, in fact keen, and able to learn? - Can you see beyond the technical issues? [1] This tends to be frowned on in some circles, but given the bi-modal distribution of developer skill, leading to plenty of smart people who aren't good programmers, in my view it's of critical importance. Generally asking somebody to solve a relatively simple problem in a language they're comfortable with and that is also similar to something we use, or pairing together on a problem, works well here. What I don't care about is understanding of specific frameworks or technologies: if you're a good dev you can learn those, and we're happy to invest and give you the time to do so.
- justherefortart 8y ago
  I just ask them to talk about the projects they've worked on recently and any issues that arose, and how they dealt with them. If they can communicate clearly what happened. I've never had that fail me as far as them being "technical enough" for the position as no one knows everything, can you figure it out is the bigger issue. Then I typically just have them tell me about what they liked and disliked at prior jobs and what environment they would like to work in. After that, what are their goals for their career and how can we help them achieve them. If the interviewee can demonstrate they have anything in those areas, I've never had an issue with someone I've hired. I don't care if you can program everything walking in the door. If you've got a can-do attitude, we can work together to get you up to speed on our crap code and the whys behind it.
stmw 8y ago
Right, seems the real issue here is that HR/recruiting misrouted the OP's resume, or perhaps the interviewer did not read it carefully, resulting in a negative experience for both. The real issue is that more senior engineers and managers need to be involved in earlier parts of the hiring process.

_Donny 8y ago

I understand that the article is about how many developers are inclined to use wrong "hammers" for certain tasks. However, it also makes me think about how we actually code. At my university, we learn to sort files, parse data-structures, model various data formats, etc. But in most UNIX systems, we already have the basic building blocks in the form of simple programs that do one thing, very well. Will programming ever evolve from programming languages to more complex building blocks in the form of programs combined with pipes in the bash terminal?

goatlover 8y ago
Well, some programming languages encourage that kind of design by emphasizing message passing. You even get piping between functions in languages like Elixir.
int0x80 8y ago
Microservices? No bash though
TeMPOraL 8y ago
> Will programming ever evolve from programming languages to more complex building blocks in the form of programs combined with pipes in the bash terminal? Fundamentally, UNIX "programs combined with pipes" are equivalent to function calls. sort foo | uniq is equivalent to uniq(sort(foo)); Shell is nothing but a programming language/environment optimized for fast input and immediate, stateful execution. If you seek evolution of programming to higher levels of abstraction, this isn't the place. Command line interfaces work at the same abstraction level as regular programming in a high-level language.
xboxnolifes 8y ago
> Will programming ever evolve from programming languages to more complex building blocks in the form of programs combined with pipes in the bash terminal? 1) A bash script or 2) Those are called libraries.

zdw 8y ago

Reminds me of this article, which recounts a book by Knuth where the reviewer comes up with an 6 command shell pipeline equivalent to one of the multi-page examples: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...

blackbrokkoli 8y ago
That was a good read, thanks
samatman 8y ago
That exchange never sat right with me. I feel, and I hope Dr. Knuth would agree, that literate programming is a good choice for writing `uniq`, that the problem domain was chosen for didactic reasons. In effect, he chose to show off parts of several programs, rather than finishing one. The intention was to teach. That shell script was a tour de force at the time, showing off the Unix Way of small, sharp, composable tools. What Dr. Knuth was (and is) saying: write those small, sharp tools in a literate manner. A real missed opportunity.
- svat 8y ago
  Indeed, yes exactly. And in fact, later Knuth wrote `wc` (one of the shell programs in the pipeline) as a literate program, and showed that it was better as a result than the one that came with Unix.

mmjaa 8y ago

I think that whats missing in this assessment of HR these days, is that interviews are just as much an opportunity for the prospective employee to evaluate their potential new employer, as it is the other way around - only, we're seriously NOT used to thinking in these kinds of terms. I've been programming since the 70's, and have built systems and subsystems that are still up and running around the world. If you logged onto an ISP in the 90's and early 00's, chances are you were going through a code-path that I was responsible for .. if you took a train in any one of 38 different countries in the world, in the last 15 years, chances are your life is being protected by code for which I was once responsible. I've done a lot of crazy shit; I've done a lot of cool stuff... I say this only to indicate that I'm no newbie when it comes to software systems engineering, and all it entails: I've shipped to tens of millions of people, and I've shipped to a small, localised group. Point is, I've shipped, yo. A few years ago I went to a job interview at a local game development company, since I have a high interest in game engines and have even built a few of them myself, as well as published a few games over the years. I thought the interview was going well, and at first I hit it off just great with the guys doing the interview .. but then as they started pulling in more and more other engineers to meet and greet, and ask questions, I started to get a feel that I really didn't want to work at this place. Mid-interview, I felt like I should just stand up, say "sorry guys, you're not a good fit for me", and left... but instead I decided to sit through the interview. This was a big mistake - they came with the inevitable whiteboard questions, and so on. So, I flunked them all - not because I couldn't work out the A* algorithm on the board, but because I really lost interest mid-interview. It was only a day or so afterwards, having a bit of retrospective rumination time, that I realised that I just really didn't want to work with those guys. They rubbed me up the wrong way, and there was just something about their culture that I didn't feel for .. well, I should've just said something. I should've said "well, you guys have a great company (it seems), but I'm seeing all sorts of warning signs in this interview, so I think I'll just pass on this opportunity - and thanks!". But instead, I stuck around and ended up just degrading myself with stupid responses to their requests. I didn't really feel like I was in power, or had any control - but honestly, I did. I really could have just stood up and said "well, that last guy you brought in was a bit of a wanker, and I don't want to work in an environment of wankers, so thanks for the opportunity but no thanks".. I think this is a real cultural dilemma. We, builders of technology, should really acknowledge our value, and place it a lot higher than the current HR-infected job market implies. Its a double-edged sword of course - nobody wants to be known as the guy who shits on this interview companies - but on the other hand, why do we put up with such imbalance? EDIT: Just wanted to add that this particular line of the article resonated with me: 'He asked, "But didn't you write an embedded OS?".'. That, right there, is a sign that the interviewer has a very, very poor understanding of the subject, and the talent should just get up and leave. I wonder how many of us overlook this fact in our interviews, out of desperation?

a1369209993 8y ago

> "I can do it in two commands chained by a pipe in bash." > any programming language I like I choose Bash.

paulddraper 8y ago
Probably depends on what the "commands" are. You could also do it with two Node.js functions (from npm packages). The presumption is that the available library is limited, though exactly how limited depends on the interviewer. Plenty of times I've chosen a language because of a particular function in its standard library, only to be told that function can't be used.

twblalock 8y ago

In defense of the interviewer, if somebody told me they wrote an OS for the Raspberry Pi I would assume they wrote it mostly in C, not mostly in Bash.

aw3c2 8y ago
> I made an distro for the Raspberry Pi called Crankshaft Someone who picks up that info and turns it into interview material should be well aware about the difference between making a distribution and writing an OS!
- PrimHelios 8y ago
  Not to mention that since the interviewer now has a name for said distro, they should have looked it up and found what language it was written in.
jimmies 8y ago
No that's the problem. I said I did not write this to bash the interviewer and I really meant it. The idea here is that to achieve something quite useful like a distro ("made an OS") for the Raspberry Pi, the important part is to figure out a problem that needs solving and a tool to solve it. A person who made something cool might be actually quite dumb, and that's alright. A good answer is something that foremost solves a problem. A bad answer is a fancy technology that doesn't do it better. Here I sucked at my Go solution and I deserved to fail. But here it's just a lame fail because my initial solution worked and the rule changed to accommodate the fact that it was not the technology he expected.

daixtr 8y ago

So I said, iL call the snmp API to read the data. Then he said, "no, you need to read the bin file to read the data". I thought, what an idiot he is. I lost respect, lost faith. Little knowledge is a dangerous thing.

im_down_w_otp 8y ago

Given how much of software development itself is often little more than cargo culting w/ strong doses of guess & check stirred in, I suppose it makes sense that hiring/interview practices would mirror that, but it's still depressing everytime I come across stories like this one. It doesn't have to be like this. I don't hire people this way because I've never seen it produce good results, and I have to hire esoteric skillsets for a challenging problem, and without the time or budget that will forgive making bad hires.

rambossa 8y ago

I hate the Cracking the Coding Interview/Leetcode style... studying for these type of interviews is annoying. Trying to find a good video on youtube, where they aren't just naively coding up the bruteForce->optimal possible solutions, especially is irritating. It is literally a landscape of college kids with thousands of viewers who treat these interviews like a standardized test (SAT, GMAT). Even the author of the book produces videos with very little insight or meaningful content. "Find all the subsets in a set that add up to sum" -- "Okay for this we will use the sliding window technique and here is how it is done" -- WTF is this. I get that they want to see problem-solving skills, but this is on a different level requiring the interviewee to have studied and knowledge of the technique, otherwise we are basically trying to develop efficient algorithms from scratch and in little time. --This makes sense for college interviewees who have only studied the past 4 years, but for a professional with experience, why is this adequate?? Does algorithmic programming matter?-- still yes. But the way it is interviewed is absurd and inadequate. I had a production service centered around the stable-roommate-problem. It took me a week or two (mostly research) to develop something out and fit it into our codebase. It then took 1-3 more weeks to actually make it work for us and cover edge cases (i.e. Irving's algo quits after instability -- this isnt an option in the real-world). I read much material on the subject, other's code, had many deep-thinking sessions where I was mostly in my head, wrote unreadable scratch on paper, collab-whiteboarded (sometimes arguing), tested&failed PoCs, and had many breaks in-between it all. How successful was that project?--very, did I need to know and study techniques with lacking/meaningless basis to do it--no.

zawerf 8y ago
Recall when you first learned how to program. Something as trivial as iterating through a list requires some thought. What is the syntax for a "for" loop? Do you start with i = 0 or i = 1? Should you end at i < n or i <= n? At some point you stop thinking about it and write "for (int i = 0; i < n; i++)" instinctively. You can now solve harder problems that require iterating through a list without thinking about it. All of algorithms and programming is like this. You unlock harder problems as you learn more problem solving building blocks (whether it's an algorithm, a software design pattern, or some API call). A programmer is someone who can learn these on the fly for any problem of any domain. An effective programmer is someone who has a large cache preloaded with these building blocks already. In that sense I find leetcode style problems to be very fair. They are meant to be solvable in under an hour without thinking once cached into muscle memory. All it is testing is whether you're capable of becoming an effective programmer in some agnostic domain. All you need to do is warm your cache with a small number of standard patterns (which might even be useful for real work). It does suck that even the good programmers need a few weeks to warm their cache. But it weeds out the fakers who can't do it given any amount of time.

jknoepfler 8y ago

I'm honestly tired of programmers complaining about interviews. I don't think the whiteboard blitz is a good gauge of an employee, either, but I don't know of any good "test" of a potential coworker other than working with them. One thing I think people wildly underestimate is how aware the interviewer is of the inadequacies of parts of the process. I will ask basic programming questions for the same reason I write unit tests. Weed out obviously broken candidates with really easy questions. But beyond that, I need people with common sense and a strong sense of professional ownership. I need engineers with spines. I need people who tell me what they think needs to be done, not people who are going to sit in their cubical complaining about how crappy the interview process is. I need people who learn quickly, not people who will be paralyzed by code smell or new tech. I need people who can jump into management roles to fill in gaps because they get how things work and want the team to get shit done. If you don't like the process, fix it yourself on your team. Do better. Teach others. Believe it or not, lots of people have gone down the same rabbit hole, and your "crappy interviewer" is likely one of them.

scarface74 8y ago
I'm honestly tired of programmers complaining about interviews. I don't think the whiteboard blitz is a good gauge of an employee, either, but I don't know of any good "test" of a potential coworker other than working with them That's the answer - "you work with them". I create a simple version of a real world class that we have worked on. Each method has comments on what the code is suppose to do and a bunch of failing unit tests and we pair program. The first set of unit tests are relatively easy. I then add a second set of requirements with a second set of unit tests. They have to modify the code to pass the 2nd set of unit tests without breaking the first. But as far as "going down the rabbit hole", I've never gone down that rabbit hole of algorithm type tests. I was drilled on C in an interview in 1999 because they were doing a lot of hard core C work (I stayed on that job until 2008). But since then, most of my interviews have either consisted of the sitting down at a computer and solving problems type or just drawing on the board and explaining architecture. Even though I'm very much hands on, at this point most companies hire me more to help them with architectural issues than just as another coder. My salary requirements filter the just another developer type roles out. No, I'm not bragging about how much I make. I'm still only making the median for a senior software Engineer/architect for my market - if the salary surveys and my anecdotal experience is accurate.

HumanDrivenDev 8y ago

> If his tech model turns out to be relatively successful, a medium-sized company in tech will be able to easily copy his model and out-compete him Does this happen all the time and we don't realise it due to survivorship bias? And if so, how do we account for the successful stories that started from the bottom up and became medium-sized companies themselves?

lucio 8y ago

>I don't intend to write this post to bash the interviewer pun, intended?

103e 8y ago

"Invert a binary tree on a whiteboard" I wonder if you get any points for turning the board upside down.

jernfrost 8y ago

Sitting on the other side of an interview, I was so annoyed with the guy I was doing the interview with because he insisted on these algorithm challenges. I told him these tasks are bullshit, because the job we do doesn't involve coding algorithms EVER. I wanted to focus on the ability to read messed up code and figure out what it roughly does and how to improve it. Turned out we were both kind of wrong, although I would claim my co-worker was way more wrong than me. Our candidates pretty much failed all these algorithm questions. And when my co-worker tried to help it turned out that he didn't have a proper grasp of the problems we presented either. My reading code test didn't work very well either, because these test subjects were fresh out of college and had little experience in reading larger code bases, refactoring and dealing with software engineering problems. Like most people in college they had mostly dealt with toy sized programs. So in the end what proved the best guide was plain old boring interview questions. Our interview was largely a failure but we hired the programmer on a hunch anyway based on her explanation of some theoretical subjects. It turned out that she worked out just fine despite failing pretty much all the tests we had made. That is because a lot of development these days is more about persistence, motivation and ability to google. She was practical, eager to find solutions and eager to google and that made her get stuff done.

bsder 8y ago
> That is because a lot of development these days is more about persistence This is true of most technical endeavors ...

andrewstuart 8y ago

The only sound recruiting advice is Joel's, which remains true today: Hire people who are smart and get things done. The interview questions to determine that go something like: "List out your top achievements in programming" "Explain each of them to us in as much detail as you possibly can" I'd look for enthusiasm for this particular job too, assuming they have had time to fully understand it and give it some thought.

deleted 8y ago

[deleted]