“But didn't you write an embedded OS?”
tnhh.net
tnhh.net
"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.
If you have an interview with complicated tangled questions with too many things to handle, or questions that require the knowledge of a special algorithm, then either you fail because you haven't come across it, or you pass because you know the answer and pretend that you don't. Then those interviews literally become the SAT. I think it is a good strategy when it comes to giant companies (applicant's job demand>>supply). It's just as a high SAT score is relevant when it comes to the top schools. It signals to employers that either you're a genius who have done a lot, or you want the position badly enough to go through the pain to study and memorize them. Either is a good thing to have.
I think for smaller companies, posing those crazy hard questions and expecting the best answer is a bad idea.
I have seen companies that have executed the tech interview very well, though. The questions don't require specific knowledge about an algorithm. The interviewer hinted the interviewee when they needed help. I got asked questions that I never came across but managed to come up with a great answer by the end of the session. That's a sign of companies that know what they are doing.
After interviewing with several companies in different sizes with a mixture of good/bad interviewing processes, I realized the YouTube tutorials and the books weren't wrong. But not everyone has a bad interviewing process. And you probably shouldn't expect a non-tricky one from a giant tech company that everyone wants to get in.
It's like dating the hottest girl in high school -- you know the name of the game. But for a real happy relationship, maybe you don't need to chase the hottest girl. Maybe you should look for smaller companies that like you as much as you like them.
Is it? I can't help but feel if, for instance, Google had useed a sensible interview process and hired Max Howell they might have gotten their act together on golang's package management a little earlier.
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.
It also weeds out people who have better things to do than cram two weeks for your pretend-meritocratic little exam.
How about requiring that candidates comment their code using quotes from Classical Chinese poetry? They are proven timeless classics that an intelligent person can apply to any situation. This test would weed out the fakers who can't refresh their caches while also honoring an ancient tradition of stupid job interviews, the Chinese imperial examination.
All interviewing techniques have to make precision-recall style trade offs. The mere fact that an interview method has false negatives surely doesn't disqualify it. It has to be compared against the available alternatives. What are the alternatives?
- White boarding? Algorithmic knowledge is often tangential to the actual job.
- Take home assignments/mini projects? High relevance to job, but in my experience takes the most time for the candidate.
- Trial period? Most people can't just drop everything they are doing to come hang out at your company.
- Conversational interview. Like white-boarding, tangential to actual job. My experience on the interviewing side is that it is often hard to learn much about the candidate.
- Read their code on github / blog. Lots of candidates don't have the time or inclination to code outside of work.
- Something else?
So what's your preference? I've done them all and find them all to be lacking in different ways.
> How about requiring that candiates comment their code using quotes from Classical Chinese poetry? They are proven timeless classics that an intelligent person can apply to any situation. This test would weed out the fakers who can't refresh their caches while also honoring an ancient tradition of stupid job interviews, the Chinese imperial examination.
This seems like the fallacy of grey to me [1]. When hiring, for example, a web developer, yes, algorithmic knowledge is a somewhat arbitrary indicator to use, but it is not completely arbitrary. Not all things are equally unlike.
If I were hiring for a basketball team, and had to choose between two candidates neither of whom had experience playing basketball and were alike in all ways except that one was an avid soccer player and one was equally fervent about pottery, I would choose the soccer player. The logic of course being basketball and soccer have more in common (athleticism at the least) than basketball and pottery.
Likewise, algorithmic thinking shares some common points with almost any kind of engineering task.
Interviewing is just a hard problem where you are trying to predict future performance based on a few hours worth of data. I don't think most of the popular the techniques we have are obviously stupid. Companies have strong incentives to make hiring efficient, but there just isn't a lot of low hanging fruit. Of course there are the occasional ego maniac interviewers, but an ego-maniac is going to be able to ruin any type of interview. Let't not throw out the baby with the bathwater.
1. https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallac...
1. Filter candidates based on fairly simplistic early models for personality profile, motivational bias, and metacognitive disposition cues.
2. On a subset, further refine the above filtering further w/ another 1 or 2 interactions looking for inconsistencies and/or stressing facets of the model that seem contraindicating or hard to suss out.
3. Prep the team on what & how to assess and bring a small number of candidates on-site for a few hours, to work directly with the members of the team they'd be joining, and have them work together on exactly the work they'd be doing.
So I put in a lot of work ahead of time as a hiring manager to understand what kind of role I need to hire for, what kind of person would likely be successful in that role, and what kind of person would likely be successful working with the team that exists (or will be built). Then I completely avoid some contrived pile of quizes and weak competence signals by instead directly using an actual work environment w/ the same people, the same meetings (stand-up, design review, etc.), and the same tasks that both we & they would be cooperating on together.
The "contrived" puzzles approach has the advantage that each candidate can be given (and thus evaluated on) the same task. The size and perquisite knowledge for the task can be well controlled and since the problem is not new to the interviewers, we know how to present it in an easily understandable way and help them if they get stuck.
I think another reason why the "general cognitive ability" approaches are popular is because employees (especially at small companies) need to be good at such a wide range of tasks that it is not realistic to evaluate even a fraction of them in the span of a few hours.
The tasks can be writing docs, writing requirements, writing property-based tests, writing CLI tools for developer ergonomics, formally modelling and verifying a scheduler, designing a DSL for safety-constraints or characterizing the electrical interfaces of a car's steering system. It's not entirely material what the tasks are. There will be opportunities in any of those to get good indicators of the important factors.
FWIW, the purported consistency of evaluating people using the same contrived task is fairly unlikely to be actually consistent, and even if it were, the value of what you can actually meaningfully derive from it is still deeply questionable all the same. As a result the reality is more likely that those situations are producing negative net benefit.
That’s not at all what happens in programming interviews that use algorithmic puzzles.
You have candidates who already have a professional track record in basketball, and instead of focusing on that profile and whether it’s a good fit for your team, you give them a timed soccer workout because it’s somehow a more objective measure of athletic ability.
Any basketball team that hires like that wouldn’t survive for long. The quiz interview format in the tech industry is a form of “anti-Moneyball”. It works for the SV giants because they have an enormous supply of candidates and they need generic competence that can be shuffled around. Smaller companies would do much better to hire for the actual role, not for “Cracking the code interview” memorization performance.
As for hiring people based on their experience profile, it’s great of course in the case of candidates with lots of open source contributions and such, but this has the issue of ignoring the majority of candidates which don’t contribute to open source. Should being an os contributor be a hard requirement?
But if you are suggesting that a resume with the words “5 years experience web development at company x” means anything, I’m a little incredulous. I worked with people that claimed to have far more experience than that and struggled horribly with even the most basic tasks.
Finally, a little tangential, but memorization gets a lot of flack for being a “stupid” skill. My experience is that it is nearly impossible for adults to memorize something like Chinese by poetry “by rote.” Indeed if you try memorizing some poetry I think you’ll find that it really is a very fulfilling and creative process.
Yes, you might need to prep two weeks in order to get a job that pays very well for 2-15 years. And since this test is so common, you don't have to dedicate 2 weeks to juat one potential employer. If you can't freshen up on standard basic algorithms and coding in 2 weeks for an interview, how can you do it for whatever complex problems you'll face at work?
You can't hire someone solely based on what they claim they built.
I see a lot of people that complaining that they can't take their senior engineer rank from company A and jump into company B at the same level without even justifying themselves, let alone working their way back up. To me that's utterly disrespectful to the the domain specific knowledge and experience that is needed to be a good senior engineer. Someone thinks they are obviously good enough to be a senior employee somewhere, but for some reason isn't good enough to build something valuable on their own, and isn't able to demonstrate skills in a face to face meeting.
Do you really believe in this? I would maybe call it an Ex Machina droid...
In my experience, this is where the house of cards collapses. For most programming jobs, none of that will ever be useful. And on the rare occasion that it is, you'll have gotten by without needing it for so long that you'll have to look it up and more or less learn it again from scratch anyway.
I find these sorts of things to give far too little useful information during a developer interview.
All this to say, if interviewers actually spend half a day and write practical questions that test the skills used in real work, it IS possible for both the interviewer and interviewee to be happy.
Also for the in-person, I just delete an existing integration-test we have and give the candidate our laptop and we pair program on rewriting it. This has worked well.
No memorization or trivia or tricks, just standard development exercizes.
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?
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.
That's what the parent-poster meant.
It was only in the mid-late 90s that simple handwriting / character recognition techniques were able to be used in somewhat real-time.
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.
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.)
There are well paying ML jobs that don't involve getting a PhD first.
Most job ads mentioning Haskell and OCaml are really for Java too.
Incentives are currently aligned toward everyone choosing to solve problems using the most complicated tools available.
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.
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.
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.
“We know what it is - just not what it’s for... yet”
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...
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.
Assuming that the data is available and curated (I'd argue this is a hard and very value creating task).
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).
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.
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".
The problem with #1 is that they refuse to acknowledge the newer tools of analysis and understanding. They cling to older "mature" tools and methods, with nary a care of if/how the newer ones work. They won't be the fastest or novelist, but one ting can be said: it will work, and it will work well.
The problem with #2 is "Oh shiny OH SHIT". They go down the path of the next new thing, with little to no understanding that the old fogeys already did that and it didn't work then. But their big advantage is, it might just work now and enable a whole new area.
And it's really hard being in both #1 and #2.
I didn’t mentioned it there but the only reason she got into Software Engineering is because it pays well.
Try and talk to her about tech and you won’t get much out of it. At home she watches Netflix and does her nails. No HN, Reddit or anything. No conferences.
Tell her she needs to learn language X and tools Y and Z and she’ll master it in a week. She’ll deliver 10x what everyone in the team does. Top performer in no time.
I can’t really wrap my head around it. I’m your typical tech enthusiast always here on HN, coding on my own time, etc. And yet if we were on the same team I’m sure she’d be orders of magnitude more productive than me. Which can be seen by the fact she makes almost twice what I make (am also an SDE at a large company), and is at a higher level despite starting 2 years later than me.
Sounds like she follows the needs of her job. The tangential, part-overlap enthusiast is always going to get toasted by the person going full on what's needed.
A couple of them where so far ahead of me it was like teaming up with a different species.
I don't buy the 10x developer stuff but I'd certainly put them in the 1.5x-2x category, We ended up working well together though I'd naturally take the "flesh this out, make it bullet proof, document it" side and they'd do the more creative part (it's not that I couldn't do it as well, it was just they'd do that in half the time).
I learnt a lot working with them.
This of course is impossible at companies which don't allow the flexibility for these people to stretch their wings. A big part of increasing a company's productivity is giving everyone the possibility to do this so you can uncover those hidden 10x-ers and put them in architectural roles.
Closer to 2.5x, if you're comparing best to median. 10x is comparing best to worst, and that's very believable.
A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance.
The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.
Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]
Also an idea: maybe she is fast because she has rest and downtime. We are more productive when we are not working all the time and have rest.
It baffles me because my initial reaction to someone like that is to think they’re not good. But she’s really good. She’s able to pick things up on the job fast and is extremely focused on her work. I OTOH always need to use my personal time to learn things and have trouble focusing, despite being a tech enthusiast.
But, I think that since she is "extermly focused on job" she probably likes (or at least does not hate) the job itself - not pop version of what programer should like or random messing with gadgets, but the job itself. Many people are like that - they are able to like many different things, so they like what they are doing now.
Not once can I recall reading something on HN I had no experience with an being able to use that at work without doing a lot of additional research. In terms of time spent and career impact HN is on the same level as Reddit, which is a net negative.
Conferences aren't necessarily a net negative but who wants to spend 2-3 days going to talks and all the after party stuff (which is where real career progress is made) to get one or two solid technical bits? Especially when those will be available a week later in countless blog recaps?
Upvote/downvote mechanisms always drown out unpopular truths.
yeah been weeded out a few times. and left some really interesting solutions at past jobs. When I get exhausted though I need breaks.. Flip side, it's way too easy to get obsessed over the wrong kind of solution too ... I LOVE working with QA teams and competent management because they'll usually spot this before I will!
I'm very happy in my current company.
I don't see anything wrong with that. I started programming in the 80s in the 6th grade because I was the stereotypical "short fat kid with a computer". (I got better) but after a few years in the industry, the only reason I code is for the money. The only reason I keep learning is to stay employable. It's not for a higher calling, it's not to change the world, and I don't enjoy doing it enough to learn any technology that isn't in demand in my local market.
When I was in my 20's it was very different to late 30's I had far fewer responsibilities so I think part of increased responsibility is knowing which problems to tackle.
I'm not saying I don't enjoy development - but as a part of building the system.
If I can find a hosted solution for a piece of infrastructure, I jump on it. I'm all in on "serverless".
I would fail any algorithm type interview these days. I'm just not interested in algorithms. I'm much more interested in leveraging libraries/frameworks/infrastructure providers to get things done.
For a concrete example, I'm currently (hopefully for not too much longer) working at a large defense contractor with a lot of 20 year+ software developers who have never worked outside the company in an engineering capacity. Some have kept up to date, but many hang up their engineer hat the moment they walk out the door, and it shows in their work. They don't learn anything new that they aren't forced to, and they often don't care about code readability, maintainability, anything that wasn't taught in mid 90s. They don't know what continuous integration is, and they don't particularly care. They argue, sometimes successfully, against changes and infrastructure that would be no-brainers at any marginally competent software dev house. They think agile is a horrible idea because all they know is my company's half-assed, broken implementation of it. These are the people who are still writing bloated 500-line functions in new code, giving me blank looks when I mention refactoring at the code review, and approving said functions anyway. It's very hard to be fired unless you commit a security violation, so they'll keep happily churning out horrible code until they hit retirement. Then they dream of kicking their feet up in Florida (literally in one case) and doing nothing. Or so they claim. Hell they've been in the aerospace industry for over two decades, and in many cases I, the junior man, had to tell them who SpaceX and Blue Origin are and why they mattered to our industry (and possibly their jobs in the medium/long term). They simply do not care. They approach their job like they're making corn flakes on an assembly line, and our product is many times shitier than it should be as a result.
If you can't tell, their wilful mediocrity pisses me off. :P They're part of the reason I'm looking to leave, although my larger problem is with leadership, or lack thereof (imagine these guys getting promoted, where they can care even less about staying up to date). Not to paint the whole company too badly, there are good engineers/managers that I work with, and they're a welcome breath of fresh air when I do. Just far too few of them for my liking.
If your goal is to simply remain employable then fine, you're welcome to find all your fulfillment outside of work. But if your only motivation is the stick and there's never any carrot, the moment that stick goes away you're going to be passed. From the sound of it fear of unemployment is your only incentive. For the sake of your co-workers, I hope you never find an overly stable job.
Yes I do put a relatively few hours in my craft outside of work. But I also keep my eye on the market and I aggressively change jobs if my job ia not allowing me to keep up with technology. Why work at a job where your skills are stagnating and then spend extra time learning the new and shiney when you can learn the new and shiney and get paid for it? Especially since wage stagnation is real and the easiest way to make more money is to change jobs.
I’m not above doing resume driven development or spending extra time at work doing a proof of concept on a new to me technology.
As far as the fear of unemployment being my only motivation. Why wouldn’t that be enough? At least that and optionality. There is no such thing as a stable job. A company will lay you off in a heartbeat. Fear of not being employable is a major motivation. The other motivation is not being able to jump ship at a moments notice. It usually takes me about a month to start a new job after I start looking - including a two week notice - always paying substantially more. (20 years and counting)
I’m at the point now though where I have to keep my skills marketable just to stay at my current salary.
Most people I'd describe as being in it for the money are just looking for a bland, suburban middle class existence and are happy to plateau once they start making enough to be comfortable.
As for job stability, oh believe me it exists. One thing I've discovered is defense contractor work (at least at the large contractors) is only one step removed from government work in terms of non-firability. Security clearances take a minimum of 6 months, often a year or more to process, it costs hundreds of thousands of dollars per investigation, and there's no guarantee a prospective hire will pass. As a result the large contractors hoard cleared engineers, almost regardless of ability. Even if your program ends it's an unwritten rule that some other program will pick you up. We haven't had layoffs since sequestration/the financial crisis, and relative to the size of the company those were minimal.
Again, you're describing me. I'm happy to "plateau" and unless something drastically happens with my local market, I'm close to it since I have no desire to go into management. If I want to keep my "bland,surbaban, middle class" lifestyle, I've got to keep my skills current.
But if I look what's on my agenda for possible things I can learn next, the most I can hope for is 10K more - excluding cost of living raises -than I make now (after making $45K more in the last four years by changing jobs three times).
I'm definitely trying to get even stronger at infrastructure (AWS mostly), but everything else I'm planning on learning - Node, at least one modern front end framework, Android and/or iOS, just increases the number of jobs I'm qualified for, not my salary by much.
There was also a political subtext. Burns' motivation was patriotism.
I actually found Frank to be somewhat sympathetic and to have some valid points on a few episodes, but many times he was just grossly incompetent to the point of threatening his patients' lives and his co-worker's careers. He wasn't just honestly mediocre, he rationalized it in all sorts of ways from extreme Patriotism to racism to outright denial, and was constantly looking for empty, sometimes underhanded ways to prove his supposed superiority.
But since the overall topic is the nature of elitism, I would volunteer that when I've had a friend or relative at a hospital with an "elite" reputation, that was no guarantee against episodes of incompetence. But that's a completely different topic.
The problem with these people is not that they haven't kept up to date with modern practices (half of which are probably cyclical anyway). The problem is they never learned any best practices.
People in 1998 knew not to write 500 line functions.
Reading about technology::coding for fun
Watching basketball on tv::going outside and playing a pickup game.
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.
http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...
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.
Using the programming language of your choice, sort the strings in this file and remove duplicates. You have 30 minutes.
sort foo | uniq sort -u fooUsing sort -u alone might actually not be as fast as sort | uniq -u.
By the time you say “unicode” and “collation” the programmer is going to be in serious trouble.
Fortunately the programmer can lawyer the problem. The original requirements don’t specify what the strings are sorted by. I choose “position in original source” file and complete the task with a NOP.
tr ' ' '\n' < foo | sort | uniq
I’ve worked with engineers who are competent programmers but just can’t handle these problems when they come up in practice. If the job actually requires it, I don’t know of a better way in the context of an interview to determine if a person is that type of programmer than with a few toy problems and a solution in code. You may miss some good people because the format is suboptimal, but you will weed out the people who just don’t have the theoretical and practical background to solve this particular type of problem.
I think there are better ways of doing things than the standard X interviews of 1 hour. One method that works well is hiring people for short term contracts (few days) and seeing how they work with the team on real problems.
The problem is that most really great people, who are in high demand, won't put up with this because they know they can get someone else to hire them with less hassle. Your approach ends up weeding out your best candidates.
I can see that there are scenarios where it might not work, for example if non-competes are in place and the industry is similar. But in most cases I think there's enough flexibility to make it practical.
The parent comment of yours identified the right need for them (a person who can come up with a solution when the time comes in the real world), but the method of toy algorithms means you could end up with the following scenario:
Person A: Spends months drilling solutions on whiteboards to memorize the answer. They pass as they can regurgitate every toy algorithm possible without thinking. They pass the interview.
Person B: doesn't deal well with interview situations and doesn't get the chance to talk in general about how they'd approach it in real life. They freeze up as they're stood up in front of a panel of people holding a whiteboard marker and being stared down. They don't progress in the interview.
Perhaps person B was the person who would sit at their desk for 20 mins in silence and come up with:
"ok if we're not deduping these on the inserts for our system, I guess the least we can be doing is maintaining one of those in-memory bloom filter things, I read about those one time as a good probabilistic data structure, might end up being a part of solution. I'll ask the tech lead if we have any memory constraints as I see that our AWS instances are compute optimised instead of memory optimised, anyway, we might get an off the shelf solution"
Person A: "which question in my 'interviewing for algorithms' text book does this belong to?"
You want Person B, you optimised your interview process for A.
I've seen the typical examples of ugly code over the years; over-complicated conditions, piles of IF statements, things that should be in a database or associative array, all because the person just couldn't solve the problem in a simple, straight-forward way.
These people get stuck on what should be a simple problem and productivity plummets. If you've spent the whole morning on something, taking it from 5 lines to 105, you're probably attacking the problem from the wrong angle.
All that for stuff which can be solved with simple 1-10 lines of code. (not these everlasting functional programming chained to eternity lines. real slim and dumb code)
> Broken. uniq alone removes only adjacent duplicates. You need uniq -u to remove all duplicates.
As benchaney (https://news.ycombinator.com/item?id=17060154) points out, the duplicates will be adjacent after `sort`.
sorted(set(foo.strip.split(' '))) #although we need to open the file first
Perl's not too shabby either for this kind of stuff :)
- 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.
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.
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.
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?
No bash though
Fundamentally, UNIX "programs combined with pipes" are equivalent to function calls.
sort foo | uniq
uniq(sort(foo));
1) A bash script
or
2) Those are called libraries.
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.
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.
This is true of most technical endeavors ...
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.
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.
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!
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.
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?
Thanks,
In retrospect, I think I should have said "Thank you for spending the time to talk to me, I don't want to waste any more of our time", and left.
I’ll wager whoever said that was a decent guy who liked you and decided to do you a favour.
Unpaid overtime is something I expect much more from employers that are not doing government work, particularly the game industry.
I've found a very different situation at a federal government contractor. Normal weeks are 40 hours, it is rare to work beyond that, and any extra work means extra pay. BTW, see my "Who is Hiring?" post if you wrote an embedded OS.
1. During a technical phone screen for an SRE role, the questions delved into, well, the nitty gritty parts of containerization, as if I were building my own Docker. Afterwards, I regretted not calling out how bored I was by this. I didn't want this to be my day-to-day work, and I disengaged from the questions. I should have bailed.
2. I'd submitted my resume for an SRE role, and a few minutes into a technical phone screen we realized it was for more of an IT role. The interviewer asked if I wanted to keep going, but I opted to pass, as it wasn't a great fit. Talking to the initial recruiter again got the SRE role rolling again.
Calling the interview off early saved time for me and the interviewer. If it had been more interesting or relevant, I could consider it practice.
A bad sign for sure, from the candidates perspective.
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?
> any programming language I like
I choose Bash.
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.
pun, intended?