>>"The first round started with introductions, followed by a coding exercise — write a maze solving algorithm. What the fuck?! Seriously?...I am not a recent college graduate anymore"
I wonder if just writing a brute-force maze solver, and then explaining that you are aware better solutions exist...but that you didn't have any memorized, would have sufficed.
If you're sure you don't want the job, turn the tables and say something like "I have no clue. Can you show me?" Most likely, they don't have a clue either.
(Edit: Whoops, I misread you and thought you were saying you couldn't remember the brute-force one, not the more elegant solution. Ah what the hell, it was fun to write. :)
A recursive implementation of depth-first search should only take ten minutes to write. OK, here, I'll do it without looking anything up. Start time 8:55pm.
#include <stdio.h>
#include <memory.h>
const int WIDTH = 32; // adjust to suit
const int HEIGHT = 32; // adjust to suit
const bool WALLS[WIDTH][HEIGHT] = {
// enter maze layout here, true = wall
// this isn't a test of file IO knowledge
// make sure the outer perimeter of the maze is
// fully closed with walls
};
const int START_X = 16; // adjust to suit
const int START_Y = 16; // adjust to suit
const int GOAL_X = 16; // adjust to suit
const int GOAL_Y = 16; // adjust to suit
bool search_maze(bool **searched, int cur_x, int cur_y,
int start_x, int start_y) {
const int DIRS = 4;
const int DIR_X = { -1, 0, 1, 0 };
const int DIR_Y = { 0, 1, 0, -1 };
searched[cur_x][cur_y] = true;
for (int i=0; i<DIRS; i++) {
int new_x = cur_x + DIR_X[i];
int new_y = cur_y + DIR_Y[i];
if (WALLS[new_x][new_y])
continue;
// if moving in this direction lands us on the start
// point, or searching starting here returns true,
// then we're done and our current pos is on the path
if ((new_x == start_x && new_y == start_y) ||
(!searched[new_x][new_y] && search_maze(
searched, new_x, new_y, start_x, start_y)) {
printf("Go to %d, %d\n", new_x, new_y);
return true;
}
}
return false;
}
int main(int argc, char **argv) {
bool searched[WIDTH][HEIGHT];
memset(searched, 0, sizeof(searched));
printf("Starting at %d, %d\n", START_X, START_Y);
search_maze(searched, GOAL_X, GOAL_Y, START_X, START_Y);
printf("Goal at %d, %d\n", GOAL_X, GOAL_Y);
return 0;
}
End time 9:12pm. So 17 minutes (what's that rule about estimating software dev time?), and I haven't run and tested it yet, but it should show what the interviewer wants.
"Being that this isn't my specialty, I would research a solution online as it would provide a far greater business value for the time spent. But you probably want to see me try to solve it anyways, so I let's start with a brute force and improve from there."
Point out that in a real life scenario you wouldn't do this because it is so more efficient to use the work of others, but then solve the problem so they can measure your problem solving skills.
I'm right there with you. There is a lot of FUD on both sides of this issue, it would be nice to know what the reality of tech interviewing is. I can't seem to get passed perfunctory phone screens right now (if I even get those.)
I know of someone who quit his day job, then spent several months studying algorithms, the books about passing Google-style interviews, memorized everything, practised interviews a lot. Then he sent his carefully-crafted resume, scheduled several interviews and flew to San Francisco.
It worked. He's working at a top company for several times his former salary, he had several competing offers with HUGE bonuses and equity offers.
However, I don't know if I have the commitment to do that, and I'm not sure if everyone SHOULD have to do that.
Every employer I've worked for has made the experience farcical. If not at the start, then over time. You interview for one job, and eventually end up doing something else.
A full time career that doesn't pay enough to buy a home. And they say software developers are overpaid.
I think the end-game for me is to just go camping with a laptop or something. I'll code for fun, rather than trying to meet this 'market demand' which provides people with studio apartments, temporarily, in exchange for ~all of their productive hours.
I'd say a majority of those who graduated my CS class 6.5 years ago now own their own home, and that's in the UK where devs aren't as relatively well paid and house prices are high. There are plenty of good employers out there, though they don't spend all their time hiring because they have low turnover.
As for "eventually end up doing something else" isn't that career development? We can't bemoan having non-technical senior managers if some developers don't go on to do that.
> I'd say a majority of those who graduated my CS class 6.5 years ago now own their own home
I think what you mean is that they have a mortgage they'll be repaying for a long time. Houses are still too expensive to buy in the UK with a junior- to mid-tier developer's salary in the UK, even if you went to a place like Cambridge and worked for Google.
> You interview for one job, and eventually end up doing something else.
LOL yeah, that's what happened to me for my last job. A recruiting process that lasted 4 bloody months for an electronic designer position, and when I was finally hired they put me on software testing; not only I had never done this, but I had never heard it was a thing. Anyway, after less than 2 months I was better as this than the CS graduates who had been doing it for several years and they were asking me for help in their work.
But now I have been unemployed for 2.5 years, I made it to the interview stage only once during that time, and I have given up on even just applying to any job offer for the last 5 months because it is absolutely pointless and humiliating to be repeatedly discarded by people who are clueless, who don't give a flying fuck about the persons they "harvest" and lack the basic respect in social interactions (like spending 2 minutes of their precious time answering a question, not blatantly lying, doing what they said they'd do, or even just showing up at the very appointment themselves fixed!).
So yes, in a way, I've quitted and I am getting ready to become a street beggar when all savings are gone. In the blogger case, his situation is too fresh, I don't think his mood of the day will last long for this time (and after all, he got plenty of interviews, at least), but I am really really tired of these completely nonsensical recruiting processes and their humiliating consequences.
> A full time career that doesn't pay enough to buy a home. And they say software developers are overpaid.
The average salary for a "software developer" job posting in my city (Charlotte, NC) is $101k. The average income in Charlotte is $53k. The median home value is $167k. 60% of the value of a home in a year is pretty good.
I've also lived in Sydney, Mannheim, San Francisco, and Seattle, and I noticed similar economics in each of these places (where the salary of software developers tended to be quite high relative to the average income). Do you perhaps live somewhere with a very different trend?
I don't know when you lived in those cities, but things have evidently changed. I've lived in Sydney and Seattle. Median home price in Sydney is currently ~AUD$1 million and median home price in the Seattle area has reached ~USD$0.5 million. Average developer salaries in those cities are certainly not 60% of the value of a home.
I didn't mean to imply that in each city, a software developer makes more than half of the price of a home in a year. What I am asserting is that, in contrast to the previous post, software developers can afford homes in these (very expensive) cities and they can do so at a much higher rate than the average resident.
An average software developer earns about $85,000 in Sydney, so you're right, they're priced out of the central city's market. Senior software engineers make $100-150k, so even they make only up to 15% of a median downtown home.
I lived in Macquarie Park, a suburb of Sydney (which is ~20 minutes by public transit from the center of the city). The median price for a house there is $619k. That's well within reach for a senior engineer, although admittedly more of a stretch for an average developer.
Software engineer salaries in Seattle average $111k. As you've said, the median home price there is about $500k, which is very much attainable for someone earning six figures. The average income in Seattle is $37k, showing that (just like in Charlotte) software developers make about 3x as much as the average resident, and are in fact one of the few groups not yet priced out of central housing.
I should also note that the $53k income is household income. Median personal income is $32k, meaning that a software developer makes over 3x the salary of a normal Charlotte resident.
Tech hiring sucks, and the people who continue to do such a bad job at it seem to wear their behavior and tactics as a mark of pride.
There are a few companies that make it a point to mention they avoid the kind of interviews you've been getting. Perhaps try to seek them out rather than rely on recruiters
The examples that always come up of "stupid interview questions" in this kind of rant: Implement a breadth first search, or reverse a binary tree, or write FizzBuzz. Are these really such difficult things to whip up, off the top of your head? Is it really that unreasonable to want to hire someone who can do so?
Yes, if you need such a thing and it's not immediately obvious how to do it, off to StackOverflow you go to find some example code, but these are basic "do you understand fundamental data structure / control flow" type questions. It's not like they're asking you to implement a theorem prover or something.
If you haven't been exposed to it, it's just jargon. That's the point. You are testing for jargon rather than ability.
It is the distinction between saying 'implement FizzBuzz' and going silent, and actually explaining what it is. As an interviewer it is easy to forget that whilst you may have asked a question 20 times, this may be the candidate's first encounter with your terminology.
No, it's not a test of whether you know it, it's a test of whether you can implement it. If the candidate doesn't know/recall what BFS is, it's trivial to demonstrate the basic idea on a whiteboard, and it's the candidate's job to convert the idea into code. (Which, at the end of day, is pretty much what the vast majority of coding is about.)
It's still not realistic. People don't code on whiteboards. You code (today) with all the resources of the internet at your fingertips, and if you need to invert a binary tree you will use a well-tested implementation from a standard library.
I know for damn sure that, if I'm implementing something algorithmically tricky (not BFS, though), I first sketch the details on a whiteboard or a piece of paper.
It's not supposed to realistic. It's supposed to be a test of programming ability that fits into an hour interview with time left over for talking about other things. Real world projects last months or years. You can't fit that into an hour, so you have to make do with something that can.
Which is why they're not asking you to do it in an actual job. It's a proxy problem that is easy to communicate so you're not spending the entire interview explaining the problem. Arguably, fleshing out a spec would also be a valuable test, but not the same one.
Sometimes actual code too. For instance, if I'm designing an optimization pass for a compiler, I'll write toy IR programs and show how the optimization pass will rewrite them. And I'll do it on a whiteboard.
Most specialized fields have jargon. It is the common language between the practitioners of that field. At what point should a person be expected to know some basic ideas and the words associated with them for the field they work in?
Well, if the knowledge of a particular thing is useful for that job, then yes, that's reasonable.
But we know that most of the time this isn't true. <1% of software developers write sorting algorithms on the job, and even fewer of those actually need to know which one is Bubble and which Quick and which Heap without reference.
If I'm a multinational company, I want my accountant to know what transfer pricing is. If I'm a self employed joiner, I don't.
Problem solving tests are good. Memorization tests are terrible. We have search engines for that.
I think memorization tests of the sort that ask what FunctionX you should use from LibraryY for a particular situation are terrible.
I don't consider asking a developer about basic data structures and their properties as terrible. This is foundational knowledge that is useful for nearly every programming job. Knowing about lists, hash tables, trees, etc and their operations or tradeoffs is extremely important.
Similarly, having a developer that can reason about the runtime and memory complexity of the code they write is important as well.
These are the "lingua franca" things that I was speaking about in my previous post. Even if particular developers think that the above things aren't useful to them, I would argue that they are probably wrong and just don't know how or why they are.
Sure. I know what a list, a hash table, a tree are because I looked it up whenever I saw someone mention it, and eventually internalized it.
But before that, I'd used them for 10-15 years without knowing the name because it doesn't matter. Take a hash table. Python calls it a dict. C++ calls it an (unordered) map. Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing you want in a new language, but otherwise they're just words.
Actually in usage I type {} in Python and it is what it is.
I'm not arguing that these things aren't useful at all.
I'm arguing that the distinction between the CS-ified person that has spent the effort to learn what the words mean to pass interviews is not substantially more knowledgeable or useful than the version of that person that will have to find it out in the future. It's marginal.
Basically it feels like a sort of 'table manners' test. You've put the fork on the wrong side of the plate, so you can't eat dinner with us today, you scoundrel.
Don't take this to mean that I think that computer science is useless. Far, far from it. It is simply that I think that relying on jargon is testing whether someone genuinely has a CS degree (or equivalent without certification). It's not testing whether someone is a good programmer.
If that's what you want, just ask for it. Let's not waste each other's time and money.
The anger here exists because people want good faith interviewing, and instead they get "bloody hell the last 20 people were crap I can't be bothered any more" interviewing.
>> Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing you want in a new language, but otherwise they're just words.
Actually, they are more than just words. Try not to conflate the abstract data structure itself with the language-specific implementations which can vary quite significantly. Also your flippant, dismissive attitude on quite important CS concepts wouldn't take you far. It's better to frame your argument like this ... "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for" which is quite reasonable as most devs CS-minted or otherwise will agree with you. & also while it might not be useful to rote memorize every single CS concept, it's sensible to at least have a passing familiarity. Why? Well, not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.
>> Also your flippant, dismissive attitude on quite important CS concepts wouldn't take you far.
Please try to avoid this. We can discuss without resorting to attacks.
>> "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for"
That's what most people are arguing for I think, so I agree with you there.
>> not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.
By doing this you are throwing away developers that have made their respective companies millions in revenue. It's not hypothetical. One day, a non-CS trained developer will come across a tree and use it. And then they'll learn.
You seem to be arguing that non-CS trained devs can learn these things when they come across them. I wouldn't disagree with that.
I think what I see as the real concern is a case of "not knowing what you don't know." If you aren't exposed to at least the fundamentals of this broad base of CS knowledge you aren't going to know that they are available to you when you need them. Learning about a tree when you first read about it is great. But that person will still have huge gaps in their CS knowledge compared to someone who systematically studied it.
I also don't think this is so much about having a CS degree, as it is simply having studied CS in some fashion. I've worked with plenty of talented self-taught developers who took the time to learn these things on their own.
I think really what we're arguing about now is the distinction between hiring for a Google position (pushing the absolute state of the art) and hiring for a position creating accounting software or something.
I don't think that it's reasonable to expect to be hired into a top tier position as a kernel hacker at RedHat or a database expert at Google with an English degree and a few weeks of github commits.
I think that most software development jobs don't need the level of technical chops that are being asked for - and that many of the developers that actually have this level of ability just don't need the company (this post might be an example of that).
Some of the job requirements I've seen make me think along the lines of - 'hell, if I can do all of that, why would I work for you for peanuts?'.
Hey, whoa, stop right here. std::map and std::unordered_map are not at all the same thing, and if you're going to be using them in a manner beyond "trivial" it's important to know the difference between them.
That's not what happened to the OP. He was asked to code up a solution to maze searching problem. The statement of this problem is understandable by a 5-year old kid.
To a degree this is true, but there is also significant value in having (and retaining) that broad base of knowledge that a good CS program or some systematic personal studies will get you. Most of the time you're not going to get a "implement this algorithm" you're going to get a "solve this problem we have" and you need to know the standard tools that are available to get you to a first approximation solution.
Depending on what their listed requirements were, I think it's reasonable to expect you to know standard terminology, though I wouldn't count it against you if you asked to be reminded of the details for one or two things.
Why would an interviewer assume a front-end dev has a CS degree or has invested personal time in studying algorithms rather than other (probably more) relevant topics, such as various frameworks?
That depends. Mostly because front end job listings still often list a CS degree as a requirement. Also, I think it's great when people enjoy working on the front end since I don't particularly, but I still want to work with people that aren't hyper specialized.
I think you might be underestimating the breadth of front-end skills required to properly develop, test, deploy, deliver, monitor, analyze, and optimize front-end applications. Including the myriad third-party integrations that other teams need, from CS to marketing.
Well, I wouldn't have considered half of those things as part of "front end development" work, but it pretty much drives my point. I'm a firm believer in the idea that you'll be more effective at all of those things if you have a general baseline knowledge of CS, so that if you need to you can (relatively quickly) understand how and why all of your tools work the way they do.
Trees and graphs are fundamental to computer science and there are only two ways to traverse them. I don't know what kids are doing these days, but I learned this because of my high-school curricula.
In other words, it's OK if you don't have a formal education in computer science, but when you don't have it, you need to make up for it by learning on your own, because this is basic stuff that high-school kids are learning. And it's even worse when people do have that education on their resume and don't know BFS, because it means they cheated on those courses.
And what would you prefer for a hiring test? Straight IQ tests? A requirement for public, open-source contributions? Or are you speaking of querying databases and fading out divs? I think we can all agree that neither is entirely fair.
And keep in mind that for all the pain involved in the interview process, the only alternative is optimistic hiring for a test period, except that doesn't work because it causes distress to everybody involved if it doesn't work out. This is why many companies now prefer internships, because thus they are dealing with young people that don't have big expectations.
You're right about learning. Everyone should be doing this ALL THE TIME. Problem solving and learning ability are what you should be measuring and then deciding if their past experience justifies the position/starting rate. This is far more likely to serve you well than testing the finer points of some algo/tech that is simply a building block of a solution to a far bigger set of business/technical challenges.
But you cannot measure problem solving and learning ability without relying on a set of common knowledge to use in your tests.
Again, are we speaking of giving out straight IQ tests? I think there's plenty of people that would be against that, plenty of people that consider IQ tests to be fundamentally flawed. And if not IQ tests, how do you measure problem solving and learning ability?
Maybe you give the interviewee something to do, like an algorithm or a piece of code to develop on the spot, right? But maybe your personal expertise doesn't match with what the interviewer wants or needs. And the interviewer has to give you some problem to solve in some way.
I remember that at a coding interview I was given the problem of programming a Lego Mindstorms device to detect obstacles and do stuff. But then the problem was really about reading a document on the C subset used to program the device, along with the several couple of functions needed to control the motion and read the sensors. Was that measuring learning ability in any way? Of course, if you think that the skill of reading a technical document with precise instructions is so rare. But that wasn't real world problem solving.
So how can you test real world problem solving? Do you give candidates a homework? Ah, but then you run into another problem: the good candidates, the ones that might actually solve your homework, are rarely interested in spending their time on such things, because most good people already have jobs and a life and things to do and you can consider yourself lucky if you get their attention for a couple of hours.
In that light, I don't think it's that unfair to give problems to solve that rely on basic algorithms and data structures, especially for companies where the problems solved are much harder than that.
I think fundamentally the idea of paying developer X 40K and developer Y 80K (because developer Y has been twice as effective in the past) is broken, because it negates the impact of environment.
If you pay someone 150K GBP in London they can live next door to the office, have TaskRabbit like services perform all household tasks for them, and spend their time exercising and reading 24/7. They will kill it.
Pay them 30K, and regardless of pedigree, they're going to struggle.
Somewhere in there is a balance and I argue it's far less to do with certification and more the circumstances of life which as an employer you have huge discretion to influence.
Basically, it's about steelmanning. Why is someone bad? Is it that they're inherently genetically dysfunctional? Or is it that they haven't been coached well or have a difficult environment?
Given good faith, most of the developers I know have the ability to be amazing. I include myself in that (am I that good? dunno, impostor syndrome innit). But they are stifled by needless nonsense. Management, open office, low pay, commute, stress, basically. Kill the stress and you get your '10x engineer'. Keep the stress and your '10x engineer' turns into a chocolate mousse.
Are you sure you replied to the right comment? :-)
From my point of view, an interview really isn't an exchange between equals, but a meetup where two parties meet, state their demands and evaluate each other. It works in both directions of course.
So first of all, I'm not hiring :-P
I see your point though and I don't agree.
First of all, the point of the interview isn't to determine whether somebody is bad, or improperly couched. Surely interviewers would love being able to do that, but it's not possible to do it in a couple of hours.
During the interview all you get to do is to apply a noise filter to get rid of the incredibly bad ones. Because without that filter you can get people that are a very bad fit and that can cost you the project and the morale of your existing employees. It's incredibly taxing to fire somebody. Every time it happened to see a colleague being fired, internal discussions, personal attacks and bad feelings happened internally, every single time and not just at one company. And then in big corporations, because of the risks involved in firing people, you get an even worse effect - you see them "promoted".
And with a noise filter you can naturally have many, many false negatives, as in people that are in fact good, but won't pass the test and interviewers are willing to have that risk, instead of risking false positives.
Of course, from what you're saying, I think you believe everybody can be great. Well, yeah, I think everybody can be great at something useful, but not everybody can be great at something specific. We software developers are too idealistic at times. I don't see surgeons going around telling other people that everybody can be a surgeon. That would be a preposterous thing to say.
On the other hand I do think that if companies want good people, they should invest in education.
> The whole principle here is that there exists a growing portion of developers who can't be bothered with interview ping pong.
I can agree with that. I'm not into interviewing myself. I'm not into switching jobs that often either. I can't be bothered with that because I've got satisfying things to work on already. Capitalism and the free market cuts both ways, right?
I've been programming for ~8 years as well and have implemented BFS multiple times, especially in occasions where I have to travel nested data structures and want to print them in a specific order.
BFS and DFS are the bread and butter of tree/graph problems and every software engineer is expected to encounter them at least once in their life. What if you want to debug a complex data structure or just a tree and want to print out its contents in order? Is it really such a weird thing? It's akin to asking to do a for loop through a list to print the elements, except slightly more complex (but certainly something that should be achievable by intuition rather than by memory).
I guess I should rephrase. I've been programming for ~8 years and I've never been presented with a problem that insisted I know what BFS was explicitly.
It is intuitive, which even further pushes the question "Why do I need to know this to be an effective programmer"?
You don't need to know BFS, you need to show that you can come up with a BFS implementation if you need to do so. You can always say "wait, remind me again, which one was BFS?" and the interviewer can certainly tell you at least what the conditions are. Maybe he might think a bit less of you (although I personally wouldn't) because BFS is a really really common name in the jargon of a programmer, but still it's better than simply blanking out and then angrily claiming that it's unfair to ask BFS.
A similar question could be "Can you print in order all the elements of a given tree/graph?", would you find that more fair compared to straight out using the word "BFS/Breadth First Search"?
Yeah, I think presenting the actual problem rather than a jargon test is a better way of determining a programmer's competency, but even then I'd prefer to ask questions specific to the problem domain, like if you're a streaming company ask about compression algorithms.
My favorite questions are when companies ask actual problems they're having and try to get the interviewee to suggest solutions and/or implementations.
How can anybody have knowledge about compression algorithms without knowing what BFS is? This is like claiming to be a mathematician and not knowing what rational and irrational numbers are.
You speak about the problem domain, but the primary problem domain we are facing first is programming. And without a shared vocabulary, you can talk with other software developers, but you aren't going to be very efficient in that communication. So going back to the problem domain, as software developers we are supposed to master whatever problem domain we are facing, in order to efficiently communicate with the business side in their own domain-specific language. How are we supposed to do that if we haven't even bothered to learn our own domain-specific language?
But it goes deeper than that. Many software developers these days rely too much on libraries, without knowing how they work. And this hurts them a lot.
This is all about standing on the shoulders of giants. And it all starts from the most basic data-structures and algorithms. BFS is right up there with the characteristics of a List or a Map. It's common knowledge that everybody should know. And this common knowledge is half of "Introduction to Algorithms" by Cormen et al. So instead of reading another fluffy piece on Agile methodologies or on soft skills like the "Pragmatic Programmer", or other such bullshit, maybe people should read this one instead.
One recent problem we had was one of scaling out our micro-service-based infrastructure. And I've heard from colleagues wild ideas like "oh, lets introduce an external queue, like Kafka". DevOps for some reason think external queues are the solution to all problems. Yeah, great, but this isn't a freaking webpage reading from a database, we've got singletons, as in producers of truth that need strong consistency in their decision-making because we aren't that smart and you're just moving the problem around, because locks don't freaking scale, no matter how smart your queue is. Or "we'll just add Akka Cluster or Finagle or whathaveyou, should take care of it". Dude, yeah, we've got singletons, which means we need to do sharding and have a protocol for failure detection, so maybe we should talk about that first.
This is just a recent example. Developers are so eager to jump to the latest fads and the latest cool things, without thinking for a second if those solutions would work, only because they can't imagine how these tools are even implemented. And this isn't something that a superficial Google search can fix, because the unknown keeps piling up, the more complex the system is, until the shit hits the fan and you throw your hands in the air and bring in external consultants to fix it. And if you think the UI is spared from all of these problems, think again. I've seen dozens of Javascript-enabled interfaces with performance issues, only because of the "thundering herd" problem happening due to sloppy event handling. How many UI folks understand how Facebook's React works? Not that many.
Because it's not intuitive to some people. Some people just don't 'get' it. The assumption is that such people are probably also not good software developers.
Given time alone in a quiet room with a computer, these are not huge demands. Trying to do this in front of people, on a whiteboard, with limited time, and having to explain yourself to idiots is indeed, the very definition of "stupid interview questions". This would, however, work great in other professions. For example, why don't we test surgeons' skills by giving them a chainsaw to cut up the patient with, in a room full of germs, while they have to explain to a 3 year old what they're doing? Oh, and always ask the surgeon to operate on a body part he doesn't specialize in, hasn't worked on in 20 years, and will likely never work on in his lifetime. This would hire us great surgeons because it hires us great programmers! I mean, just look at all the amazingly good code out there!
I had a disastrous phone interview this week throughout which I remained calm and focused but immediately after putting the phone down I emailed the recruiter to say I wasn't interested.
The "Technical" part was just trivia. Never-mind that I was sat in front of a computer and could have googled everything asked, I chose not to do that.
So yes, I stumbled when asked "what does the using keyword do". I explained how it relates to IDisposable, disposeing the object at the end of the block scope and avoids needing try/finally blocks.
But clearly that wasn't the script, because they kept asking "Are you sure it doesn't do anything else? Are you sure isn't used anywhere else?".
Eventually I realised they were talking about "using System.Linq" etc, and all they wanted to hear was the word "namespaces".
Talk about interviewing by numbers, had I wanted to I could have googled every question and given them perfect descriptions.
What could they possibly have learned from that interaction? I learned I didn't want to work there, so it helped me I guess.
But I find implementation things more helpful (in person, not by phone!), because it's not about whipping out the right answer, it's about watching how the candidate thinks and approaches problems. It's about how they work not the end result.
I like the "write a function to multiply" because it can be extended to any level. If someone aces the positive numbers case you point out negative numbers, if they ace that you can talk about efficiency, or bounds checks, exception handling, efficiency or whatever else you think they'd like to talk about.
The first Google phone screen for SRE candidates is so scripted that you can probably Google the questions and get exact answers. It's been years since I've had it, but I remember it being the exact same questions, about UNIX internals and TCP/IP.
This type of recruiting seriously turns me off because you can tell they're hiring minimum wage call center workers to read a script and filter out the 9/10 candidates that can't answer a few administrivia questions. It makes me think of them more as an industrialized recruiting center than a company that actually cares about their workers, which is probably the wrong message to send to potential employees.
The first Google phone screening for SRE candidates is usually done by a technical recruiter who doesn't have extensive technical knowledge but at least knows the basics and is able to talk with you about the answers you give (albeit not in as much detail). It's supposed to be easy and it's to filter out people who lie on their CV or really don't have broad superficial knowledge.
The follow up phone interviews are what really matters (before the onsite of course) with actual engineers and go more in-depth with coding questions (among other things) at least.
I remember my recruiter was a really knowledgeable guy and he knew his stuff even though he wasn't an engineer. We had a nice chat and he was able to keep up with my (basic, obviously) responses of how TCP works, how to implement inode-based filesystems or whatever information you can read out of a stat call... Nothing too fancy but still it didn't sound like rehearsed script to me.
In my opinion Google absolutely does care about their employees. However, if you are turned off at the first contact, this company might just not be for you.
At the end of the day, it is not about what the company can do for you, it is about what you can do for the company.
I'm currently considering jobs directions too and finally have a name for what I'm experiencing. "career interview fatigue", it's probably similar to whatever performing elephants in circuses experience right before they snap.
I think it comes from a decade of experience of being asked to jump through increasingly ridiculous hoop sizes over time, and complicity cooperating with this nonsense system in an otherwise analytical logical calling.
Hiring isn't broken, dude. You just don't interview well, and you seem antagonistic even to the idea that your cachet and skills, insofar as they exist, aren't useful to the market. That's a problem -- for you.
Interviews exist because employers need a way to quantify and qualify your ability. Typical computer science problems are a (flawed, but concrete) way of doing that. No reasonable interviewer expects you to recollect breadth-first search flawlessly, on demand, onto a whiteboard. But they do expect you to be able to reason from a problem statement to something approximating a solution. That's fundamentally what programmers do. You should have the chops to think in this way, and you should be eager to try. Emoting "what the fuck?!" and claiming you can't, or won't, because you're not a recent graduate is an excuse and a cop-out.
A few popular open-source projects don't necessarily speak to your talent as a programmer. A 960 day GitHub streak is trivia, not a signal of anything useful. (If anything, it marks you as a target for burnout!) A few Hackathon wins and a couple hundred GH stars are the artifacts of a successful hobbyist, not a proxy for professional ability, or a gateway to employment.
Additionally, a good programmer (or worker in general) should be good at much more than programming; like being able to collaborate & socialize with other team members & management without immediately resorting to "Fuck you, I quit".
The author seems to have a chip on his shoulder...
Zero(?), but I have also never had a "great" job that I had to fight for. Regardless, I think everyone knows through experience that an employee's technical skills are practically useless if said worker is socially inept.
Sure, but what I was trying to get at is: if you had a string of interviews that felt "bad", and/or rejections, that you would probably be a little sour, and that's what I get from the article. It doesn't strike me that the author is particularly socially inept.
As someone who watched previous coworkers, who are older, go through the interview ringer, I can sympathize with the author on the pigeonhole one can get stuck in due to seemingly trivial reasons: I don't have a classic CS background, people think I'm past my prime, etc.
These aren't imaginary problems, and I struggle to believe that I would be all "go-getter" and "pull yourself up by your bootstraps" after continually being rejected, too.
And what are your social skills? You, who can't even see that the "fuck you, I quit" attitude does not come up first out of nothing but after a series of rejection and nonsensical situations, i.e. that it is a consequence of successive experiences and not the reason of these experiences. You, who decide unilaterally from your failure to understand the logic of events in a blog post, that the blogger is once and for all "socially inept". Great social skills without a bit of understanding and empathy, no doubt.
Gee, I am also very tired of people for which stuff went well, and think it is be the same for others. Can't you even imagine there is a variety of situations out there? Can't you imagine it may happen to you one day? Do you think people who encounter this kind of problems never had a shiny position earlier, and their "social skills" were considered perfect before some conceited internet stranger decided they were "socially inept"?
And you dare to talk about "experience", seriously?
You started your post with a veiled ad hominem attack, which instantly sets an illogical, angry tone... :( Yeah, I have no social skills, so what? I may also have a below average mind, so what?
I did not call the author "socially inept"; that sentence was a hypothetical example of how an individual's incredible technical skills can be overshadowed by other problems.
I am sorry if I offended you. I thought my posts were critical but logical...
I don't think many software engineers deal with "computer science problems" in their everyday jobs.
GitHub stars are worth much more IMO. It shows that other developers value your work. That says a lot.
In the end, we have to realize that most developers are just average. Why go through the ridiculous process of finding average developers who by luck (or some homework) happen to solve the problems you throw at them perfectly?
Most developers are average and most jobs are average. How many people really get to think about breadth first or binary trees daily? Most of us spend their days wondering why Chrome doesn't render a div in the expected way or why some API doesn't do what it should and finding workarounds.
> Why go through the ridiculous process of finding average developers who by luck (or some homework) happen to solve the problems you throw at them perfectly?
Never underestimate the value of hard work, preparation, and a can-do attitude. It eclipses natural talent every time.
The hardest workers with the most successful can-do attitudes will simply reject your company if you ask them to do bullshit like algorithm trivia or HackerRank tests.
Such trivia is the opposite of useful hard work; preparation for it truly wastes time that could be better spent on other things; a can-do attitude would imply rejecting or ignoring requests to do such things.
As a result, the people who actually do take the time to complete it will not be completing it because of a good attitude or work ethic, yet you will mistakenly believe they are.
or they already learned it because they worked hard during school and they work hard to keep themselves current.
I think the concerns people have about the efficacy of this interview style is valid, but extending it to the point where you start to make claims about how people who can pass them aren't as good is ridiculous.
No, overfitting is a real thing. Overfitted learning algorithms are generally worse at generalizing their ability to broader examples and new situations.
The types of candidates who spend the time necessary to memorize algorithm trivia for the sake of passing these exams are exactly like overfitted learning algorithms. What they happen to know is unlikely to generalize well. Of course you could get lucky and hire someone like that who can generalize, but that's rare. More often, since hiring is political, you pat yourself on the back for how "good" the candidate is (based on some trivia) and make excuses when their on-the-job performance isn't what you'd hoped, and find ways to deflect attention from that so that you, as an inefficient hirer, won't be called out on it.
Willingness to waste time overfitting yourself to algorithm trivia absolutely predicts worse later-on performance than candidates with demonstrated experience and pragmatism (e.g. I'm not wasting my time memorizing how to solve tricky things that rarely matter. I will look them up / derive them / figure them out when/if I need them).
If given the choice between hiring a math/programming olympiad winner vs. a Macgyver/Edison-like tinkerer who may not be able to explain how to convert between Thevenin and Norton circuit forms, but who took their family radio apart and put it back together, Macgyver/Edison wins every time (unless you're hiring for bullshit on-paper prestige, and of course many places are while proclaiming loudly that they aren't).
> Overfitting generally occurs when a model is excessively complex, such as having too many parameters relative to the number of observations. A model that has been overfit will generally have poor predictive performance, as it can exaggerate minor fluctuations in the data.
> The concepts of generalization error and overfitting are closely related. Overfitting occurs when the learned function f_S becomes sensitive to the noise in the sample. As a result, the function will perform well on the training set but not perform well on other data from the joint probability distribution of x and y. Thus, the more overfitting occurs, the larger the generalization error.
> The types of candidates who spend the time necessary to memorize algorithm trivia for the sake of passing these exams are exactly like overfitted learning algorithms.
I should have asked for a source for that portion. It's the part that is ridiculous.
Sigh. I wish instead of the sarcasm, you actually introspected on the toxic and needlessly aggressive way you're defending rote memorization of algorithm trivia. For example, you saying
> Source? or just trying to justify your own shortcomings?
is clearly, unequivocally unprovoked and needlessly antagonistic (what do my shortcomings have to do with my point ... either you engage with the claim or not, but use ad hominem insults is not a valid discussion tactic. Yet you seem to assume no responsibility for your completely unprovoked hostility, and continue on with sarcasm, even sarcasm about your own ridiculousness.)
The particular sections of the actual study that cover poor performance of those who focus on memorization is not available in the free sample (Chapter 2), but it was reported on, e.g. here: < http://hechingerreport.org/memorizers-are-the-lowest-achieve... >, including this:
> The U.S. has more memorizers than most other countries in the world. Perhaps not surprisingly as math teachers, driven by narrow state standards and tests, have valued those students over all others, communicating to many other students along the way – often girls – that they do not belong in math class.
> The fact that we have valued one type of learner and given others the idea they cannot do math is part of the reason for the widespread math failure and dislike in the U.S.
There is also the discussion from Google that test scores and brainteasers do not predict later-on job success < http://www.newyorker.com/tech/elements/why-brainteasers-dont... > (and many algorithm interviews are absolutely the same kind of brainteaser nonsense).
From the NY article:
> The major problem with most attempts to predict a specific outcome, such as interviews, is decontextualization: the attempt takes place in a generalized environment, as opposed to the context in which a behavior or trait naturally occurs. Google’s brainteasers measure how good people are at quickly coming up with a clever, plausible-seeming solution to an abstract problem under pressure. But employees don’t experience this particular type of pressure on the job. What the interviewee faces, instead, is the objective of a stressful, artificial interview setting: to make an impression that speaks to her qualifications in a limited time, within the narrow parameters set by the interviewer. What’s more, the candidate is asked to handle an abstracted “gotcha” situation, where thinking quickly is often more important than thinking well. Instead of determining how someone will perform on relevant tasks, the interviewer measures how the candidate will handle a brainteaser during an interview, and not much more.
The other thing we have to fight against is self-selection. It's not necessarily in everyone's interest to publicize that their riddles and algorithm hazing process isn't working. Especially not for start-ups which need investors to feel like they are crammed to the brim with stereotypical nerds or something. So if you go looking along the lines of "well, my company uses riddles and we have hired well" you're already done. You haven't hired well. Your company (if it's a startup) probably isn't even remotely proven yet, even if it's well-funded, and the verdict is out on...
Totally disagree with the final sentence. Most math/programming olympiad winners are way more than capable of handling anything the Macgyver/Edison type would be good at. At least in my industry, every olympiad winner has been a consistently spectacular performer, and I have absolutely no qualms heavily biasing myself towards that credential.
Having worked with some such folks in a quant-focused field, I can say that their performance was no better than average and in some cases worse. After a few hires like this, my boss actually pulled me aside and asked me to take over one of the main hiring projects because he and a few other managers were unhappy with the way the emphasis on this type of paper credential had failed to produce good enough analysts, and they wanted a process more focused on probing someone's experience and ingenuity. I didn't enjoy it at the time, but that 9-month project focused on that team's hiring needs (which took me away from some of my technical projects for more time than I liked) ended up teaching me a ton about what candidates in general look like (at least for that type of firm).
But I grant this is reasoning just from the anecdata that I have. I can believe that winners perhaps represent a higher degree of skill, but then we're talking about an extremely small number of people.
Generally you're facing a tradeoff where you have to choose between a sort of rustic self-reliance skill set versus a bookworm skill set. People from either group can learn the other over time, but you can't predict how well by testing them solely on trivia that constitutes their current main group. My preference is to hire for self-reliance and learn bookworm stuff later. I used to believe the opposite (e.g. hire someone good at math because they can always learn to be an effective programmer later) but my job experience made me believe the opposite (e.g. actually it's pretty easy to teach people stochastic processes, machine learning, or cryptography, but it's incredibly hard to teach people how to be good at creative software design).
But in original author's interview recaps, it's pretty evident that he's NOT comfortable "generalizing his ability to new situations". A BFS is not a super exotic, highly specialized algorithm. It's pretty much a bread-and-butter application of general principles (linear search of children + storing away hypotheses for later).
there's nothing 'current' about BFS. It hasn't changed. You'll never write one to meet a real, work-related need. It's just a memory test that puts recent grads at an advantage.
> Easier to take 20 minutes and just write the tool.
What? That would be a huge red flag in my book. Where are your unit tests? I'm not trusting your 20 minute off the cuff reproduction of classic algorithms in any business critical piece of the code, not ever.
This would get you booted from a lot of places, or at least given a stern talking to for doing something that seems slick, cool, and time-saving in the short term (yay, let's roll our own!) when really it's immature and time-wasting in the long run.
Never (!) homebrew that shit unless you have to (like, you're in an embedded environment or your use case requires some bleeding edge research algorithm).
It's like seeing someone write their own argument-parsing code. Holy shit, what a bad idea. Never (!) do that.
If you did write your own argument parsing code, then yes the choice to commit to that was incompetent, barring some extraordinary situation.
I don't think it's controversial or insulting to say so in the least. It's a solved problem in every major language and most fringe languages. Spending time re-inventing it is just obviously wrong.
It's not insulting or judgmental to say that it's wrong. It's just a fact. I do not understand being offended or angry about my statement of that fact. If we're talking about what is effective engineering and what is not, writing your own argument parsing tool for actual business usage (as opposed to doing this as a pedagogical side project or something), without evidence of some exceptional corner case, is ineffective engineering. It's practically the definition of ineffective engineering.
The pseudo-code of BFS is all of 20 lines, and that's accounting for a graph possibly containing cycles. A graph without cycles (such as a tree) would be even simpler/shorter.
Correct arg parsing is actually significantly more complicated in comparison because of all the possibilities and edge cases.
> Never (!) homebrew that shit unless you have to (like, you're in an embedded environment or your use case requires some bleeding edge research algorithm).
I can't help but think this mentality is what lead to the recent left-pad debacle
> I can't help but think this mentality is what lead to the recent left-pad debacle
It borders on category error to compare homebrewing argument parsing with an overreliance on microframeworks extending all the way down to leftpad. Argument parsing is almost always supported directly by the language implementers in a standard library. And even if it wasn't, it's such a critical task with huge overhead for handling corner cases, cross-platform details, etc., that the value of a central implementation is obvious. A left pad operation ought to be part of the standard language (which is actually what the leftpad debacle was about, Javascript's incredible failures as a language), but it's too trivial to compare it to something like argument parsing.
> The pseudo-code of BFS is all of 20 lines, ...
If it's only 20 lines, that's great because it means it was easy for the other 500 library writers to write it, write tests, and observe and fix issues over time. So, whew, that's 20 lines I totally shouldn't waste my time on, plus unit tests and routine maintenance I don't have to commit to.
And also, given the wide acknowledgement that a good programmer should be writing at most a few hundred lines of code per day (otherwise it's probably mostly junk), 20 lines of code is not trivial.
Probably most programmers write a whole lot more than that per day (especially if counting copy/pasted code), but this is in part a sign of a bad programmer, or perhaps more so a sign of the anti-quality constraints placed on them by most employers.
What the hell sort of library would you crack out to do a breadth first search traversal? This is my main problem with the OP, BFS isn't some arcane complex cryptic algorithm, it's a way of moving through a data structure that becomes natural and very obvious when you think about how you can effectively traverse it for some tasks.
If I were ever to want to traverse something in a breadth first search manner, then I would just write it. It would take longer to search for another library and read how it's somehow implemented this search than it would to write it, test it, get it reviewed, and we've still avoided adding another potentially crappy dependency to our project.
It's not category error to compare this to leftpad. leftpad actually makes more sense imo, as it's a common microfunction that may be used more than once. BFS is typically far more coupled with the underlying data and is more naturally written inline.
> we've still avoided adding another potentially crappy dependency to our project.
No, you've just added the crappy dependency == your off the cuff implementation (which is even more work since you have to handle issues and unit testing for it too).
> What the hell sort of library would you crack out to do a breadth first search traversal?
In Python I would use networkx probably, unless there was a good reason I couldn't (such as working in an embedded environment where I couldn't install large libraries). It ought to require an exceptional circumstance to stoop to implementing it myself.
Tell me, if we switched from talking about breadth first search to, say, inverting a matrix with Gaussian elimination and pivoting, do you feel the same? Are you going to trust your implementation over something you can get from netlib?
In the case where you'd require a bfs to traverse a graph, you're already doing something that is algorithmic, and will otherwise be prohibitively costly if explored in a dfs manner. The most complicated part of this algorithm is highly unlikely to be the bfs itself, with it's highly likely 10 lines of code in total.
In this case, someone who didn't have the time to visualise exactly how the bfs is operating shouldn't be writing the algorithm. Pretending like you don't need to know the details of how it traverses the tree when you needed to choose the specific implementation for this algorithm to be performant is a lie. It's not like Guassian elimination, where the concept is far more abstract, this is a concrete idea of how you're moving through the graph and shouldn't be some black magic.
On top of this, who writes this code and doesn't test that it does what you expected it to do on sample data. If you bfs implementation was bust, then you'd miss nodes or revisit them, which becomes immediately apparent from testing the algorithm you're writing.
> It ought to require an exceptional circumstance to stoop to implementing it myself.
Maybe the problem here is that I see a bfs as a fundamentally simple algorithm. Saying writing it yourself must be an exceptional circumstance sounds about as crazy to me as saying no-one should ever use for loops, they expose you to making mistakes with an index you may forget is zero-based, please use anonymous iterators instead. When something takes 5m to write, is heavily tested by default (as it will be a feature under test anyway and possible flaws will be highly obvious) and is at the same level of abstraction as the code you'll be writing around it, then just write the damn thing.
EDIT - Try writing a BFS that operates on an acyclic graph that outputs the value of each node, that compiles and runs and prints at least two node values that has a bug. Try writing bugs into this, it's actually difficult to screw up.
> Maybe the problem here is that I see a bfs as a fundamentally simple algorithm.
Yes, this kind of hubris is often the root of the problem when so-called 'simple' algorithms get homebrewed, then later on unexpected corner cases pop up, testing isn't adequate, you didn't implement it in an extensible way, your implementation is unacceptably inefficient, etc. etc.
> On top of this, who writes this code and doesn't test that it does what you expected it to do on sample data. If you bfs implementation was bust, then you'd miss nodes or revisit them, which becomes immediately apparent from testing the algorithm you're writing.
Yes, but the point is that testing isn't free. If you commit to writing your own implementation of something to interface with whatever larger business / domain-specific project created the need for it in the first place, then you have to dedicate not just the time to write it, but also the time to test it, and to test how it integrates, and to maintain the API for it and maintain its integration (possibly backward compatibility, etc. etc.)
If you adopt a standard to use a certain library, then up to the degree to which you trust the library, those problems are mostly offloaded to others. For things like classical algorithms, the libraries are extremely trustworthy, so many of the pitfalls of adding a dependency don't apply.
> In this case, someone who didn't have the time to visualise exactly how the bfs is operating shouldn't be writing the algorithm.
It's not about being too pressed for time. Even if you had all day, it's a poor use of time to create more future work for yourself by yoking yourself to all the extra responsibilities that come along with rolling your own. Yoking yourself to those responsibilities should require an exception reason for doing so.
> Saying writing it yourself must be an exceptional circumstance sounds about as crazy to me as saying no-one should ever use for loops, they expose you to making mistakes with an index you may forget is zero-based, please use anonymous iterators instead.
This is an extremely fallacious comparison. Basic control structure are built in features of the language. You don't have to test or maintain the runtime execution of a for loop, that's the job of language designers. Making mistakes in the usage of something (like an off-by-one index) is completely non sequitur to this entire discussion. I don't see how you would think that type of bug is related to anything I'm saying.
In general, you also assume a much higher fidelity of testing than what happens in the real world. In 99% of software jobs, you'll be extremely lucky if someone even documents their homemade BFS algorithm, let alone writing even the most superficial of tests. Expecting them to give you an adequate bank of automated tests is like believing in the Easter Bunny.
> Try writing bugs into this, it's actually difficult to screw up.
Yes, people will write them; the fact that you do not means nothing. Software field is large, do not project your experience onto the rest of the industry.
Tree traversal is such a basic algo that anyone who's done any amount of programming shouldn't have trouble working out how to do it, depth- or breadth-first, even if they haven't done that before. If a potential candidate can't figure that out, even in a simple pseudo-code, and even with guidance from an interviewer, I can't imagine ever hiring that person.
Next to arrays and lists, trees are such fundamental part of computer programming that I can't find an excuse for not being aware of some basic operations. I am not suggesting here that the RB or AVL trees and all the tricky stuff about them should be your bed time reading, but a certain baseline should be established.
Many highly skilled and experienced programmers would struggle with this kind of thing in a whiteboard interview, but then if hired would be very good at the job.
The interview scenario is just not similar to on-the-job coding. It has different social pressures, time pressures, access to help, access to privacy, etc. etc.
Plus, for someone like me (I studied machine learning and stats, and all data structure knowledge is self-taught post college, yet I have 6 years experience writing scientific code, performant database stuff, etc.) I am always hearing about data structures and algorithms that are supposedly "fundamental" but I never even heard of them before and have yet to need them in a job.
Basically, all of my experience, and all of the experience of hiring software developers in any of the companies I've been in just completely suggests what you're saying is actually not true. It's just a story we tell to allow us to keep our crab mentality hazing rituals.
GitHub stars are a popularity contest that has little correlation with the quality of your work. You get them when lots of people happen to look at your GitHub profile, for one reason or another. I recently discovered this when a project of mine [1] that had been on GitHub for six months got starred by a prominent open source developer at my company. Within the next week, 50 random people came through and starred the same project. It's not my best code, it's not complicated, and I doubt most of those people ever tried it. Instead, they starred it because they're the kind of people who happen to star a lot of things, and they saw it from somewhere else.
I'm always happy to get a kudos on GitHub. But those of us who don't play the game of promoting our own code on social media, or who have code we can't post on GitHub, would be at a significant disadvantage in a hiring process based on that metric.
"The first round had four interviewers in the room. It was an open-ended discussion about me, my accomplishments, my projects. To be honest, I was not prepared for this interview format, so my presentation was probably all over the place"
A professional programmer, the one hired by a company to work alongside other professionals - as opposed to one working by themselves on small projects - is capable of presenting previous experiences and applying them to new problems. Unless you want to be put in the basement and handed small chunks of work to solve. It's about how you mentor juniors, resolve disagreements on how to proceed, deal with set backs and changing requirements.
Given the whole post is about how terrible the interviewing process is the above quote is the most telling, and backs up the GPs point - not being prepared to have a conversation about your previous experience when interviewing for a job is pretty bad.
Of course they're unrelated. The interviewer asking this doesn't expect you to write these algorithms all day, they want to know that you have the basic mental dexterity to figure things like this out. They are, ideally, abstracted problems of the complexity that you'd be expected to be able to solve on your own.
There are some positions where you don't have to care if people can really problem-solve; as long as they can tweak CSS until it works right-ish, or know the particular arcane implementation details of installing some WordPress module, they can do the job. But there are a lot more positions where you want someone who can solve the problems that need solving, pick up new technologies as needed, and just generally be a flexible and productive contributor in a way that doesn't relate to the fiddly details of one particular technology.
> they want to know that you have the basic mental dexterity to figure things like this out
If you have the "mental dexterity" to coming up with your own solution which is identical to Dijkstra's pathfinding algorithms in terms of complexity within an hour interview, you are a god among mortals.
And that's what they expect - a solution to a problem that is equal to the best minds of our field. I say this from experience: I was expected to do exactly that, and criticized when I came up with a O(n^3) instead of O(n^2).
Solving a maze isn't identical to Dijkstra's algorithm. And Dijkstra's algorithm was specifically chosen to be an easy problem with an understandable answer, to show off a new computer. It was never some grand unsolved problem. Yes, it's reasonable to expect somebody with a modern data structures education who mysteriously hadn't heard of it to be able to invent it. Or to reinvent it, having forgotten it, because it's your basic breadth first search with care taken not to get "lost in the woods."
They aren't asking those questions to see if you have mental dexterity. They are asking them as they asked hundreds of people that same question before and kid themselves to thinking it is an objective measure as, well, everyone working at the company passed it and everyone here is a 10xer and so if you don't pass it you are a loser.
I think that's an unfounded and problematic stance.
Front-ends almost always involve working with data. It is increasingly common for front-ends to have filters, searching, sorting, etc... of that data as well.
Doing that efficiently is key to ensuring a fast, responsive UI.
Wrangling with divs and CSS may take a disproportionately large amount of your time but that doesn't mean it's the most important skill to look for, nor does it mean the CS questions are somehow irrelevant to the work.
Complaining that breadth-first-search is irrelevant to frontend dev seems concerning to me. The DOM is a tree; so are JSON structures; so are website directory structures; so are half the data structures you will encounter in most businesses (departments, categories, etc.). You WILL need to traverse a tree in a frontend position at some point. I absolutely want to know whether a frontend developer has a variety of tools in their toolbox for handling tree structured data - and ideally the ability to refactor between recursion (using the call stack), explicit stack descent (which will be depth first), and queue based descent (which will be breadth first).
That would be incredibly rare to implement a breadth first algorithm in front end work. I mean you could pick any question about the most obscure browser quirks would probably be more relevant.
Hiring IS broken, unfortunately everyone isn't realizing it simultaneously, so half of us end up speaking about it to the other half who are already employed and feel the need to justify their employment. Since these discussions never happen out of CS / IT circles they very rarely propogate upwards to changing company practices unless the CTO/CEO happens to read HN.
You're just further contributing to the rigged scenario when you respond like this.
IT (By IT I'm talking about my industry, I'm an IT administrator, not programming) hiring is based a lot on certifications, certifications which are abundantly easy to scam.
You can find full exams with answers of CCNA and every Microsoft cert imaginable, I've worked for companies that incentivise certifications, and i watched coworkers use these 'tools' en masse to gain easy pay bumps and pad their resumes.
I've had two interviewers ever to ask me technical questions that actually tested my knowledge or capabilities. I look good enough on paper so usually interviews are with a couple managers and if there's a culture fit I'm in. Doesn't matter if i dont know a damn thing, if my resume says MCSE on it.
Microsoft and others further incentivise these certs by giving bonuses and breaks to companies employing certified individuals.
If you think people being hired because they passed a test they cheated on is 'more objective than other fields' then maybe i just have a warped view of how objective other fields are
I've let mine lapse completely to weed out companies searching only for major certs, i'm not interested in competing with cheaters.
Vastly fewer responses and recruiters on major sites, but i've got about another 6 months to go on a really interesting couple of projects at my current job, so I'm not too upset about it.
I've worked for several MSPs this is my experience.
They are very keen on getting employees with existing certs or getting current employees to actively be getting more certs.
There are specific incentives from microsoft based on how many employees have certain levels of microsoft certification. it comes with discounts and marketing materials/privileges (Who doesnt want to say they are a Microsoft certified Gold support partner?)
As such, it is conveniently ignored that the guy with an MCSE isnt going to get fired because their gold level partnership lapses if they dont keep X number of MCSEs on staff
In my experience I wouldn't say they were complete crap or didn't care at all, but I'd agree with the notion that they're a poor indicator by themselves.
When my team would look at candidates, past accomplishments and projects counted for tons more than a cert. Still, a cert told us what someone was interested in and what they wanted to bone up on. They could expect questions relating to that cert field during the call. If they had trouble talking on the subject, then we knew that the cert was likely there to be a pad or just something to fulfill some billet requirement. In good cases we'd find that the cert was an indicator of something they were passionate about.
So I consider it a pointer of sorts. Never worthy of hiring someone on it's own, but I'd recommend them to people who are /ready/ to demonstrate knowledge and may not necessarily have the project experience otherwise. I'd just recommend to them that they be ready to talk to it in an interview.
>* being hired because they passed a test they cheated on*
The certificate shouldn't matter in the interview itself - it is just a way to pair down the choices of who you interview when you have many candidates. If you have knowledgeable people in the interview process (i.e. at least have a dev present for a dev interview, not just managers or HR people) then you should be able to catch those that don't really have the skills.
Heck, even people who genuinely have a certificate might be rubbish overall but revised well for the exam days - you'll hopefully weed those out in a good interview process too.
>The certificate shouldn't matter in the interview itself
Have you had many IT interviews? I have, they are vastly non-technical interviews.
Unless you count "have you ever used #CommonSoftware? how about #SlightlylessCommonSoftware?" as a technical interview.
I'm an IT administrator, not a programmer, so i'm speaking to my experience in that field, I am not trying to make any claims about how programming interviews work.
I've never had a whiteboard in an interview, I have in two interviews ever been asked to walk through a diagnostic process for problems, or asked any infrastructure or network design/architecture questions.
Its worth noting I work and live in Detroit Michigan, so I'm not exactly interviewing with major technology companies regularly. But I have worked for MSPs which glossed over technical interviews in favor of culture fit as well. (MSPs are especially incentivised to have employees with certs, they get discounts and kickbacks)
The discounts and kickbacks matter far less than referrals from the major tech company vendor for, say, integration work that's contracted. Most tech work outside major cities comes down to basic IT or contracting for the big tech companies that don't want to deal with enterprise drivel.
I downvoted you because your comment was off topic. The discussion is about the interview process for business application developers. That is a very different role than what you do.
Not really - these kinds of interviews are about hiring "People Like Us", i.e. recent college CS graduates who the interviewers like right off the bat (are they going to strongly recommend someone they don't like). It discourages diversity, reinforces ageism, and creates a stagnation in the company doing the hiring.
I've seen this directly happen - the interviewers were two Asian and one White male, who came to this job as their first outside college. Looking over the engineering department, I saw, with one exception in fourty, young White or Asian males. The one exception was a lone Asian female, who had a doctorate in CS.
> Looking over the engineering department, I saw, with one exception in fourty, young White or Asian males.
IME, that's much more a consequence of the limited diversity of candidates, not a limited diversity of hires. In most places I've worked at, even if they hired all women and blacks (or other non-Asian minorities), there would still be at most approximately 5% women and 0% blacks (the latter would probably be higher in the US).
How many of those potential candidates were weeded out by phone interviews with the same hiring criteria and scoring mechanism?
I have personally been rejected after a phone interview, not because my technical skills were lacking, but because the interviewer didn't like something he heard in our conversation. I could quite literally hear him checking out of the conversation and going back to surfing the internet.
> Hiring in CS / IT is massively more objective compared to most of other fields.
That is the illusion many people have convinced themselves of but literally 0 of my coworkers could answer the questions I was asked simply because don't have similar responsibilities despite us applying for literally word-for-word identical job ads.
The reality is, unless you do X regularly, you simply aren't going to be able to impress people with your answer to X.
When the author himself describes very positive and negative interviewing experiences, yet having no success at either, I have a hard time blaming the hiring practices.
An interview can be positive and not lead to a job.
I went on a lot of interviews (maybe close to 100) before starting my own business, and I'd say at least 9/10 of them were very positive.
By positive: I felt we both left the interview a bit happier than we went in. We both had a legitimate good time, and enjoyed it. It wasn't a grind, both people got to know each other.
I'd say I had a 10% offer rate. The most common "why didn't you select me?" follow up answer I got was "we need someone who is an expert in XYZ language." Sometimes it was even that they need someone who is an expert in ABC library (when I was already pretty-much an expert in the language.)
The ones that did lead to job offers I didn't want after the interview.
The other 1/10 was because they had me take an IQ test, or do some really super long project, or meet with literally all 20 people in the company, or they made me sit in the lobby for 2 hours past the meeting time.
I had already took the day off, and they did update me every 20 minutes or so. They also gave me water and snacks before I even knew to wait, and I had my laptop.
It wasn't that big a deal, but they didn't have a good reason to make it not a deal breaker.
I once showed up to an interview only to discover that the people who were supposed to interview me had traveled to another state. This was only after I had taken time off work and been escorted from the military base security gate to the ramshackle, unmarked building that did not in any way resemble a clean and healthy workplace.
Someone eventually called me to reschedule, and it took every last ounce of my willpower not to perform a verbal auxiliary anus installation over the phone.
To name names and shame the shameful, it was SAIC (before they split into SAIC and Leidos).
> I'd say I had a 10% offer rate. The most common "why didn't you select me?" follow up answer I got was "we need someone who is an expert in XYZ language."
I would think this is something that should have been made clear from the get-go in the initial technical phone interview.
Anyone who goes to an in-person interview should expect, at minimum, that the interviewers have done their homework.
For example, if they just want Stanford or MIT grads, fine. But to bring someone into an interview - which may involve more than a day of travel, lost vacation time etc - just to tell them they went to the wrong college afterwards, that's plain infuriating and shows complete lack of courtesy.
> The most common "why didn't you select me?" follow up answer I got was "we need someone who is an expert in XYZ language." Sometimes it was even that they need someone who is an expert in ABC library (when I was already pretty-much an expert in the language.)
There's nothing really wrong with that as long as they advertise such and make it clear before even starting the interview process that you won't be hired unless you're a library ABC or language XYZ expert. The problem comes when they don't advertise that, bring you in anyway, and waste everybody's time.
I run a small company and I absolutely refuse to have an HR department. We're still small enough that this is fairly easy to work around.
My recent hires are all just people I met at events. I'm told by people outside the company that they're all very happy workers.
We do not do technical interviews. We talk casually about past work and what people want to achieve. After hiring we usually find out they have a different skillset and then we find the right tasks to match experience vs. career path.
Knowing this works for my team I would never want to go back to full-time employment at a place with HR ever again. HR has become an insular group of "specialists" who do not deliver value to organizations, and often ruin them IMO.
>I run a small company and I absolutely refuse to have an HR department.
You are my hero. If you ever end up having an HR department you can put in mediocre software developers to do the menial tasks. Most mediocre software developers will out do your average HR drone. For hiring and interviewing use the very best people that you have.
If you've got a good mix of developers at various levels of skill I'd say you're doing it correctly then. The problem is the corporate mandates that 100% of employees be ninja/guru/cowboys. It's this mindset that keeps everyone else running around interviewing needlessly.
I'm confused. I think of HR as human resources, that is, the folks who manage benefits and paychecks and insurance struggles. How is that related to interviewing new engineers?
It's really not an either/or situation. Hiring could improve obviously but the current process of generic white board problems is effective if imperfect.
It's just really hard to decipher one's ability when everyone puts technical experience on their resume because they took an online class or read a book on some thing once.
1. It gets your foot in the door and gets you an interview.
2. It likely gives you valuable experience to answer white board questions.
I don't think it's a perfect process but it weeds out fakers/resume padders. Also a lot of companies arent looking for specialists but want broad skills to handle a variety of problems cause the problems 5 years from now could be very different for the company.
And this is why there is an impedance mismatch... these people are interviewing for a "computer science" role they're filling when really they want a programmer. The two are different.
I think hiring is really steered to avoid hiring idiots. After all it's the interviewer that will have to answer if they hire someone who can't do the job. So all questions are very technical/random and difficult. Most of these people just lookup stuff from textbooks and fling them at interviewees. It eliminates the top and bottom contenders while catching mostly people who just came out of school (or ridicilously smart).
Hiring does need to avoid hiring idiots, but I've found that it's more effective to ask easy questions. Seriously. People who can't program a digital computer have just as much trouble, and there's less opportunity to fake it. Easy questions produce better signals.
I was asked once during an interview to describe a specific problem that I enjoyed solving. And I was told to go in as much depth as I could during the timeslot.
I thought that was a great question. It got me talking about something I cared about, knew very well, and showed my normal thought process and development process outside of an interview. It also gave the interviewer plenty of things to ask about, to "quiz" me on if they wanted, or to just make sure I could actually code.
If I'm ever in a position to interview someone one-on-one, that's most likely going to be my main question.
I've been asked a similar question which would have been perfect for this author.
I had recently published a (terrible, but also terribly fun to write) JavaScript physics engine, which the interviewer saw on GitHub. He began with, "how does it work?" and then continued with probing questions, getting deeper and deeper into the various problems I solved while developing the library, especially focusing on tradeoffs between various choices.
By opening the discussion on "my turf," he put me at ease in the conversation, but by driving the interview with very technical questions, he also got the answers he needed about my technical ability.
This is a great approach. I do this with candidates I interview. I ask for a sample they are proud of and then I just probe away. Has worked very well.
There are a number of problems with this approach. It's difficult to standardize so personal biases are more likely to creep in.
I've asked this question in interviews a number of times, but it's primarily to gauge communication skills rather than technical skills. The biggest problem with using it as a technical screen is that candidates are really bad at choosing a project to tell you about. I've had candidates choose as their problem building out some responsive dynamic front end and their entire solution boils down to, I picked Angular and Bootstrap.
I think the best questions are those that have an easy initial answer, but which can be expanded upon into a harder and harder direction. This way you are able to measure candidates in a repeatable way based on how far they get.
Hiring interviews often contain shibboleths that serve as cultural markers. It's a way to exclude people who are different while claiming that hiring is a meritocracy.
I don't interview well. Technology for me is exciting because of its potential to bring happiness to people. If someone tells me that the product I am working on has a security issue because it does not follow some the security portions of the RFC correctly, I will be delighted to read it carefully, study arcane encoding algorthms etc and implement code that brings up the compliance to an acceptable level. If you ask me to devise an algorithm to find the longest increasing subsequence in an array of numbers without any context I won't do so well.
Maybe I am conceited, but I can't convince myself I am an inferior programmer because of it. I can make money for your company. I can work well with a diverse of group of people. I take pains to conduct myself with integrity. Shouldn't all that be the central measure of how people are hired ?
For what it's worth, if you were interviewing for a security job and couldn't solve the longest increasing subsequence problem within a minute, I would probably say "no hire". All security folks I know can solve such problems in their sleep, and it seems really important for the job. Or at least you'd have to show your algorithmic skills in some other way, without relying on "business" rhetoric. Does that sound reasonable?
This is a false correlation. What is it about longest increasing subsequence that is relevant to security? If you can't explain, then it has no relevance and means nothing.
The hubris in this response is unbelievably high! Have you ever considered that YOU can also be systemically decimated in an interview designed around your weaknesses?
Heck, what if I picked 5 problems from a national level math-Olympiad. You've surey studied high school math right? Should be able to solve them in the 5 hour interview I invite you to!
"But they do expect you to be able to reason from a problem statement to something approximating a solution."
In under 45 minutes? Are you really concerned with their ability to even naively solve an algorithmic problem in that time frame? I would think not. No, this is not only flawed, but it's so deeply flawed (and easily exploitable), that you're not even interviewing for skill set anymore, simply either 1) someone's luck for having been exposed to the problem before or 2) their ability to remember things they don't use day to day.
Congratulations, you're hiring lucky people or idiot savants.
My friend recently got a job at a fund when her now boss asked her, "what are some of the more recent innovations in the Haswell chip set that might be advantageous to a fund". She had literally just read an article about this--out of pure coincidence--the day before, and she was able to recall it when the question was asked.
It's also broken if it simply selects for people who can only code well - with little-to-no insight into how well they collaborate and work with a team.
Hiring IS in fact broken, dude. Did you read his whole piece? Its not just pulling questions off of hacker rank or writing full data structure implementation from scratch at a white board while being time or whatever. The author also mentions the culture of unprofessional recruiters and interviewers who show no interest in the candidate or selling him on the job(yes It's a two way street.) If someone takes time out of their day to talk to you or come to your office, you owe them a little professional courtesy and respect. I think lots of these companies have no idea how poorly some people are representing them and their company during the interview/recruiting process. And these aren't just early stage startups that might not know any better, many of these are Twitters, Netflex et al as well. So yeah its broken.
How do you know his skills aren't useful to the market? That seems like a terrible thing to say.
If you think that AT LEAST one part of the hiring "process" isn't broken, you're living in lala land.
Lets just pick one: recruiters. You're telling me that every single tech recruiter you've come across is excellent at what they do, an amazing and decent human being and has amazing communication skills?!
(Generally/Most of the time) Recruiters don't--and yes, they should--care about candidates. They're interested in pocketing their cut of the candidates salary, so as soon as the company says they're not interested in the candidate, the recruiter is done. Most people don't get call-backs even informing them that they're out of the running, much less a reason as to why they weren't deemed qualified.
Recruiters--especially tech recruiters are NOTORIOUS for being bottom-dwelling scum. I actually know a few good recruiters, but they are--by far--in the minority.
The fact that you don't recognize this indicates that you've either had extraordinary/atypical results, or aren't very familiar with the "process". Dude.
The 960 day github streak is an illustration of his passion to code, of the fact that he is doing it for the pleasure of coding. He said it himself that it's not there to show any skill.
The purposes of these interviews is not (usually) to see if you know the answer. It's to see how you problem solve.
If you knew the correct answer to e.g. the BFS algorithm, you'll get thrown another question that they hope you don't know.
When interviewing, the thing I want to see most is how someone works through a problem: can they solve from first principles? do they go via trial and error? do they ask for a computer to google things up/a book?
Picking raw CS problems is an easy option, as its something that you should be able to solve, and it means I don't have to require you to know Angular/React/Flavour of the month (new tools are easy to teach the right candidate).
You're not going to immediately know the answer to everything that comes up in your job; so evaluating how you solve the unfamiliar is very important.
That's cool, but it's understood that it's a very complex process to "figure out something you don't know."
It absolutely includes talking to people. But not people you don't know, in a very high stress situation, under the pressure to solve the problem in thirty minutes :)
That is sometimes required, definitely. But I'd say that situation only applies to the .01% of real-life programming situations.
That sounds nicer than what 95% of programming interviewers actually do, which is something rather different.
Almost all are simply playing "programming trivia." They name an algorithm or a data structure, and then evaluate whether you can recite it from memory. That's it. There is no problem-solving element involved. It is purely a test of whether you can memorize and recite.
This requires a lot less effort on the part of the interviewer than the style you describe, and also bolsters their ego and makes them feel clever when they find a candidate who can't recite properly.
Just went through this process from the POV of employer.
The risk of choosing the wrong person is so great, that it's often better to not choose anyone. If there is any doubt what-so-ever, it's better to not make a a hire, it can be too damaging to a team, manager, company.
I've tried so many different "coding interview" scenarios. But I found the best one was a real task that a real staff member would be expected to do, extract it out into its own example, and before I talk to someone, they present their solution to the task, and the only thing we talk about, is their solution. If they can dissect and discuss their solution eloquently, and reason about trade-offs, short-cuts, talk about what they may have done better....
Of course, it can also be a simple case of, "is this person an asshole? are they going to rub my team up the wrong way? yes? fuck them."
"The risk of choosing the wrong person is so great, that it's often better to not choose anyone"
This risk can be great, but the team and company can be organized such that the risk is extremely reduced. A pairing schedule, for example, can be very effective.
So many things. The only times I can think that it'd be super damaging:
1) This person is talking directly to clients day one, solo
2) Their code is pushed without review...
3) They are making high-level (C-level, maybe a bit lower) decisions for your business
Otherwise, yeah... a bad employee can do some harm. But, it's that employee's fault, and the other employees will realize this.
It is the business's fault if they go a year under-staffed because "they are afraid."
The second is MUCH more damaging: shows your leadership is not bold, they are misguided, and they don't know what to do to correct course if something goes unplanned (sub-performing employee).
And what if you are a small startup and only have enough money to hire 1 person and you waste months of time and money trying to train the person? Hiring can make or break a small company.
"The risk of choosing the wrong person is so great"
I assume you don't live in the US or if you do, please elaborate because in the US there are virtually no such risks with at-will employment. It's so incredibly easy to fire people in the US that such an idea is actually ridiculous, yet people keep bringing it up all the time as if it's real.
No, Australia. Once you've hired someone, there's a process you need to go through in order to get rid of them - multiple warnings for breaking company policy, mediation, it depends on what the problems are. If they know their rights, and play by the rules, it's basically not possible.
Worse, if you have someone who just doesn't play well with others, there are no grounds for dismissal. You end up having to cook up some sort of severance package for genuinely toxic staff, and hope they hate the environment as much as others hate them.
"Please take this package. In the long run it will be better for everyone" and hope they see the light and walk.
Legal barriers are not the only barriers. Many companies don't work with a quick-fire model. If you, as a hiring manager, hire a person and then fire them within a month, you're going to need to sit down with your manager and explain what happened. If you do it twice, they're going to have serious doubts about whether you're qualified to be a manager.
Plus, it's sociopathic: If someone has a job already, having them quit that job, start working for you, and then get fired and end up on the street because it didn't work out... man, that's a jerk move. The manager owes it to the new hire to be confident that they'll work out.
1 the people that interviewed / recruited that bad egg will be scorned as the people that brought that idiot in
2 often people think the bad one will get better so they invent a lot of time into making it work. Time that could be better spent elsewhere.
3 typically groups have a very limited headcount. So if you bring in a bad person you've used up that slot and won't have anything available for months (if ever)
4 have you ever worked with a negative person? It really zaps the energy out of going into work.
5 the damage that a bad hire can also be great on the code base, let alone morale. Some junk stays in the code for years
> The risk of choosing the wrong person is so great, that it's often better to not choose anyone. If there is any doubt what-so-ever, it's better to not make a a hire, it can be too damaging to a team, manager, company.
That's bullshit. Sorry, but it is.
If it was such a big risk, companies would:
1) Do much better jobs at retaining employees (that are known to be good).
2) Be in a lot of trouble currently, because companies hire all the time and fire all the time.
If you're having this problem you seriously need to reevaluate what you consider damaging. Hiring someone your team thinks is an idiot is not damaging.
Making your current team go home and talk to their roommate/spouse/so each night about how "we really need to fucking hire someone, this is ridiculous" while making your devs set through interviews is damaging :)
> The risk of choosing the wrong person is so great, that it's often better to not choose anyone.
This is a great way to hire "People Like You". Look around at your team. How much diversity is there in age, race, gender, hobbies, college education, or even favorite TV shows? How many would be willing to tell you that you're wrong, and stick to it in the face of a (to you) completely logical explanation of why you are right?
What you qualify as a wrong hire is not necessarily the wrong person to hire. If you're so afraid to hire the wrong person that you will never hire someone you don't instantly like, you and your company will suffer for the lack of different views.
Even that "asshole" can make you think about things in a different light.
What very few employees understand, even some interviewers don't consciously understand, is that people are hired based on race, gender, TV shows, hobbies, school pedigree, all that stuff. The "prove P=NP on the whiteboard in 30 minutes... go!" routine exists to not_hire people.
So the fix is in and the bosses nephew is going to hired or your frat bro you watched south park episodes with. HR makes you interview multiple people to make it look fair. Obviously its going to be a hostile interview experience. Maybe if you're a clone of Knuth and totally wow the interviewer, the bosses nephew will get kicked to the curb, or if you're cooler than the interviewer's frat bro, well, thats a strong maybe. But basically if you walk into an interview and they ask you about algos that a dog whistle you're not getting hired. Either the fix is already in, or you're a minority, either way you're not getting hired once the questions about red-black trees get unleashed. The interview is already over at that point unless its a 1 in 1000 meteorite strike, it does happen, just almost never.
There are way too many skilled programmers for way too few positions or else the system would collapse if just one employer defected. That hasn't happened, therefore there are too many applicants for too few positions.
The reason you hear nonsense about "not enough skilled programmers" is because they didn't mention they have to be white or male or members of the interviewer's fraternity or fans of the same TV show. There's no shortage at all of excellent programmers who happen to be minorities or unrelated to members of management.
Completely agree with all of your points. I think I'd do horrible in most on the spot interviews, but give me an ide with intellisense and a book of advanced algorithms and I'll complete what ever you want. I understand the most common algorithms but I don't use them hardly ever in all the work I have done over the past 10 years. Am I implementing a big data search engine, no. So why would I know all the specifics to that, but given an hour or two of reading I'd be up to speed and be on top of things.
Yeah. I think teaching students algo at college does one thing really well: It helps them understand runtime in association with the data structures they will use.
Gives you an intuition of the proper way to implement something before you know the big picture.
This isn't what interviews are testing: they are testing if you can implement the algo. That is rarely important.
Can you explain why a front-end position requires computer science fundamentals?
If you are a company and have to select between two front-end developers where one has a vast portfolio of production apps that you find impressive and the other knows BFS by heart (but has never shipped something to production), who would you choose?
Consider a scenario where the developer is required to write a custom directory tree. Each row contains a caret and a checkbox. When either of these are clicked, you'll need to perform some sort of tree traversal to ensure integrity of the view -- for example, checking the checkbox on a row may require that all children as selected too. Additionally, you may need an upward traversal to the root to ensure the parents are either in a mixed or unchecked state.
If the developer doesn't understand performance (or at the very least, basic tree operations like searching/sorting/traversing), they're going to write some horrible code. Google and Bloomberg have their pick, they don't want a shitty developer.
From a front-end developer perspective, I would google "navigation tree jquery", download some library that does this for me, and be done with it. If all children of a checkbox need to also be selected, that's like a single like of jQuery. Worst case scenario, something custom is written, and yeah it's not the best way and yeah it takes 100 milliseconds instead of 4, but who cares?
Worst case scenario, something custom is written, and yeah it's not the best way and yeah it takes 100 milliseconds instead of 4, but who cares?
The person who has to try to understand what the hell is going on and how to add new features after the original developer has moved on to other things probably cares quite a lot. The difference between a good programmer and a mediocre programmer is not that one can solve the problem and the other can't, but that the good one can solve the problem in an easy to understand and easy to maintain way.
In my example I did not say that the first developer is ignorant about performance. I only talked about knowing data algorithms by heart.
So let me rephrase this. Isn't it possible that a developer knows about computer performance but at the same time does not know <insert your favourite algorithm here> by heart?
Do you really think that "knowing BFS by heart" equals "knowing everything there is to know about computer performance"?
In your scenario, a developer might just google BFS if that is really needed (when a custom component is needed). Is this so important that he/she has to know BFS by heart beforehand during the interview?
BFS is a 4 line algorithm that doesn't need to be memorized. I wouldn't trust a developer who can't even reason this out with understanding runtime order complexity.
In jobs or sales or relationships (which is ultimately what this is: interpersonal relationship dynamics), the best outcomes are effortless. If there's too much friction, it's probably not going to work out. The best job/deal/friend/partner will simply fall into your lap, and you'll wonder how it can be so simple.
The challenge is finding these. Careful filtering can help, but it seems to be largely a numbers game.
This becomes increasingly difficult, as more companies are infected with these faddish processes every day.
And there's a cost, of time and money and contentment. To help reduce this, consider spending increasingly less time on opportunities you deem unlikely to work out, based on past experience.
I often prequalify jobs--sometimes companies respond, sometimes not, but that also provides me with useful information.
Considering that it's our fellow programmers doing the interviewing, I'd say we're failing ourselves here. I'd wager that in almost all cases, those doing interviews have had zero training on effectively recruiting anyone (let alone other developers). An effective interview requires preparation - and I bet the majority of developers do this right between saying "fuck, have they arrived already?" and starting the interview. Is it any wonder it falls back to the standard approach of "Google does it, it must be good" or a dick swinging contest trying to prove how amazing your team is, because "fuck yeah, we all write search algos every fucking day - it's why our product is amazing."
I guess the take-home lesson here is that programmers have no idea what makes a good programmer and how to screen for one. So they fall back to the basics, CS 101.
> programmers have no idea what makes a good programmer
I disagree. I think we do know what we want, but there is no cheap/easy litmus test for this. If time, money, and opportunity were free, the way to find out if someone is a good programmer is to work with them for a long time.
Okay, now find a cheap way to do that while both sides of the interview have to juggle full time jobs and other interviews.
I see these same algorithms/concepts show up repeatedly in interview rants posted here. At this point, if I'm going to interview, I'm just going to cold memorize them over a week or so and then adapt to the specific interview questions. It's just a ritual that needs to be done at this point.
Didn't care to read after first rant about hiring process. It just seems like you are not a fit for Google. People always try to find company which "culture" fits them, but it also works the other way around, even if you wish to work for Google, maybe just for the salary or other benefits, if you are poor fit for the company culture then you are a net loss.
I interviewed for Google. I didn't get the job, but they were 100% awesome people. Even followed up after asking if I had an complaints, or questions, or anything like that.
I would love to get to experience something like that, but I don't have the educational merits to even be considered by industry heavy hitters like that.
I don't think the specific interview questions are all that y fair. BFS, shortest path, etc, are building blocks of computer science and familiarity with them is a good signal someone has a thorough education in algorithms. If you're hiring an engineer and he's not familiar with the Bernoulli equation, or a lawyer who isn't familiar with Marbury v. Madison, that'd give you pause too.
The real issue is why is a front end developer expected to have an education in algorithms? Part of the problem is that programmers doing the interviewing like to show off, instead of focusing on the requirements of the position. I remember the first time I interviewed someone. His resume said he knew C++, so I asked him about the intricacies of templates. That revealed that his knowledge of C++, like that of many people in the early 2000s, extended only to "C with classes." Gave a negative evaluation. But in retrospect, all our code was C with classes so what did it matter? I was really just showing off that I had read TCPPPL.
> If you're hiring an engineer and he's not familiar with the Bernoulli equation
What discipline are you hiring, and what do you define as "familiar with"? If I am hiring an electrical engineer, I expect them all to know what Maxwell's equations are and what they represent. I would only expect an analog, mixed-signal, or power systems engineer to know how to apply them. Even then I would expect them to look up the equations.
Engineering has been standing on a foundation of reference books for as long as the discipline has existed. Engineers are expected to know what the principles are and how to apply them. They aren't expected to do all this from memory. The PE exam is a mostly open book test for that reason.
The good news is there are plenty of shops that don't ask these types of questions in interviews. Most of the companies you mention have a technical reputation as being elite, and as you say they can hire or interview as they please.
Everybody can't work for Google, and there may be some that could work for Google if they were better at interviewing the way Google does (and these other companies do).
The author harbors some hostility towards the recruiters that have landed him these interviews. I'm a recruiter, and I too harbor some hostility towards recruiters when they behave badly.
The recruiters in all of these situations seem to have done the author a service, and there are no explanations of the recruiters behaving badly (other than the going silent/no feedback scenario).
Telling recruiters to "F* OFF" is just blaming the messenger. They didn't design the interviews, they didn't conduct the technical interviews being complained about, and they didn't make the decision not to hire. They simply facilitated the process and relayed the message.
Blame recruiters when they behave badly. Lying about salary ranges, 'bait and switch' jobs, etc. Don't blame them when they do their jobs, just because you didn't like the outcome.
The basic idea is demonstrate you can provide value to the company, and you have the skills to do the job. If you're stuck with a disinterested interviewer asking irrelevant questions, make it about the job you'll do and your ability to succeed in the job. He has concrete suggestions. I say, if they're not open to that and it is clearly not working, tell them you it is not going to work out and stop the interview rather than enduring another miserable experience.
The OP is describing the new grad tech hiring process. It looks like an exam because it's for hiring people straight out of school.
For experienced people, it's not what you know, it's who you know. You tell your connected friend that you're looking for a job, he tells you who's hiring and gives you a recommendation.
You still have an interview, but it's no longer adversarial, it's a formality, it's friendly, it's just a screen to make sure you're not faking it. One of the people on the other side of the table has seen your work before, so is on your side. So when you get those stupid questions, it's a joke that you all laugh at. You handwave at it, and it's enough.
There are obviously problems with the above process -- it leads to hiring friends rather than the "best" candidate, but I'm surprised that we've moved so far away from it that the obviously well-connected OP is having so much trouble.
That depends on the culture of where you're applying, and maybe what team is hiring you.
When I interviewed at Google after working for a small company for 13 years, it was my first "newfangled" tech interview. I didn't know anybody in the room. And it was more than a formality. I'm a fairly terrible interviewee, and although I got hired (finally, after a very long process), I was hired at least a level below where I should have been. I blame my fuzzy memories of algorithms I haven't had to implement in 20+ years. I finally got promoted to the correct level nearly 2 years later.
Contrast this with Netflix, where I found the opening via my network. I knew more than half the people who interviewed me, and the interview itself felt like it was basically a formality. Days later they made an offer that I accepted.
If one is experienced yet not well-connected, then it's back to the interrogation room. I have a small number of really good friends, who aren't in my geographic area. So it's being asked logic puzzles by twenty-somethings who think Bill Gates invented the computer. Or OO religious questions that only serve to prove that I don't want to work with these people or for their company. And yes I've been through the Google process, at least until I bailed because it was so ridiculous - I am no one's show pony. By comparison, recently I've done a bunch of product management and analysis interviews and they've actually been more fun than not - real conversations exchanging views.
This calls the entire meme of "Silicon Valley is a meritocracy" into question. This just further validates those who criticize tech for being a monoculture with lack of diversity.
The gauntlet also applies if you've spent the better part of a decade in an industry that recently collapsed, and your connected friends are either unemployed or living in constant fear of the layoff notice. cough oilandgas cough
692 comments
[ 2.8 ms ] story [ 347 ms ] threadI wonder if just writing a brute-force maze solver, and then explaining that you are aware better solutions exist...but that you didn't have any memorized, would have sufficed.
If you could go back in time to before they've ever seen it, well then yeah, I agree.
A recursive implementation of depth-first search should only take ten minutes to write. OK, here, I'll do it without looking anything up. Start time 8:55pm.
End time 9:12pm. So 17 minutes (what's that rule about estimating software dev time?), and I haven't run and tested it yet, but it should show what the interviewer wants.Point out that in a real life scenario you wouldn't do this because it is so more efficient to use the work of others, but then solve the problem so they can measure your problem solving skills.
So just who the hell is passing these inquisitions? What's really necessary?
It worked. He's working at a top company for several times his former salary, he had several competing offers with HUGE bonuses and equity offers.
However, I don't know if I have the commitment to do that, and I'm not sure if everyone SHOULD have to do that.
Every employer I've worked for has made the experience farcical. If not at the start, then over time. You interview for one job, and eventually end up doing something else.
A full time career that doesn't pay enough to buy a home. And they say software developers are overpaid.
I think the end-game for me is to just go camping with a laptop or something. I'll code for fun, rather than trying to meet this 'market demand' which provides people with studio apartments, temporarily, in exchange for ~all of their productive hours.
As for "eventually end up doing something else" isn't that career development? We can't bemoan having non-technical senior managers if some developers don't go on to do that.
I think what you mean is that they have a mortgage they'll be repaying for a long time. Houses are still too expensive to buy in the UK with a junior- to mid-tier developer's salary in the UK, even if you went to a place like Cambridge and worked for Google.
LOL yeah, that's what happened to me for my last job. A recruiting process that lasted 4 bloody months for an electronic designer position, and when I was finally hired they put me on software testing; not only I had never done this, but I had never heard it was a thing. Anyway, after less than 2 months I was better as this than the CS graduates who had been doing it for several years and they were asking me for help in their work.
But now I have been unemployed for 2.5 years, I made it to the interview stage only once during that time, and I have given up on even just applying to any job offer for the last 5 months because it is absolutely pointless and humiliating to be repeatedly discarded by people who are clueless, who don't give a flying fuck about the persons they "harvest" and lack the basic respect in social interactions (like spending 2 minutes of their precious time answering a question, not blatantly lying, doing what they said they'd do, or even just showing up at the very appointment themselves fixed!).
So yes, in a way, I've quitted and I am getting ready to become a street beggar when all savings are gone. In the blogger case, his situation is too fresh, I don't think his mood of the day will last long for this time (and after all, he got plenty of interviews, at least), but I am really really tired of these completely nonsensical recruiting processes and their humiliating consequences.
If you want someone to talk to (someone who is doing this), my contact info is in my profile.
The average salary for a "software developer" job posting in my city (Charlotte, NC) is $101k. The average income in Charlotte is $53k. The median home value is $167k. 60% of the value of a home in a year is pretty good.
I've also lived in Sydney, Mannheim, San Francisco, and Seattle, and I noticed similar economics in each of these places (where the salary of software developers tended to be quite high relative to the average income). Do you perhaps live somewhere with a very different trend?
Sources:
- http://www.indeed.com/salary?q1=software+developer&l1=charlo...
- http://www.bestplaces.net/economy/city/north_carolina/charlo...
- http://www.zillow.com/charlotte-nc/home-values/
http://www.theguardian.com/business/2016/mar/10/australias-m...
http://www.seattletimes.com/business/real-estate/king-county...
An average software developer earns about $85,000 in Sydney, so you're right, they're priced out of the central city's market. Senior software engineers make $100-150k, so even they make only up to 15% of a median downtown home.
I lived in Macquarie Park, a suburb of Sydney (which is ~20 minutes by public transit from the center of the city). The median price for a house there is $619k. That's well within reach for a senior engineer, although admittedly more of a stretch for an average developer.
Software engineer salaries in Seattle average $111k. As you've said, the median home price there is about $500k, which is very much attainable for someone earning six figures. The average income in Seattle is $37k, showing that (just like in Charlotte) software developers make about 3x as much as the average resident, and are in fact one of the few groups not yet priced out of central housing.
https://www.glassdoor.com/Salaries/sydney-software-engineer-...
https://www.glassdoor.com/Salaries/sydney-senior-software-en...
https://www.investsmart.com.au/property/nsw/2113/macquarie-p...
http://www.indeed.com/salary?q1=software+engineer&l1=seattle...
http://www.deptofnumbers.com/income/washington/seattle/
There are a few companies that make it a point to mention they avoid the kind of interviews you've been getting. Perhaps try to seek them out rather than rely on recruiters
Yes, if you need such a thing and it's not immediately obvious how to do it, off to StackOverflow you go to find some example code, but these are basic "do you understand fundamental data structure / control flow" type questions. It's not like they're asking you to implement a theorem prover or something.
I just googled it. Oh, I know what it is now.
If you haven't been exposed to it, it's just jargon. That's the point. You are testing for jargon rather than ability.
It is the distinction between saying 'implement FizzBuzz' and going silent, and actually explaining what it is. As an interviewer it is easy to forget that whilst you may have asked a question 20 times, this may be the candidate's first encounter with your terminology.
Steelmanning as applied to interviews, basically.
I have experienced (on both sides of the table) situations in which it just hasn't happened. 'Can you do X?' 'What is X?' 'Never mind, let's move on'.
But we know that most of the time this isn't true. <1% of software developers write sorting algorithms on the job, and even fewer of those actually need to know which one is Bubble and which Quick and which Heap without reference.
If I'm a multinational company, I want my accountant to know what transfer pricing is. If I'm a self employed joiner, I don't.
Problem solving tests are good. Memorization tests are terrible. We have search engines for that.
I don't consider asking a developer about basic data structures and their properties as terrible. This is foundational knowledge that is useful for nearly every programming job. Knowing about lists, hash tables, trees, etc and their operations or tradeoffs is extremely important.
Similarly, having a developer that can reason about the runtime and memory complexity of the code they write is important as well.
These are the "lingua franca" things that I was speaking about in my previous post. Even if particular developers think that the above things aren't useful to them, I would argue that they are probably wrong and just don't know how or why they are.
But before that, I'd used them for 10-15 years without knowing the name because it doesn't matter. Take a hash table. Python calls it a dict. C++ calls it an (unordered) map. Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing you want in a new language, but otherwise they're just words.
Actually in usage I type {} in Python and it is what it is.
I'm not arguing that these things aren't useful at all.
I'm arguing that the distinction between the CS-ified person that has spent the effort to learn what the words mean to pass interviews is not substantially more knowledgeable or useful than the version of that person that will have to find it out in the future. It's marginal.
Basically it feels like a sort of 'table manners' test. You've put the fork on the wrong side of the plate, so you can't eat dinner with us today, you scoundrel.
Don't take this to mean that I think that computer science is useless. Far, far from it. It is simply that I think that relying on jargon is testing whether someone genuinely has a CS degree (or equivalent without certification). It's not testing whether someone is a good programmer.
If that's what you want, just ask for it. Let's not waste each other's time and money.
The anger here exists because people want good faith interviewing, and instead they get "bloody hell the last 20 people were crap I can't be bothered any more" interviewing.
Actually, they are more than just words. Try not to conflate the abstract data structure itself with the language-specific implementations which can vary quite significantly. Also your flippant, dismissive attitude on quite important CS concepts wouldn't take you far. It's better to frame your argument like this ... "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for" which is quite reasonable as most devs CS-minted or otherwise will agree with you. & also while it might not be useful to rote memorize every single CS concept, it's sensible to at least have a passing familiarity. Why? Well, not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.
Please try to avoid this. We can discuss without resorting to attacks.
>> "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for"
That's what most people are arguing for I think, so I agree with you there.
>> not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.
By doing this you are throwing away developers that have made their respective companies millions in revenue. It's not hypothetical. One day, a non-CS trained developer will come across a tree and use it. And then they'll learn.
I think what I see as the real concern is a case of "not knowing what you don't know." If you aren't exposed to at least the fundamentals of this broad base of CS knowledge you aren't going to know that they are available to you when you need them. Learning about a tree when you first read about it is great. But that person will still have huge gaps in their CS knowledge compared to someone who systematically studied it.
I also don't think this is so much about having a CS degree, as it is simply having studied CS in some fashion. I've worked with plenty of talented self-taught developers who took the time to learn these things on their own.
I think really what we're arguing about now is the distinction between hiring for a Google position (pushing the absolute state of the art) and hiring for a position creating accounting software or something.
I don't think that it's reasonable to expect to be hired into a top tier position as a kernel hacker at RedHat or a database expert at Google with an English degree and a few weeks of github commits.
I think that most software development jobs don't need the level of technical chops that are being asked for - and that many of the developers that actually have this level of ability just don't need the company (this post might be an example of that).
Some of the job requirements I've seen make me think along the lines of - 'hell, if I can do all of that, why would I work for you for peanuts?'.
Hey, whoa, stop right here. std::map and std::unordered_map are not at all the same thing, and if you're going to be using them in a manner beyond "trivial" it's important to know the difference between them.
Depending on what their listed requirements were, I think it's reasonable to expect you to know standard terminology, though I wouldn't count it against you if you asked to be reminded of the details for one or two things.
In other words, it's OK if you don't have a formal education in computer science, but when you don't have it, you need to make up for it by learning on your own, because this is basic stuff that high-school kids are learning. And it's even worse when people do have that education on their resume and don't know BFS, because it means they cheated on those courses.
And what would you prefer for a hiring test? Straight IQ tests? A requirement for public, open-source contributions? Or are you speaking of querying databases and fading out divs? I think we can all agree that neither is entirely fair.
And keep in mind that for all the pain involved in the interview process, the only alternative is optimistic hiring for a test period, except that doesn't work because it causes distress to everybody involved if it doesn't work out. This is why many companies now prefer internships, because thus they are dealing with young people that don't have big expectations.
Again, are we speaking of giving out straight IQ tests? I think there's plenty of people that would be against that, plenty of people that consider IQ tests to be fundamentally flawed. And if not IQ tests, how do you measure problem solving and learning ability?
Maybe you give the interviewee something to do, like an algorithm or a piece of code to develop on the spot, right? But maybe your personal expertise doesn't match with what the interviewer wants or needs. And the interviewer has to give you some problem to solve in some way.
I remember that at a coding interview I was given the problem of programming a Lego Mindstorms device to detect obstacles and do stuff. But then the problem was really about reading a document on the C subset used to program the device, along with the several couple of functions needed to control the motion and read the sensors. Was that measuring learning ability in any way? Of course, if you think that the skill of reading a technical document with precise instructions is so rare. But that wasn't real world problem solving.
So how can you test real world problem solving? Do you give candidates a homework? Ah, but then you run into another problem: the good candidates, the ones that might actually solve your homework, are rarely interested in spending their time on such things, because most good people already have jobs and a life and things to do and you can consider yourself lucky if you get their attention for a couple of hours.
In that light, I don't think it's that unfair to give problems to solve that rely on basic algorithms and data structures, especially for companies where the problems solved are much harder than that.
The article might go over the top a bit with self-pity, but personally I just see it as suboptimal behaviour.
http://danluu.com/programmer-moneyball/ - Dan Luu explains better than I can.
I think fundamentally the idea of paying developer X 40K and developer Y 80K (because developer Y has been twice as effective in the past) is broken, because it negates the impact of environment.
If you pay someone 150K GBP in London they can live next door to the office, have TaskRabbit like services perform all household tasks for them, and spend their time exercising and reading 24/7. They will kill it.
Pay them 30K, and regardless of pedigree, they're going to struggle.
Somewhere in there is a balance and I argue it's far less to do with certification and more the circumstances of life which as an employer you have huge discretion to influence.
Basically, it's about steelmanning. Why is someone bad? Is it that they're inherently genetically dysfunctional? Or is it that they haven't been coached well or have a difficult environment?
Given good faith, most of the developers I know have the ability to be amazing. I include myself in that (am I that good? dunno, impostor syndrome innit). But they are stifled by needless nonsense. Management, open office, low pay, commute, stress, basically. Kill the stress and you get your '10x engineer'. Keep the stress and your '10x engineer' turns into a chocolate mousse.
From my point of view, an interview really isn't an exchange between equals, but a meetup where two parties meet, state their demands and evaluate each other. It works in both directions of course.
>> From my point of view, an interview really isn't an exchange between equals
If you design it that way, sure. It doesn't have to be like that.
The whole principle here is that there exists a growing portion of developers who can't be bothered with interview ping pong.
If you don't want them, great! Everyone wins. You don't need to convince us, we won't be working at your company anyway.
First of all, the point of the interview isn't to determine whether somebody is bad, or improperly couched. Surely interviewers would love being able to do that, but it's not possible to do it in a couple of hours.
During the interview all you get to do is to apply a noise filter to get rid of the incredibly bad ones. Because without that filter you can get people that are a very bad fit and that can cost you the project and the morale of your existing employees. It's incredibly taxing to fire somebody. Every time it happened to see a colleague being fired, internal discussions, personal attacks and bad feelings happened internally, every single time and not just at one company. And then in big corporations, because of the risks involved in firing people, you get an even worse effect - you see them "promoted".
And with a noise filter you can naturally have many, many false negatives, as in people that are in fact good, but won't pass the test and interviewers are willing to have that risk, instead of risking false positives.
Of course, from what you're saying, I think you believe everybody can be great. Well, yeah, I think everybody can be great at something useful, but not everybody can be great at something specific. We software developers are too idealistic at times. I don't see surgeons going around telling other people that everybody can be a surgeon. That would be a preposterous thing to say.
On the other hand I do think that if companies want good people, they should invest in education.
> The whole principle here is that there exists a growing portion of developers who can't be bothered with interview ping pong.
I can agree with that. I'm not into interviewing myself. I'm not into switching jobs that often either. I can't be bothered with that because I've got satisfying things to work on already. Capitalism and the free market cuts both ways, right?
BFS and DFS are the bread and butter of tree/graph problems and every software engineer is expected to encounter them at least once in their life. What if you want to debug a complex data structure or just a tree and want to print out its contents in order? Is it really such a weird thing? It's akin to asking to do a for loop through a list to print the elements, except slightly more complex (but certainly something that should be achievable by intuition rather than by memory).
It is intuitive, which even further pushes the question "Why do I need to know this to be an effective programmer"?
A similar question could be "Can you print in order all the elements of a given tree/graph?", would you find that more fair compared to straight out using the word "BFS/Breadth First Search"?
My favorite questions are when companies ask actual problems they're having and try to get the interviewee to suggest solutions and/or implementations.
You speak about the problem domain, but the primary problem domain we are facing first is programming. And without a shared vocabulary, you can talk with other software developers, but you aren't going to be very efficient in that communication. So going back to the problem domain, as software developers we are supposed to master whatever problem domain we are facing, in order to efficiently communicate with the business side in their own domain-specific language. How are we supposed to do that if we haven't even bothered to learn our own domain-specific language?
But it goes deeper than that. Many software developers these days rely too much on libraries, without knowing how they work. And this hurts them a lot.
This is all about standing on the shoulders of giants. And it all starts from the most basic data-structures and algorithms. BFS is right up there with the characteristics of a List or a Map. It's common knowledge that everybody should know. And this common knowledge is half of "Introduction to Algorithms" by Cormen et al. So instead of reading another fluffy piece on Agile methodologies or on soft skills like the "Pragmatic Programmer", or other such bullshit, maybe people should read this one instead.
One recent problem we had was one of scaling out our micro-service-based infrastructure. And I've heard from colleagues wild ideas like "oh, lets introduce an external queue, like Kafka". DevOps for some reason think external queues are the solution to all problems. Yeah, great, but this isn't a freaking webpage reading from a database, we've got singletons, as in producers of truth that need strong consistency in their decision-making because we aren't that smart and you're just moving the problem around, because locks don't freaking scale, no matter how smart your queue is. Or "we'll just add Akka Cluster or Finagle or whathaveyou, should take care of it". Dude, yeah, we've got singletons, which means we need to do sharding and have a protocol for failure detection, so maybe we should talk about that first.
This is just a recent example. Developers are so eager to jump to the latest fads and the latest cool things, without thinking for a second if those solutions would work, only because they can't imagine how these tools are even implemented. And this isn't something that a superficial Google search can fix, because the unknown keeps piling up, the more complex the system is, until the shit hits the fan and you throw your hands in the air and bring in external consultants to fix it. And if you think the UI is spared from all of these problems, think again. I've seen dozens of Javascript-enabled interfaces with performance issues, only because of the "thundering herd" problem happening due to sloppy event handling. How many UI folks understand how Facebook's React works? Not that many.
The "Technical" part was just trivia. Never-mind that I was sat in front of a computer and could have googled everything asked, I chose not to do that.
So yes, I stumbled when asked "what does the using keyword do". I explained how it relates to IDisposable, disposeing the object at the end of the block scope and avoids needing try/finally blocks.
But clearly that wasn't the script, because they kept asking "Are you sure it doesn't do anything else? Are you sure isn't used anywhere else?".
Eventually I realised they were talking about "using System.Linq" etc, and all they wanted to hear was the word "namespaces".
Talk about interviewing by numbers, had I wanted to I could have googled every question and given them perfect descriptions.
What could they possibly have learned from that interaction? I learned I didn't want to work there, so it helped me I guess.
But I find implementation things more helpful (in person, not by phone!), because it's not about whipping out the right answer, it's about watching how the candidate thinks and approaches problems. It's about how they work not the end result.
I like the "write a function to multiply" because it can be extended to any level. If someone aces the positive numbers case you point out negative numbers, if they ace that you can talk about efficiency, or bounds checks, exception handling, efficiency or whatever else you think they'd like to talk about.
This type of recruiting seriously turns me off because you can tell they're hiring minimum wage call center workers to read a script and filter out the 9/10 candidates that can't answer a few administrivia questions. It makes me think of them more as an industrialized recruiting center than a company that actually cares about their workers, which is probably the wrong message to send to potential employees.
It may minimize "humanity" for potential interviewees, but it optimizes for lack of heart ache on their end.
Is my guess.
The follow up phone interviews are what really matters (before the onsite of course) with actual engineers and go more in-depth with coding questions (among other things) at least.
I remember my recruiter was a really knowledgeable guy and he knew his stuff even though he wasn't an engineer. We had a nice chat and he was able to keep up with my (basic, obviously) responses of how TCP works, how to implement inode-based filesystems or whatever information you can read out of a stat call... Nothing too fancy but still it didn't sound like rehearsed script to me.
At the end of the day, it is not about what the company can do for you, it is about what you can do for the company.
I think it comes from a decade of experience of being asked to jump through increasingly ridiculous hoop sizes over time, and complicity cooperating with this nonsense system in an otherwise analytical logical calling.
Essentially that's what is going on. Easier to exercise your biases when the default is "don't hire."
Interviews exist because employers need a way to quantify and qualify your ability. Typical computer science problems are a (flawed, but concrete) way of doing that. No reasonable interviewer expects you to recollect breadth-first search flawlessly, on demand, onto a whiteboard. But they do expect you to be able to reason from a problem statement to something approximating a solution. That's fundamentally what programmers do. You should have the chops to think in this way, and you should be eager to try. Emoting "what the fuck?!" and claiming you can't, or won't, because you're not a recent graduate is an excuse and a cop-out.
A few popular open-source projects don't necessarily speak to your talent as a programmer. A 960 day GitHub streak is trivia, not a signal of anything useful. (If anything, it marks you as a target for burnout!) A few Hackathon wins and a couple hundred GH stars are the artifacts of a successful hobbyist, not a proxy for professional ability, or a gateway to employment.
The author seems to have a chip on his shoulder...
As someone who watched previous coworkers, who are older, go through the interview ringer, I can sympathize with the author on the pigeonhole one can get stuck in due to seemingly trivial reasons: I don't have a classic CS background, people think I'm past my prime, etc.
These aren't imaginary problems, and I struggle to believe that I would be all "go-getter" and "pull yourself up by your bootstraps" after continually being rejected, too.
Gee, I am also very tired of people for which stuff went well, and think it is be the same for others. Can't you even imagine there is a variety of situations out there? Can't you imagine it may happen to you one day? Do you think people who encounter this kind of problems never had a shiny position earlier, and their "social skills" were considered perfect before some conceited internet stranger decided they were "socially inept"?
And you dare to talk about "experience", seriously?
I did not call the author "socially inept"; that sentence was a hypothetical example of how an individual's incredible technical skills can be overshadowed by other problems.
I am sorry if I offended you. I thought my posts were critical but logical...
GitHub stars are worth much more IMO. It shows that other developers value your work. That says a lot.
In the end, we have to realize that most developers are just average. Why go through the ridiculous process of finding average developers who by luck (or some homework) happen to solve the problems you throw at them perfectly?
Never underestimate the value of hard work, preparation, and a can-do attitude. It eclipses natural talent every time.
Such trivia is the opposite of useful hard work; preparation for it truly wastes time that could be better spent on other things; a can-do attitude would imply rejecting or ignoring requests to do such things.
As a result, the people who actually do take the time to complete it will not be completing it because of a good attitude or work ethic, yet you will mistakenly believe they are.
I think the concerns people have about the efficacy of this interview style is valid, but extending it to the point where you start to make claims about how people who can pass them aren't as good is ridiculous.
The types of candidates who spend the time necessary to memorize algorithm trivia for the sake of passing these exams are exactly like overfitted learning algorithms. What they happen to know is unlikely to generalize well. Of course you could get lucky and hire someone like that who can generalize, but that's rare. More often, since hiring is political, you pat yourself on the back for how "good" the candidate is (based on some trivia) and make excuses when their on-the-job performance isn't what you'd hoped, and find ways to deflect attention from that so that you, as an inefficient hirer, won't be called out on it.
Willingness to waste time overfitting yourself to algorithm trivia absolutely predicts worse later-on performance than candidates with demonstrated experience and pragmatism (e.g. I'm not wasting my time memorizing how to solve tricky things that rarely matter. I will look them up / derive them / figure them out when/if I need them).
If given the choice between hiring a math/programming olympiad winner vs. a Macgyver/Edison-like tinkerer who may not be able to explain how to convert between Thevenin and Norton circuit forms, but who took their family radio apart and put it back together, Macgyver/Edison wins every time (unless you're hiring for bullshit on-paper prestige, and of course many places are while proclaiming loudly that they aren't).
Source? or just trying to justify your own shortcomings?
[0] < https://en.wikipedia.org/wiki/Overfitting >
> Overfitting generally occurs when a model is excessively complex, such as having too many parameters relative to the number of observations. A model that has been overfit will generally have poor predictive performance, as it can exaggerate minor fluctuations in the data.
[1] < https://en.wikipedia.org/wiki/Generalization_error#Relation_... >
> The concepts of generalization error and overfitting are closely related. Overfitting occurs when the learned function f_S becomes sensitive to the noise in the sample. As a result, the function will perform well on the training set but not perform well on other data from the joint probability distribution of x and y. Thus, the more overfitting occurs, the larger the generalization error.
Shall I fetch a ruler?
> The types of candidates who spend the time necessary to memorize algorithm trivia for the sake of passing these exams are exactly like overfitted learning algorithms.
I should have asked for a source for that portion. It's the part that is ridiculous.
Again, my bad.
> Source? or just trying to justify your own shortcomings?
is clearly, unequivocally unprovoked and needlessly antagonistic (what do my shortcomings have to do with my point ... either you engage with the claim or not, but use ad hominem insults is not a valid discussion tactic. Yet you seem to assume no responsibility for your completely unprovoked hostility, and continue on with sarcasm, even sarcasm about your own ridiculousness.)
In terms of data, obviously no study is perfect and we should not simply base everything on a single study, but the 2012 PISA results offer at least some evidence < http://www.oecd.org/pisa/keyfindings/pisa-2012-results-volum... >.
The particular sections of the actual study that cover poor performance of those who focus on memorization is not available in the free sample (Chapter 2), but it was reported on, e.g. here: < http://hechingerreport.org/memorizers-are-the-lowest-achieve... >, including this:
> The U.S. has more memorizers than most other countries in the world. Perhaps not surprisingly as math teachers, driven by narrow state standards and tests, have valued those students over all others, communicating to many other students along the way – often girls – that they do not belong in math class.
> The fact that we have valued one type of learner and given others the idea they cannot do math is part of the reason for the widespread math failure and dislike in the U.S.
There is also the discussion from Google that test scores and brainteasers do not predict later-on job success < http://www.newyorker.com/tech/elements/why-brainteasers-dont... > (and many algorithm interviews are absolutely the same kind of brainteaser nonsense).
From the NY article:
> The major problem with most attempts to predict a specific outcome, such as interviews, is decontextualization: the attempt takes place in a generalized environment, as opposed to the context in which a behavior or trait naturally occurs. Google’s brainteasers measure how good people are at quickly coming up with a clever, plausible-seeming solution to an abstract problem under pressure. But employees don’t experience this particular type of pressure on the job. What the interviewee faces, instead, is the objective of a stressful, artificial interview setting: to make an impression that speaks to her qualifications in a limited time, within the narrow parameters set by the interviewer. What’s more, the candidate is asked to handle an abstracted “gotcha” situation, where thinking quickly is often more important than thinking well. Instead of determining how someone will perform on relevant tasks, the interviewer measures how the candidate will handle a brainteaser during an interview, and not much more.
The other thing we have to fight against is self-selection. It's not necessarily in everyone's interest to publicize that their riddles and algorithm hazing process isn't working. Especially not for start-ups which need investors to feel like they are crammed to the brim with stereotypical nerds or something. So if you go looking along the lines of "well, my company uses riddles and we have hired well" you're already done. You haven't hired well. Your company (if it's a startup) probably isn't even remotely proven yet, even if it's well-funded, and the verdict is out on...
But I grant this is reasoning just from the anecdata that I have. I can believe that winners perhaps represent a higher degree of skill, but then we're talking about an extremely small number of people.
Generally you're facing a tradeoff where you have to choose between a sort of rustic self-reliance skill set versus a bookworm skill set. People from either group can learn the other over time, but you can't predict how well by testing them solely on trivia that constitutes their current main group. My preference is to hire for self-reliance and learn bookworm stuff later. I used to believe the opposite (e.g. hire someone good at math because they can always learn to be an effective programmer later) but my job experience made me believe the opposite (e.g. actually it's pretty easy to teach people stochastic processes, machine learning, or cryptography, but it's incredibly hard to teach people how to be good at creative software design).
Could I have dug up a library to do what I needed, sure I guess. Easier to take 20 minutes and just write the tool.
What? That would be a huge red flag in my book. Where are your unit tests? I'm not trusting your 20 minute off the cuff reproduction of classic algorithms in any business critical piece of the code, not ever.
This would get you booted from a lot of places, or at least given a stern talking to for doing something that seems slick, cool, and time-saving in the short term (yay, let's roll our own!) when really it's immature and time-wasting in the long run.
Never (!) homebrew that shit unless you have to (like, you're in an embedded environment or your use case requires some bleeding edge research algorithm).
It's like seeing someone write their own argument-parsing code. Holy shit, what a bad idea. Never (!) do that.
So we did that. works well. I dunno, maybe this company is just full of incompetents. I mean, I doubt it, but it is possible.
I appreciate judgement without context as well. Really, it's awesome.
I don't think it's controversial or insulting to say so in the least. It's a solved problem in every major language and most fringe languages. Spending time re-inventing it is just obviously wrong.
It's not insulting or judgmental to say that it's wrong. It's just a fact. I do not understand being offended or angry about my statement of that fact. If we're talking about what is effective engineering and what is not, writing your own argument parsing tool for actual business usage (as opposed to doing this as a pedagogical side project or something), without evidence of some exceptional corner case, is ineffective engineering. It's practically the definition of ineffective engineering.
https://en.wikipedia.org/wiki/Breadth-first_search
Correct arg parsing is actually significantly more complicated in comparison because of all the possibilities and edge cases.
> Never (!) homebrew that shit unless you have to (like, you're in an embedded environment or your use case requires some bleeding edge research algorithm).
I can't help but think this mentality is what lead to the recent left-pad debacle
It borders on category error to compare homebrewing argument parsing with an overreliance on microframeworks extending all the way down to leftpad. Argument parsing is almost always supported directly by the language implementers in a standard library. And even if it wasn't, it's such a critical task with huge overhead for handling corner cases, cross-platform details, etc., that the value of a central implementation is obvious. A left pad operation ought to be part of the standard language (which is actually what the leftpad debacle was about, Javascript's incredible failures as a language), but it's too trivial to compare it to something like argument parsing.
> The pseudo-code of BFS is all of 20 lines, ...
If it's only 20 lines, that's great because it means it was easy for the other 500 library writers to write it, write tests, and observe and fix issues over time. So, whew, that's 20 lines I totally shouldn't waste my time on, plus unit tests and routine maintenance I don't have to commit to.
And also, given the wide acknowledgement that a good programmer should be writing at most a few hundred lines of code per day (otherwise it's probably mostly junk), 20 lines of code is not trivial.
Probably most programmers write a whole lot more than that per day (especially if counting copy/pasted code), but this is in part a sign of a bad programmer, or perhaps more so a sign of the anti-quality constraints placed on them by most employers.
If I were ever to want to traverse something in a breadth first search manner, then I would just write it. It would take longer to search for another library and read how it's somehow implemented this search than it would to write it, test it, get it reviewed, and we've still avoided adding another potentially crappy dependency to our project.
It's not category error to compare this to leftpad. leftpad actually makes more sense imo, as it's a common microfunction that may be used more than once. BFS is typically far more coupled with the underlying data and is more naturally written inline.
No, you've just added the crappy dependency == your off the cuff implementation (which is even more work since you have to handle issues and unit testing for it too).
> What the hell sort of library would you crack out to do a breadth first search traversal?
In Python I would use networkx probably, unless there was a good reason I couldn't (such as working in an embedded environment where I couldn't install large libraries). It ought to require an exceptional circumstance to stoop to implementing it myself.
Tell me, if we switched from talking about breadth first search to, say, inverting a matrix with Gaussian elimination and pivoting, do you feel the same? Are you going to trust your implementation over something you can get from netlib?
In this case, someone who didn't have the time to visualise exactly how the bfs is operating shouldn't be writing the algorithm. Pretending like you don't need to know the details of how it traverses the tree when you needed to choose the specific implementation for this algorithm to be performant is a lie. It's not like Guassian elimination, where the concept is far more abstract, this is a concrete idea of how you're moving through the graph and shouldn't be some black magic.
On top of this, who writes this code and doesn't test that it does what you expected it to do on sample data. If you bfs implementation was bust, then you'd miss nodes or revisit them, which becomes immediately apparent from testing the algorithm you're writing.
> It ought to require an exceptional circumstance to stoop to implementing it myself.
Maybe the problem here is that I see a bfs as a fundamentally simple algorithm. Saying writing it yourself must be an exceptional circumstance sounds about as crazy to me as saying no-one should ever use for loops, they expose you to making mistakes with an index you may forget is zero-based, please use anonymous iterators instead. When something takes 5m to write, is heavily tested by default (as it will be a feature under test anyway and possible flaws will be highly obvious) and is at the same level of abstraction as the code you'll be writing around it, then just write the damn thing.
EDIT - Try writing a BFS that operates on an acyclic graph that outputs the value of each node, that compiles and runs and prints at least two node values that has a bug. Try writing bugs into this, it's actually difficult to screw up.
Yes, this kind of hubris is often the root of the problem when so-called 'simple' algorithms get homebrewed, then later on unexpected corner cases pop up, testing isn't adequate, you didn't implement it in an extensible way, your implementation is unacceptably inefficient, etc. etc.
> On top of this, who writes this code and doesn't test that it does what you expected it to do on sample data. If you bfs implementation was bust, then you'd miss nodes or revisit them, which becomes immediately apparent from testing the algorithm you're writing.
Yes, but the point is that testing isn't free. If you commit to writing your own implementation of something to interface with whatever larger business / domain-specific project created the need for it in the first place, then you have to dedicate not just the time to write it, but also the time to test it, and to test how it integrates, and to maintain the API for it and maintain its integration (possibly backward compatibility, etc. etc.)
If you adopt a standard to use a certain library, then up to the degree to which you trust the library, those problems are mostly offloaded to others. For things like classical algorithms, the libraries are extremely trustworthy, so many of the pitfalls of adding a dependency don't apply.
> In this case, someone who didn't have the time to visualise exactly how the bfs is operating shouldn't be writing the algorithm.
It's not about being too pressed for time. Even if you had all day, it's a poor use of time to create more future work for yourself by yoking yourself to all the extra responsibilities that come along with rolling your own. Yoking yourself to those responsibilities should require an exception reason for doing so.
> Saying writing it yourself must be an exceptional circumstance sounds about as crazy to me as saying no-one should ever use for loops, they expose you to making mistakes with an index you may forget is zero-based, please use anonymous iterators instead.
This is an extremely fallacious comparison. Basic control structure are built in features of the language. You don't have to test or maintain the runtime execution of a for loop, that's the job of language designers. Making mistakes in the usage of something (like an off-by-one index) is completely non sequitur to this entire discussion. I don't see how you would think that type of bug is related to anything I'm saying.
In general, you also assume a much higher fidelity of testing than what happens in the real world. In 99% of software jobs, you'll be extremely lucky if someone even documents their homemade BFS algorithm, let alone writing even the most superficial of tests. Expecting them to give you an adequate bank of automated tests is like believing in the Easter Bunny.
> Try writing bugs into this, it's actually difficult to screw up.
Ugh.
Also, the question is, is the ability to write a BFS on a whiteboard a useful way to screen programming candidates for most positions. No it is not.
Next to arrays and lists, trees are such fundamental part of computer programming that I can't find an excuse for not being aware of some basic operations. I am not suggesting here that the RB or AVL trees and all the tricky stuff about them should be your bed time reading, but a certain baseline should be established.
The interview scenario is just not similar to on-the-job coding. It has different social pressures, time pressures, access to help, access to privacy, etc. etc.
Plus, for someone like me (I studied machine learning and stats, and all data structure knowledge is self-taught post college, yet I have 6 years experience writing scientific code, performant database stuff, etc.) I am always hearing about data structures and algorithms that are supposedly "fundamental" but I never even heard of them before and have yet to need them in a job.
Basically, all of my experience, and all of the experience of hiring software developers in any of the companies I've been in just completely suggests what you're saying is actually not true. It's just a story we tell to allow us to keep our crab mentality hazing rituals.
I'm always happy to get a kudos on GitHub. But those of us who don't play the game of promoting our own code on social media, or who have code we can't post on GitHub, would be at a significant disadvantage in a hiring process based on that metric.
[1]: https://github.com/tdeck/teambot
If having source code and demonstrated traction for a few open source projects to review don't speak to one's talent as a programmer, then what does?
A professional programmer, the one hired by a company to work alongside other professionals - as opposed to one working by themselves on small projects - is capable of presenting previous experiences and applying them to new problems. Unless you want to be put in the basement and handed small chunks of work to solve. It's about how you mentor juniors, resolve disagreements on how to proceed, deal with set backs and changing requirements.
Given the whole post is about how terrible the interviewing process is the above quote is the most telling, and backs up the GPs point - not being prepared to have a conversation about your previous experience when interviewing for a job is pretty bad.
There are some positions where you don't have to care if people can really problem-solve; as long as they can tweak CSS until it works right-ish, or know the particular arcane implementation details of installing some WordPress module, they can do the job. But there are a lot more positions where you want someone who can solve the problems that need solving, pick up new technologies as needed, and just generally be a flexible and productive contributor in a way that doesn't relate to the fiddly details of one particular technology.
If you have the "mental dexterity" to coming up with your own solution which is identical to Dijkstra's pathfinding algorithms in terms of complexity within an hour interview, you are a god among mortals.
And that's what they expect - a solution to a problem that is equal to the best minds of our field. I say this from experience: I was expected to do exactly that, and criticized when I came up with a O(n^3) instead of O(n^2).
If everyone is an 10x, then everyone is an 1x .. Isn't?
Front-ends almost always involve working with data. It is increasingly common for front-ends to have filters, searching, sorting, etc... of that data as well.
Doing that efficiently is key to ensuring a fast, responsive UI.
Wrangling with divs and CSS may take a disproportionately large amount of your time but that doesn't mean it's the most important skill to look for, nor does it mean the CS questions are somehow irrelevant to the work.
You can find full exams with answers of CCNA and every Microsoft cert imaginable, I've worked for companies that incentivise certifications, and i watched coworkers use these 'tools' en masse to gain easy pay bumps and pad their resumes.
I've had two interviewers ever to ask me technical questions that actually tested my knowledge or capabilities. I look good enough on paper so usually interviews are with a couple managers and if there's a culture fit I'm in. Doesn't matter if i dont know a damn thing, if my resume says MCSE on it.
Microsoft and others further incentivise these certs by giving bonuses and breaks to companies employing certified individuals.
If you think people being hired because they passed a test they cheated on is 'more objective than other fields' then maybe i just have a warped view of how objective other fields are
I agree with you that certifications are crap but I haven't encountered a single good company that cares about them.
Vastly fewer responses and recruiters on major sites, but i've got about another 6 months to go on a really interesting couple of projects at my current job, so I'm not too upset about it.
Sometimes it is almost required (see MS certs) to be competitive.
So, they only care because it's a business thing (not a qualification thing) but they do care.
They are very keen on getting employees with existing certs or getting current employees to actively be getting more certs.
There are specific incentives from microsoft based on how many employees have certain levels of microsoft certification. it comes with discounts and marketing materials/privileges (Who doesnt want to say they are a Microsoft certified Gold support partner?)
As such, it is conveniently ignored that the guy with an MCSE isnt going to get fired because their gold level partnership lapses if they dont keep X number of MCSEs on staff
When my team would look at candidates, past accomplishments and projects counted for tons more than a cert. Still, a cert told us what someone was interested in and what they wanted to bone up on. They could expect questions relating to that cert field during the call. If they had trouble talking on the subject, then we knew that the cert was likely there to be a pad or just something to fulfill some billet requirement. In good cases we'd find that the cert was an indicator of something they were passionate about.
So I consider it a pointer of sorts. Never worthy of hiring someone on it's own, but I'd recommend them to people who are /ready/ to demonstrate knowledge and may not necessarily have the project experience otherwise. I'd just recommend to them that they be ready to talk to it in an interview.
The certificate shouldn't matter in the interview itself - it is just a way to pair down the choices of who you interview when you have many candidates. If you have knowledgeable people in the interview process (i.e. at least have a dev present for a dev interview, not just managers or HR people) then you should be able to catch those that don't really have the skills.
Heck, even people who genuinely have a certificate might be rubbish overall but revised well for the exam days - you'll hopefully weed those out in a good interview process too.
Have you had many IT interviews? I have, they are vastly non-technical interviews.
Unless you count "have you ever used #CommonSoftware? how about #SlightlylessCommonSoftware?" as a technical interview.
I'm an IT administrator, not a programmer, so i'm speaking to my experience in that field, I am not trying to make any claims about how programming interviews work.
I've never had a whiteboard in an interview, I have in two interviews ever been asked to walk through a diagnostic process for problems, or asked any infrastructure or network design/architecture questions.
Its worth noting I work and live in Detroit Michigan, so I'm not exactly interviewing with major technology companies regularly. But I have worked for MSPs which glossed over technical interviews in favor of culture fit as well. (MSPs are especially incentivised to have employees with certs, they get discounts and kickbacks)
I guess maybe i insulted some CCNA or MCSE-ers
The article starts with:
>This is a story about my interview experience in the tech industry.
I also work in the tech industry, I was sharing my experience of interviewing in the tech industry.
More specifically i was responding to a comment that said:
> Hiring in CS / IT is massively more objective compared to most of other fields.
I've seen this directly happen - the interviewers were two Asian and one White male, who came to this job as their first outside college. Looking over the engineering department, I saw, with one exception in fourty, young White or Asian males. The one exception was a lone Asian female, who had a doctorate in CS.
Hiring "People Like Us" doesn't help a company.
IME, that's much more a consequence of the limited diversity of candidates, not a limited diversity of hires. In most places I've worked at, even if they hired all women and blacks (or other non-Asian minorities), there would still be at most approximately 5% women and 0% blacks (the latter would probably be higher in the US).
I have personally been rejected after a phone interview, not because my technical skills were lacking, but because the interviewer didn't like something he heard in our conversation. I could quite literally hear him checking out of the conversation and going back to surfing the internet.
That is the illusion many people have convinced themselves of but literally 0 of my coworkers could answer the questions I was asked simply because don't have similar responsibilities despite us applying for literally word-for-word identical job ads.
The reality is, unless you do X regularly, you simply aren't going to be able to impress people with your answer to X.
I went on a lot of interviews (maybe close to 100) before starting my own business, and I'd say at least 9/10 of them were very positive.
By positive: I felt we both left the interview a bit happier than we went in. We both had a legitimate good time, and enjoyed it. It wasn't a grind, both people got to know each other.
I'd say I had a 10% offer rate. The most common "why didn't you select me?" follow up answer I got was "we need someone who is an expert in XYZ language." Sometimes it was even that they need someone who is an expert in ABC library (when I was already pretty-much an expert in the language.)
The ones that did lead to job offers I didn't want after the interview.
The other 1/10 was because they had me take an IQ test, or do some really super long project, or meet with literally all 20 people in the company, or they made me sit in the lobby for 2 hours past the meeting time.
It wasn't that big a deal, but they didn't have a good reason to make it not a deal breaker.
Someone eventually called me to reschedule, and it took every last ounce of my willpower not to perform a verbal auxiliary anus installation over the phone.
To name names and shame the shameful, it was SAIC (before they split into SAIC and Leidos).
I would think this is something that should have been made clear from the get-go in the initial technical phone interview.
Anyone who goes to an in-person interview should expect, at minimum, that the interviewers have done their homework.
For example, if they just want Stanford or MIT grads, fine. But to bring someone into an interview - which may involve more than a day of travel, lost vacation time etc - just to tell them they went to the wrong college afterwards, that's plain infuriating and shows complete lack of courtesy.
There's nothing really wrong with that as long as they advertise such and make it clear before even starting the interview process that you won't be hired unless you're a library ABC or language XYZ expert. The problem comes when they don't advertise that, bring you in anyway, and waste everybody's time.
My recent hires are all just people I met at events. I'm told by people outside the company that they're all very happy workers.
We do not do technical interviews. We talk casually about past work and what people want to achieve. After hiring we usually find out they have a different skillset and then we find the right tasks to match experience vs. career path.
Knowing this works for my team I would never want to go back to full-time employment at a place with HR ever again. HR has become an insular group of "specialists" who do not deliver value to organizations, and often ruin them IMO.
You are my hero. If you ever end up having an HR department you can put in mediocre software developers to do the menial tasks. Most mediocre software developers will out do your average HR drone. For hiring and interviewing use the very best people that you have.
It's just really hard to decipher one's ability when everyone puts technical experience on their resume because they took an online class or read a book on some thing once.
2. It likely gives you valuable experience to answer white board questions.
I don't think it's a perfect process but it weeds out fakers/resume padders. Also a lot of companies arent looking for specialists but want broad skills to handle a variety of problems cause the problems 5 years from now could be very different for the company.
Almost in any interview I had, I been asked about CS stuff. Never anything related to my field.
I don't blame them. They ask about what they know and what they think it's important, even if it's not relevant to the position.
What's this?
I thought that was a great question. It got me talking about something I cared about, knew very well, and showed my normal thought process and development process outside of an interview. It also gave the interviewer plenty of things to ask about, to "quiz" me on if they wanted, or to just make sure I could actually code.
If I'm ever in a position to interview someone one-on-one, that's most likely going to be my main question.
I had recently published a (terrible, but also terribly fun to write) JavaScript physics engine, which the interviewer saw on GitHub. He began with, "how does it work?" and then continued with probing questions, getting deeper and deeper into the various problems I solved while developing the library, especially focusing on tradeoffs between various choices.
By opening the discussion on "my turf," he put me at ease in the conversation, but by driving the interview with very technical questions, he also got the answers he needed about my technical ability.
I've asked this question in interviews a number of times, but it's primarily to gauge communication skills rather than technical skills. The biggest problem with using it as a technical screen is that candidates are really bad at choosing a project to tell you about. I've had candidates choose as their problem building out some responsive dynamic front end and their entire solution boils down to, I picked Angular and Bootstrap.
Maybe I am conceited, but I can't convince myself I am an inferior programmer because of it. I can make money for your company. I can work well with a diverse of group of people. I take pains to conduct myself with integrity. Shouldn't all that be the central measure of how people are hired ?
Heck, what if I picked 5 problems from a national level math-Olympiad. You've surey studied high school math right? Should be able to solve them in the 5 hour interview I invite you to!
In under 45 minutes? Are you really concerned with their ability to even naively solve an algorithmic problem in that time frame? I would think not. No, this is not only flawed, but it's so deeply flawed (and easily exploitable), that you're not even interviewing for skill set anymore, simply either 1) someone's luck for having been exposed to the problem before or 2) their ability to remember things they don't use day to day.
Congratulations, you're hiring lucky people or idiot savants.
She was offered the job on the spot.
Yes, absolutely.
Wait, really? I've had to do more than that just for internships, the bar for perfection at many companies is just that high or higher.
I agree with the rest of what you're saying.
How do you know his skills aren't useful to the market? That seems like a terrible thing to say.
If you think that AT LEAST one part of the hiring "process" isn't broken, you're living in lala land.
Lets just pick one: recruiters. You're telling me that every single tech recruiter you've come across is excellent at what they do, an amazing and decent human being and has amazing communication skills?!
(Generally/Most of the time) Recruiters don't--and yes, they should--care about candidates. They're interested in pocketing their cut of the candidates salary, so as soon as the company says they're not interested in the candidate, the recruiter is done. Most people don't get call-backs even informing them that they're out of the running, much less a reason as to why they weren't deemed qualified.
Recruiters--especially tech recruiters are NOTORIOUS for being bottom-dwelling scum. I actually know a few good recruiters, but they are--by far--in the minority.
The fact that you don't recognize this indicates that you've either had extraordinary/atypical results, or aren't very familiar with the "process". Dude.
Edit: spelling, puncturation
If you knew the correct answer to e.g. the BFS algorithm, you'll get thrown another question that they hope you don't know.
When interviewing, the thing I want to see most is how someone works through a problem: can they solve from first principles? do they go via trial and error? do they ask for a computer to google things up/a book?
Picking raw CS problems is an easy option, as its something that you should be able to solve, and it means I don't have to require you to know Angular/React/Flavour of the month (new tools are easy to teach the right candidate).
You're not going to immediately know the answer to everything that comes up in your job; so evaluating how you solve the unfamiliar is very important.
It absolutely includes talking to people. But not people you don't know, in a very high stress situation, under the pressure to solve the problem in thirty minutes :)
That is sometimes required, definitely. But I'd say that situation only applies to the .01% of real-life programming situations.
Almost all are simply playing "programming trivia." They name an algorithm or a data structure, and then evaluate whether you can recite it from memory. That's it. There is no problem-solving element involved. It is purely a test of whether you can memorize and recite.
This requires a lot less effort on the part of the interviewer than the style you describe, and also bolsters their ego and makes them feel clever when they find a candidate who can't recite properly.
The risk of choosing the wrong person is so great, that it's often better to not choose anyone. If there is any doubt what-so-ever, it's better to not make a a hire, it can be too damaging to a team, manager, company.
I've tried so many different "coding interview" scenarios. But I found the best one was a real task that a real staff member would be expected to do, extract it out into its own example, and before I talk to someone, they present their solution to the task, and the only thing we talk about, is their solution. If they can dissect and discuss their solution eloquently, and reason about trade-offs, short-cuts, talk about what they may have done better....
Of course, it can also be a simple case of, "is this person an asshole? are they going to rub my team up the wrong way? yes? fuck them."
This risk can be great, but the team and company can be organized such that the risk is extremely reduced. A pairing schedule, for example, can be very effective.
1) This person is talking directly to clients day one, solo
2) Their code is pushed without review...
3) They are making high-level (C-level, maybe a bit lower) decisions for your business
Otherwise, yeah... a bad employee can do some harm. But, it's that employee's fault, and the other employees will realize this.
It is the business's fault if they go a year under-staffed because "they are afraid."
The second is MUCH more damaging: shows your leadership is not bold, they are misguided, and they don't know what to do to correct course if something goes unplanned (sub-performing employee).
I assume you don't live in the US or if you do, please elaborate because in the US there are virtually no such risks with at-will employment. It's so incredibly easy to fire people in the US that such an idea is actually ridiculous, yet people keep bringing it up all the time as if it's real.
Worse, if you have someone who just doesn't play well with others, there are no grounds for dismissal. You end up having to cook up some sort of severance package for genuinely toxic staff, and hope they hate the environment as much as others hate them.
"Please take this package. In the long run it will be better for everyone" and hope they see the light and walk.
Plus, it's sociopathic: If someone has a job already, having them quit that job, start working for you, and then get fired and end up on the street because it didn't work out... man, that's a jerk move. The manager owes it to the new hire to be confident that they'll work out.
1 the people that interviewed / recruited that bad egg will be scorned as the people that brought that idiot in
2 often people think the bad one will get better so they invent a lot of time into making it work. Time that could be better spent elsewhere.
3 typically groups have a very limited headcount. So if you bring in a bad person you've used up that slot and won't have anything available for months (if ever)
4 have you ever worked with a negative person? It really zaps the energy out of going into work.
5 the damage that a bad hire can also be great on the code base, let alone morale. Some junk stays in the code for years
That's bullshit. Sorry, but it is.
If it was such a big risk, companies would:
1) Do much better jobs at retaining employees (that are known to be good).
2) Be in a lot of trouble currently, because companies hire all the time and fire all the time.
If you're having this problem you seriously need to reevaluate what you consider damaging. Hiring someone your team thinks is an idiot is not damaging.
Making your current team go home and talk to their roommate/spouse/so each night about how "we really need to fucking hire someone, this is ridiculous" while making your devs set through interviews is damaging :)
This is a great way to hire "People Like You". Look around at your team. How much diversity is there in age, race, gender, hobbies, college education, or even favorite TV shows? How many would be willing to tell you that you're wrong, and stick to it in the face of a (to you) completely logical explanation of why you are right?
What you qualify as a wrong hire is not necessarily the wrong person to hire. If you're so afraid to hire the wrong person that you will never hire someone you don't instantly like, you and your company will suffer for the lack of different views.
Even that "asshole" can make you think about things in a different light.
So the fix is in and the bosses nephew is going to hired or your frat bro you watched south park episodes with. HR makes you interview multiple people to make it look fair. Obviously its going to be a hostile interview experience. Maybe if you're a clone of Knuth and totally wow the interviewer, the bosses nephew will get kicked to the curb, or if you're cooler than the interviewer's frat bro, well, thats a strong maybe. But basically if you walk into an interview and they ask you about algos that a dog whistle you're not getting hired. Either the fix is already in, or you're a minority, either way you're not getting hired once the questions about red-black trees get unleashed. The interview is already over at that point unless its a 1 in 1000 meteorite strike, it does happen, just almost never.
There are way too many skilled programmers for way too few positions or else the system would collapse if just one employer defected. That hasn't happened, therefore there are too many applicants for too few positions.
The reason you hear nonsense about "not enough skilled programmers" is because they didn't mention they have to be white or male or members of the interviewer's fraternity or fans of the same TV show. There's no shortage at all of excellent programmers who happen to be minorities or unrelated to members of management.
Gives you an intuition of the proper way to implement something before you know the big picture.
This isn't what interviews are testing: they are testing if you can implement the algo. That is rarely important.
Is this Hacker News or Script-Kiddie News?
If you are a company and have to select between two front-end developers where one has a vast portfolio of production apps that you find impressive and the other knows BFS by heart (but has never shipped something to production), who would you choose?
If the developer doesn't understand performance (or at the very least, basic tree operations like searching/sorting/traversing), they're going to write some horrible code. Google and Bloomberg have their pick, they don't want a shitty developer.
The person who has to try to understand what the hell is going on and how to add new features after the original developer has moved on to other things probably cares quite a lot. The difference between a good programmer and a mediocre programmer is not that one can solve the problem and the other can't, but that the good one can solve the problem in an easy to understand and easy to maintain way.
So let me rephrase this. Isn't it possible that a developer knows about computer performance but at the same time does not know <insert your favourite algorithm here> by heart?
Do you really think that "knowing BFS by heart" equals "knowing everything there is to know about computer performance"?
In your scenario, a developer might just google BFS if that is really needed (when a custom component is needed). Is this so important that he/she has to know BFS by heart beforehand during the interview?
Oh, well...
The challenge is finding these. Careful filtering can help, but it seems to be largely a numbers game.
This becomes increasingly difficult, as more companies are infected with these faddish processes every day.
And there's a cost, of time and money and contentment. To help reduce this, consider spending increasingly less time on opportunities you deem unlikely to work out, based on past experience.
I often prequalify jobs--sometimes companies respond, sometimes not, but that also provides me with useful information.
I disagree. I think we do know what we want, but there is no cheap/easy litmus test for this. If time, money, and opportunity were free, the way to find out if someone is a good programmer is to work with them for a long time.
Okay, now find a cheap way to do that while both sides of the interview have to juggle full time jobs and other interviews.
https://github.com/gelstudios/gitfiti
The real issue is why is a front end developer expected to have an education in algorithms? Part of the problem is that programmers doing the interviewing like to show off, instead of focusing on the requirements of the position. I remember the first time I interviewed someone. His resume said he knew C++, so I asked him about the intricacies of templates. That revealed that his knowledge of C++, like that of many people in the early 2000s, extended only to "C with classes." Gave a negative evaluation. But in retrospect, all our code was C with classes so what did it matter? I was really just showing off that I had read TCPPPL.
What discipline are you hiring, and what do you define as "familiar with"? If I am hiring an electrical engineer, I expect them all to know what Maxwell's equations are and what they represent. I would only expect an analog, mixed-signal, or power systems engineer to know how to apply them. Even then I would expect them to look up the equations.
Engineering has been standing on a foundation of reference books for as long as the discipline has existed. Engineers are expected to know what the principles are and how to apply them. They aren't expected to do all this from memory. The PE exam is a mostly open book test for that reason.
Everybody can't work for Google, and there may be some that could work for Google if they were better at interviewing the way Google does (and these other companies do).
The author harbors some hostility towards the recruiters that have landed him these interviews. I'm a recruiter, and I too harbor some hostility towards recruiters when they behave badly.
The recruiters in all of these situations seem to have done the author a service, and there are no explanations of the recruiters behaving badly (other than the going silent/no feedback scenario).
Telling recruiters to "F* OFF" is just blaming the messenger. They didn't design the interviews, they didn't conduct the technical interviews being complained about, and they didn't make the decision not to hire. They simply facilitated the process and relayed the message.
Blame recruiters when they behave badly. Lying about salary ranges, 'bait and switch' jobs, etc. Don't blame them when they do their jobs, just because you didn't like the outcome.
My one piece of advice: read Nick Corcodilos's Reinventing the Interview:
http://www.amazon.com/Ask-Headhunter-Reinventing-Interview-W...
The basic idea is demonstrate you can provide value to the company, and you have the skills to do the job. If you're stuck with a disinterested interviewer asking irrelevant questions, make it about the job you'll do and your ability to succeed in the job. He has concrete suggestions. I say, if they're not open to that and it is clearly not working, tell them you it is not going to work out and stop the interview rather than enduring another miserable experience.
For experienced people, it's not what you know, it's who you know. You tell your connected friend that you're looking for a job, he tells you who's hiring and gives you a recommendation.
You still have an interview, but it's no longer adversarial, it's a formality, it's friendly, it's just a screen to make sure you're not faking it. One of the people on the other side of the table has seen your work before, so is on your side. So when you get those stupid questions, it's a joke that you all laugh at. You handwave at it, and it's enough.
There are obviously problems with the above process -- it leads to hiring friends rather than the "best" candidate, but I'm surprised that we've moved so far away from it that the obviously well-connected OP is having so much trouble.
When I interviewed at Google after working for a small company for 13 years, it was my first "newfangled" tech interview. I didn't know anybody in the room. And it was more than a formality. I'm a fairly terrible interviewee, and although I got hired (finally, after a very long process), I was hired at least a level below where I should have been. I blame my fuzzy memories of algorithms I haven't had to implement in 20+ years. I finally got promoted to the correct level nearly 2 years later.
Contrast this with Netflix, where I found the opening via my network. I knew more than half the people who interviewed me, and the interview itself felt like it was basically a formality. Days later they made an offer that I accepted.