That is a pretty huge statistic, - what also pops out to me is: "stop practicing ". This seems to imply that these technical interviews are skills that you don't really gain on the job. I know that personally would 9 times out of 10 spend time on a cool / beneficial project rather than making time to practice trivia problems.
> these technical interviews are skills that you don't really gain on the job
I believe that's definitely the case. That's why I shifted my interviews to be as much like the work as possible. First round was a pair programming interview plus a bit of technical discussion. Second round was kicking around a feature and its implementation with the team.
My goal was also to see people at their best, so I did as much as possible to make them comfortable. E.g., for the programming portion they were welcome to use their own device, their favorite editor, and their strongest language.
Wouldn't it be more detrimental to a team's performance to hire someone who isn't a cultural/productive fit? I think that would make the temporary performance hit when hiring worthwhile.
Exactly. A good hire will add thousands of hours of productivity. A bad hire can be negatively productive, either personally, by harming team performance, or by driving off productive people. Trying to minimize team-minutes spent per candidate on late-stage interviews is a false economy.
In practice, I don't try to get absolutely every team member involved, just a quorum. If everybody wants to have a say, that's fine by me, but often once you get past 3 participants somebody will say, "Oh, whatever you folks think is fine by me."
>This seems to imply that these technical interviews are skills that you don't really gain on the job.
the technical interviews skills are gained, at least in my experience, as result of the technical interviews - which normally implies, and did happen in my case, high rate of interview failures initially. Taking failures hard would naturally lead to Catch-22 here.
the biggest catch 22 for me is when you work with someone for years at a job. at this job you have a strong interview process. you reject the same 80%+ of candidates. then you move somewhere else. you refer your friend. they get rejected.
were they a bad employee?
did they sneak in the door at the last place?
Is there a problem with how we do interviews?
Speaking as someone who has taken on a lot of hiring responsibility: the cost for rejecting a good applicant is 4-5 hours of my teams time while they interview someone else.
The cost for accepting a bad applicant is several months of salary, reduced productivity for my team, risk of a discrimination suit if I don't put them on a PIP, etc.
So as a hiring manager I am pretty OK with rejecting a lot of good applicants just because some little part of the interview didn't go well, if it means that I never hire anyone really bad. The good applicants will get jobs somewhere else, it's OK.
The technical interview is part of that. The coding test is part of that. Sitting down with them and making sure they can talk through a problem with their future teammates is part of that. There's no one piece.
And finally, if your career is to write code and solve problems, and someone gives you a test where you have to write code and solve problems, you should be elated. Is there anyone that wants to answer the "Tell me about a time where you had a disagreement with a supervisor"-type questions that the rest of the world has to deal with?
> So as a hiring manager I am pretty OK with rejecting a lot of good applicants just because some little part of the interview didn't go well, if it means that I never hire anyone really bad.
How does this square with the oft-repeated "shortage of engineers" meme that Silicon Valley can't shake. You seem to be able to pick and choose, and pass on good candidates for nit-picky reasons, so is there really a shortage of talent?
3-6 months to get someone trained up, and a lot of their pay would be in /training/ them (you'd still pay at least a living wage for the area, but you might upfront plan and disclose to relocate them if hired).
The benefit would be both in seeing if they're a good fit, and also enriching that employee as an employee. Both sides would have a much better perspective of if it's a good fit, if they want to restart the process with a different team, or if the employee can find better value in society elsewhere.
When you think about it, college degrees in IT/CS are the wrong way to go about IT/CS learning. A 3 year apprenticeship like an electrician or plumber does would make a lot more sense. 60% of your time is spent at work, shadowing and helping an experienced professional who can show you the ropes and explain concepts in the real world. Remaining time spent in the classroom doing theory and learning new stuff.
My degree attempted something like this, with a lot of guest companies providing projects that amounted to coursework. For example, one coursework was to make a front and back end in asp.net with a predefined set of features for a company.
The problem with apprenticeships is that educators are handing over a large part of your training to a company with unknown factors, like mental people with random hangups. Still, I'm sure many of us when we got our first job felt hopelessly unprepared for working in a real company.
There's fear of poaching because the tech industry is so incredibly bad at giving raises. People are forced to change jobs to get what they're worth after just a few years.
Some companies are smarter than this, but most are not, from what I've seen. So yeah, they're going to worry about poaching because they know they aren't doing what's really needed to keep people.
>the cost for rejecting a good applicant is 4-5 hours of my teams time while they interview someone else
The cost seems much higher to me. I have to interview dozens of people to find a single good applicant. Rejecting one good applicant costs me dozens of interviews, not one.
Oh yes, and that applies to both sides of the table. Interviewing skills are learned as well - and they can be taught. (A friend is proud of the fact that he's had actual interviewing training.)
Interviewing is not that hard, but it sure as hell is a difficult thing to master. I'm reasonably good, but still nowhere near as good as I'd want to be. Nonetheless, it's still a skill that can be learned and improved.
The irony is that it'll be easier to improve one's interviewer skills than those of being interviewed. The reason is that if you're conducting technical interviews, you'll be doing it as part of your job, and any reasonably good interviewer will have his or her calendar full of learning opportunities.
Candidates will have less opportunities and due to the nature of the experience, are likely to be demoralising to boot.
I recently wrote a post about things I've picked up and learned when doing technical interviews: https://smarketshq.com/notes-on-interviewing-engineers-a4fa4... ; when judging the experience from HN posts, I cannot help the feeling that most engineers are subjected to pretty horrible, even recurring interviewing experiences.
I've had 4 technical interviews in my life and passed all of them. I didn't practice for them, I just have strong foundations in CS. The most criticism of interviews comes from people who can't get past them.
You don't "just have strong foundations in CS," you also have strong foundations in interviewing, whether you consciously developed those skills or not. The problem is that those interviewing skills aren't really relevant to the job, so they shouldn't be part of the interview.
I once had a candidate who completely bombed the interview, one of the worst interviews I've ever done, but he had a great portfolio. I took the risk and hired him on instinct and he turned out to be an amazing frontend developer who just doesn't do well when he's on the spot standing in front of someone. Years later I recommended him to someone else who was hiring, with the caveat that "he's going to bomb the interview," which he did. The guy called me back and said, "I can't hire someone who did that badly on the interview" and I told him, "do it, you won't regret it, I promise you." He did make the hire, and it predictably went great.
Interviews work well for salespeople because interview skills and sales skills overlap a lot. Interviews don't work as well for engineers because interview skills and engineering skills overlap very little. It's just a large injection of noise into the hiring process.
I've always thought that if I started my own company, I probably wouldn't even interview people. I'd search specifically for the people I'm interested in, bring them in for a meeting just to make sure they aren't crazy, and then hire immediately. If someone sent me an application wanting to be hired, I would give them a work sample to be completed in one week and hire on the basis of their performance on that.
What I'd actually prefer to do is actually pay someone to do real work for the company, like an actually useful task, but there are lot of complications with that. There are costs to "hiring" someone even for a small task (Tax ID number, 1099, etc.) and there are risks about exposing your codebase to interviewees who are not bound by proprietary information agreements and invention assignment agreements.
I have only failed one technical interview in my life, and to be honest I did not fail it, I took the confidence route which put off the 20 something lead I was interviewing with and mentioned that I was a keynotes speaker at IBM Impact on the coming transition to Javascript based applications. He took this as an affront and challenge (to be brighter than the IBM speaker guy to his team) and ensured that the interview was a miserable experience, but that is neither here nor there The only reason I toot my own horn is to relay the following observation.
The point I want to get to is: I have a buddy who I have dragged along with me (many times staking my reputation on his abilities), to every engagement I go on and this guy could not pass a how to use Microsoft Word interview. He has Aspergers and locks up and fails miserably in the interviewing process, but the honest, reality is, he is 10 times the developer I am, the guy sees patterns instantly and has a knack for code organization. He can master a new technology in a week and is hands down the best developer I have ever met.
That being said, over the years watching him has lead me to the conclusion that it is indeed the ones they hold faith in the technical interview are actually the ones that are the most stove piped and only see the world thru their limited experiences. It should be classified as a form of confirmation bias.
My advise don't be sorry be proactive, if you meet one, be their friend, be their network, look out for them. That is how the world changes, one person at a time.
Can confirm. My best friend is a sales guy at the place I landed my first real (W2) job. Been 5 years and going strong. I am even the "Sr. Engineer" now, working on first principals and loving it!
That's a pretty narrow view of the problem. Like you, I've never had a technical interview that didn't turn into an offer. However, I have some strong doubts about their sensitivity (as opposed to specificity, which is fairly good).
On the other side of things, I can say that most of the criticism of interviews I hear are from people who passed the interviews, possibly a long time ago, and are complaining that the technical interview process is inappropriate for hiring people onto their team, but they have to do it anyway. It's a common sentiment that the correlation between technical interview performance and job performance is weak.
Without sounding condescending, how old are you? I had my head more "fundamentals of CS" when I was just leaving school and also never failed a technical interview. After spending some time in industry, I don't think about those types of problems as much. If I were to do the same technical interviews I did back then today, I'm almost certain I wouldn't do as well.
You sound like a superstar. I don't mean that condescendingly, but I meant that genuinely - assuming you're telling the truth, you're the kind of candidate (based on tech skills alone) that most companies would love to interview and hire.
But there are way more jobs and positions than there are candidates like you. And you can't have every company be full of superstars.
The argument is for the rest of us, having a hiring process that optimizes for superstars doesn't select the best of the rest - it selects a random subset of the rest.
I wouldn't call 4 interviews a superstar. It's really doable, a bit of skill + a bit of luck for the first interviews + a hiring bar set at 'junior' cuz he's young :D
I suspect that they're not calling you a superstar because you've passed four tech interviews, but because your foundations of CS aren't decaying.
I work with a lot of teams as a contractor/consultant/whatever you want to call it. I often have to bite my tongue when team members that work for my clients forget what I believe are really simple things. For example, doing lookups in a hash vs an array. That was literally the entire solution to a performance problem I solved for a client: loop through an array once and make a hash, and then do lookups from the hash. Dropped the calculation from 4 minutes to 4 seconds.
The point is, this stuff comes naturally to me. When I think about going to town and shopping at 4 stores, I curse google maps for not implementing a heuristic TSP solver. When I started playing with hashicorp consul and vault, I went and read the Raft paper just to understand what was going on.
There's a lot of people in the industry that don't think about this stuff. I probably wouldn't if it didn't just come. I've got this deeply ingrained curiosity, and some kind of innate talent to remember it all and keep drinking from the fountain.
It's hard to remember that not everyone is like me. I'm not trying to say any of this as some form of humble brag or anything. It's just really important to remember that how I think and act isn't the same as most people. That, I suspect, is why the GP called you a superstar. You likely think about things in a much deeper and more frequent way than others.
Interesting, but your case may really get at what may go wrong with the algorithm exam approach to interviewing. I would expect a developer with a good understanding of fundamentals to see the difference in using a hash vs an array, and I would hope that developer at one point implemented a hash as an exercise.
I haven't needed to implement my own hashing table or methods on a real world project, as far as I can remember, but yes, I've absolutely written code that would have performed miserably if I hadn't known to use a hash rather than an array. I just didn't custom roll the hash, I used the hashing methods available to me in that language.
I'm aware of what a hash is, and what a hashing function is, and how collisions are resolved, and strategies to handle them. But I'm also almost certain I've been screened out of jobs because I couldn't implement a hash with a good hashing function in 45 minutes at the whiteboard. I just don't walk around ready to do this.
To address the last point, there's a tradeoff, as always. There's two competing forces with a hash function: speed and distribution. We want the hash to compute as quickly as possible, but want as close to equal probability of each bucket being chosen.
Assuming you're looking for a 32-bit hash value, my lazy whiteboard hash function would probably be something like:
- for strings, xor the bytes a word at a time.
- for ints, just use the 32-bit value
- for objects, let them provide their own, and if none is provided just use their memory address (this assumes that the objects don't have equality operators... that gets more complicated. If an object implements an equality operator, it also needs to implement a hash operator.)
These rules are by no means optimal, but they'd probably do as good enough for something that's not super high performance.
It also bears keeping in mind, I learned C twenty years ago, at the tender age of 12. Self-taught from the book that came with the compiler floppy[1]. We wouldn't have Internet at home for another 2 years, so I would occasionally persuade my parents to take me to a local Internet cafe for an hour to slurp up as much as I could at 28.8kbps and scribble it down. Bit manipulation operators are pretty deep in my soul at this point.
---
So going back to the original discussion... that came pretty natural to me. "How would I implement a hash function?" The brain whirrs a little bit and says "hey, here's some things to think about". I am 100% aware that this isn't typical, and do not expect others to have the same experience.
In fact, if I were hiring someone, I would be totally satisfied with an answer of "I'm not sure how to implement a hash function off the top of my head. It takes the object/value that we're going to insert into the hash table and turns it into a number that we can use to index into the appropriate bucket. Can we look one up?"
Hell, I'd probably be satisfied with "Here's when I'd use a hash table, and here's when I'd use an array. I've never implemented a hash table but I'd love to know how it works under the hood."
For me when hiring, the two biggest things I'm looking for are the ability to decompose problems into manageable parts, and a curiosity about how everything works. Those two things together tend to make any other knowledge gaps totally manageable; I'm not omniscient, but my desire to learn as much as I can about anything I don't understand can sometimes give off that illusion :P.
Well, here's the thing - I've been on a lot of interviews, and the majority of them wouldn't be satisfied with the answers you'd be satisfied with. If interviewers were the way you've described, I don't think the whole thing would be such an issue.
Overall, yeah, interviewers want to see that hash map largely written, often at a white board. Minor errors and bits of pseudocode are ok, but it should pretty much work.
"Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work. Again, it's like one chapter in one data structures book, so just go read about them. You should be able to implement one using only arrays in your favorite language, in about the space of one interview."
Of course, Steve Yegge isn't the final word on prepping for google interviews, and I only had one experience there myself, but yeah, I'd say he's pretty spot on here (in fact, the google recruiter who arranged my interviews forwarded me the Yegge blog post, though I'd already read it earlier).
This, I think, is what is called "the Curse of Knowledge". I've taught 2nd year (Assembly) and 3rd year (Intro to Operating Systems Concepts) CS courses quite successfully, but I would have a helluva time teaching a 1st year course.
Like I mentioned in the sibling thread, I've been programming C for twenty years, and learned BASIC on a Vic-20 four yearsish earlier than that (at age 8). I learned all of that from library books.
Mostly, my algorithm for learning almost anything is "look at something that is somewhat magical, and figure out how it works inside". I've been doing that for years and years. Questions like "who programs BASIC? And how?" lead to learning about assembly. "How does BASIC store my program in memory?" "How does it translate what I type into output on the screen?" Etc.
Not to ramble on... unfortunately, I don't know of such a resource, and I don't really know what material it'd cover if I wrote it.
Right. Well, my story is that I'm selft taught (started programming when I was 6 or 7) and thus have been programming as a hobby for nearly twenty years. I decided not to go study CS because I suspected the amount of new and interesting material would be low compared to the time, money and effort it'd take to graduate. Instead, I went on to learn something completely new.
So one of my problems is that I don't actually know what I'm missing out on.
Are we talking onsite loops with 4-5 interviews each? In my experience the challenge with these is it only takes one interviewer to no-hire you for reasons that may have little to do with your technical abilities.
Meanwhile, I do terribly in technical interviews, and I've failed at pretty much all of them. Then in the jobs I've successfully gotten, I always get surprised feedback of how much stronger an employee I turn out to be than was expected based on my interview. Technical interviews that become a game pass on a lot of potentially strong employees.
This is me, too. People react with astonishment when I dive into a new technology, pick it up quickly, and become productive. Interviews are hell, though (and worse than they used to be). I can't sleep the night before a big one, and I tend to be nauseous and jittery during the interview. That doesn't come across well at all.
> I didn't practice for them, I just have strong foundations in CS.
Perhaps my take on things is different since my degrees are in math, so I don't have a bunch of 'canned' algorithms stored in my head, and so in a whiteboard would come up with my own technique, even for possibly basic things like trees / sorting.
I'm sure that even in math you need to know some basic things; for instance every math major knows basic theorems about groups, fields, rings, about real analysis, and so on.
It's the same for CS; basic knowledge of algorithms and data structures, and how these can be composed, is what a technical interview tests.
There's just three sorting algorithms anyone cares about, and they're not particularly complex. Someone with a math background should be able to pick them up in a few hours at most.
And outside of interviews, you will, with high probability, never, ever, have to code one yourself. You'll just call sort(), or OrderBy(), and rely on the battle-tested and bullet-proof standard library implementation.
Exactly, I used python heavily for a while, so don't think I've ever even coded my own for anything 'real' (e.g. outside of project euler or something) - I think the closest I've done on a real project is to code the comparison function and feed that to a sort.
Maybe, but I had to implement Hoare partition scheme which is used in Quicksort a few months ago. If I didn't know Quicksort I wouldn't probably have an idea that this algorithm existed.
I had to write my own tree traversal once. If I didn't know about trees, I wouldn't have had the basic context to do this.
But I did have to spend a few hours looking up and refreshing my knowledge of tree traversal. If I'd taken a technical interview exam on tree traversal prior to that four hours or refreshing my memory, I almost certainly would have failed. And yet I within the day I was able to write the code.
Agreed - my point is that I would be rejected from a job in the morning for an inability to write code that I'd be able to write by that afternoon.
They aren't testing whether you can look it up and do it, they're testing whether you have it all loaded into short term memory, on the spot.
Like a lot of people, I'm tired of having to reload it all and essentially retake my data structures exam. A lot of us just don't want to interview anymore. I know that if I need to, I can write a BFS or find all permutations of a set. If the opportunity is good enough, sure, I'll study up and get ready to do this at a whiteboard, but it's boring and unpleasant at this point, and I might not get or want the job, so at this point, I rarely bother.
Tech interviews are a big part of why tech companies are experiencing a "shortage" of applicants. They're hardly the only reason, but I'm pretty convinced they are a reason.
Even if you had to, the algorithms are so darn well documented there's no need to keep the details in your head. If you really need to implement one, you look up the details.
I agree that the fundamentals are important. In my opinion, half of the coding interview is having strong foundations in CS, and the other is being able to clearly convey that.
I'm still in university, but have managed to intern at a few a places so far and found the critical parts of each interview to be nearly identical. Microsoft and Google asked questions that boiled down to basic data structure problems, and Dropbox asked a simple backtracking problem. The problems weren't ones I had specifically prepared for, but were ones that I could break down because of my foundations in CS.
The only interview I've failed was my first one. The interviewer asked me to implement a Gaussian blur on a small whiteboard; between not knowing the algorithm and not having enough room, I flopped pretty hard. There wasn't a realistic way to prepare for this question, it was just one of those things you had to know at the time.
I too once had only had 4 technical interviews in my life and passed all of them. Then I had my 5th and failed. I've since passed many more for (even better) positions. I have no trouble finding jobs and have never had trouble (despite the occasional, random interview failure).
Given that there is a certain amount of randomness in interviews, of course it's possible to have a streak of successes. I don't look at a die that I just rolled 4 times and never got a 6 and determine it's loaded.
On my team there are two people with CS backgrounds (one PhD, the other MS). There are a couple of PhDs from the physical sciences and one from a more Software Engineering academic background. Without exception the guy with the SE background produces generally better quality code. The CS guys are not arrogant, they know their CS stuff, but their ability to develop software is... underwhelming.
Any possibility you should share some of the questions you would consider typical of your interviews? If you can't share the exact question, could you share what you would consider an equivalent question?
Getting a job and actually performing the job are two entirely different skillsets. There are a whole lot of people who bounce from one three month gig to the next as the people who hire them realize it was a mistake.
