Hiring Is Broken
medium.com
medium.com
> How many people can actually write BFS on the spot, without preparing for it in advance?
Ughhh, should I tell him?
> why would they ask me this question, what does breadth-first search has to do with front-end development
Tree data structures are really common in front-end.. like the DOM or JSON.
I've been developing for well over a decade as full stack engineer. I've worked as a successful software dev at some big corporations (like Intel, and yes it was fulltime for several years) and almost always outperformed my peers. I work in finance now where everything is about managing portfolios for people - lots of numbers and heavy calculations.
I have no fucking clue how to write a BFS. I've never needed to know how to write a BFS. I will probably never need to know how to write a BFS. Coders like me write business applications where these things are literally never an issue. If there's something I need to know and don't, I simply research it. That's the point he's trying to make. Don't interview people on algorithms they will never ever use. It's as simple as that.
There are more productive ways to interview someone; for example take a bug in your product and see if the candidate can fix it. Or if you're worried about sharing proprietary info, then make a sample program that simulates a bug or feature that your application will use and observe the candidate working on that.
A candidate who freaks out upon being asked that question is not a candidate whom I'd trust to be a good problem solver. Solving a problem with simple constraints is something that happens all the time. If you don't know how to approach that, you could just "look it up", but how would you even know what to look up?
I disagree. My experience has been that these problems are exceptionally rare.
They're so uncommon that programmers get excited when presented with such a problem. It feels like "real programming" as opposed to fixing bugs, writing prototypes, or writing business logic.
> I'd expect an engineer with years of experience to have the strategies in a sort of unconscious memory, like a rock guitarist who plays the right chord progressions without knowing what they're called
This is fantasy. You're comparing the average programmer to musical savants? What?
You happen to have memorized a bunch of algorithms for traversing data structures. That's great, but nothing about that is "unconscious memory". The fallacy is expecting everyone else to have memorized the same thing you have memorized.
> If you don't know how to approach that, you could just "look it up", but how would you even know what to look up?
Google for "tree traversal" and spend 10 minutes researching common algorithms. Pick one that fits. Spend 20-30 minutes writing it (hopefully with some tests). Worst case you've spent an hour.
Someone who memorized the algorithm could probably write it (with tests) in half the time. And that's okay because how often are you doing tree traversal? And even if you're doing tree traversal all the time then you'll have memorized all these techniques in 1 month anyway.
They didn't describe a musical savant. They described someone who learned to play the guitar without any background in music theory. The analogy was not someone playing a chord without knowing the name of the chord, it was someone playing a chord progression without knowing the formal musical basis for that progression.
That kind of intuition is very common in guitarists, and I thought the analogy was rather apt.
I have no idea what guitarists and other musicians you know. I know quite a few and they've had to put in serious work on music theory (most from a young age). Many also started out with instruments like early piano lessons and transitioned to guitar.
It's quite literally a language you need to learn (memorize); kinda like maths actually. Some things may seems intuitive but only savants can compose actual music without training in music theory.
Composing music is to playing a chord progression as writing a naive algorithm implementation is to designing an optimal algorithm.
I don't see why any memorization should be necessary. I have never written a BFS algorithim. Yet I can immediately think to two different ways of implementing it. In fact, when reading the article I googled BFS to make sure it wasn't referring to something else because BFS seemed so simple to implement. All you have to do is place every node's children in a FIFO que and process the nodes in the order they are added. You could also use two arrays, one for the current level of nodes and one for the next one. It is only slightly more complicated if you are traversing a graph, rather than a tree, as you need to track visited nodes to avoid repeats.
Also, the utility of BFS and DFS in frontend seems hard to ignore, the majority of the data structures are trees (html, xml and json) and these are the two ways to traverse them.
> They're so uncommon that programmers get excited when presented with such a problem.
What about "process these things in this order" is uncommon? If anything, the constraints are far simpler and easier to understand than most of the business logic I implement.
Neither have I, but we both have prior knowledge that accounts for solving most of the problem. We know how trees are implemented. We clearly know what BFS is and what's "tricky" about it.
Someone hasn't dabbled with tree traversal has to grok a lot of information in the heat of an interview.
> Also, the utility of BFS and DFS in frontend seems hard to ignore, the majority of the data structures are trees (html, xml and json) and these are the two ways to traverse them.
I'm not 100% sure about frontend, but I haven't heard of anyone writing tree traversal algorithms for a DOM tree. That's all handled by either browser APIs (document.querySelectorAll?) or lower level libraries (ReactDOM?).
> What about "process these things in this order" is uncommon? If anything, the constraints are far simpler and easier to understand than most of the business logic I implement.
That's exactly the point. Think about it... there are literally dozens of ways to implement a BFS. The currently accepted standard way of writing a BFS is the most concise and efficient.
A minuscule amount of your business logic is as concise/efficient. Most of the time your business logic will balance finding the best solution with meeting milestones (milestones usually win).
So let's say someone doesn't have any experience traversing trees (why would they? you rarely have to, if ever). Let's also say that they haven't memorized what BFS is and what the constraints are. You're presenting them with a new problem and expecting them to come up with the most efficient/concise solution to that problem. The only people who get rewarded here are people that simply memorized the solution or the solution space. In effect you've validated nothing.
> as opposed to fixing bugs
bug: "takes too long to find a <file / json field / html node>"
It's a real problem.
Right. My point was the problem is perceived as "basic" because the commenter memorized solutions in the problem space. If it's not something you deal with regularly (or have interest in) then it isn't as basic as it seems.
People that haven't memorized the most efficient/concise solution also freak out because they know that their whiteboard solution is going to be judged on the merits of the industry standard solution.
> bug: "takes too long to find a <file / json field / html node>"
This is almost always an issue with an underlying library. The better question is why your programmers are wasting time writing slow BFS code when they should be using well tested solutions.
Example: I recently needed to write some AST transformation code. Did I write my own AST node traversal code? Hell no! I picked a library that did the job. I spent about 20 minutes catching up on state of the art AST traversal (so I'm not blindly importing a bad solution) and let the library do the work.
The point is you wouldn't know what to search for. If you don't know anything about cars, you wouldn't be able to search for "alternator fault". The best you could do is "engine problems" which won't help you solve the actual problem.
I'll go a little further and say that if you've qualified a candidate as capable of busting out the routine Javascript required to wire up typical front-end code, if you can't teach that developer how to implement BFS within the confines of a single interview, you the interviewer share some of the incompetence. Certainly that would be the case for a manager or team lead!
The reality is that BFS is for most jobs (frontend AND backend) a trivia question, and a status-seeking mechanism for interviewers.
If an interviewer wants to test problem solving skills with a BFS, no problem:
- Draw a tree on the whiteboard (interviewers writing the whiteboard is highly undervalued; it calms the candidate)
- Explain what a BFS is. It's easy to draw out each step in a BFS algorithm.
- Ask the candidate to write some pseudo code that implements it.
And they still failed it! It is not about trivia or what BFS is, it is all about can you reason about algorithms.
(Disclaimer: our actual interview problem is slightly different, but it it still a very basic CS one)
Okay.. so now this is about you and a bad candidate rather than the person pointing out that interviewing is broken. Got it.
Because BFS/DFS are so easy to interchange, I'd strip ordering out entirely: here's a collection of stuff where each element may also point to other stuff in the collection, starting with this element search through the stuff to see if you can find a certain element.
If I was going to ask this problem, I'd help a nervous-looking candidate by contrasting the problem (or leading with) a simpler still one: here's a collection of stuff where each element can point to at most one other thing, starting with this element see if you can find a certain one in the collection.
Linear search is, technically, an algorithm. Graph search just extends it. All these people railing against algorithms in interview problems as non-applicable surely have at least written a for loop over an array and had an if statement somewhere inside, right? Linear search. When I've given interviews I don't try to make them based on "algorithmic knowledge"[0] but at the same time I really don't like the trend of thinking of algorithms in general as "oh, that's someone else's job, I never use those" or "I can only implement algorithms by memorizing them."
[0] When I was just starting to get asked to give some I lazily asked a colleague for a reference problem, they sent me https://leetcode.com/problems/jump-game/description/ and I read the problem, immediately recognized that the general approach of graph searching would solve it[1], and coded up the 12-15 lines or so it took, made some tests, fixed some minor mistakes... Total start-finish time was 10-15 minutes, not the fastest. There's also a solution to that problem that doesn't require thinking of it as a graph, too, but I think it's harder to get the insight. Anyway, nice problem, I thought, I'll only give a problem if the candidate has 2x the time it takes me to solve it as a buffer for interview nervousness/whatever, but after giving it to a few people only one of them managed to solve it in like 50 minutes after creating a pretty verbose and pseudo-coded BFS system. (My initial approach used DFS, but it doesn't matter here -- though for the jump game 2 sequel problem which asks to find the shortest number of jumps, BFS makes sense, and it's easy to take the solution for the first problem and make minor alterations. General algorithms like "search" are great and widely applicable.)
[1] In retrospect, before I saw the problem I was writing a simple game of go client as a side project, and had recently implemented a function to, given a point on the board, determine if there's a stone there and if so determine if it's part of a larger group of stones and return their coordinates. So in some sense the problem was already 'primed', and I've written a lot of graph search skeletons for both fun and profit. It's interesting to hear that some people go decades without doing so...
It is hard to say if U/F would be more efficient for this problem. U/F can perform two `union(a, b)` and `find(a, b)` operations in O(lg n) runtime complexity, or, with some more effort (path compression), nearly constant time (a, b representing node indexes). But for this problem a first pass over all indexes would be required to build the disjoint set from the input.
I think for small inputs DFS or BFS would be more efficient, and have the plus of not needing extras storage (U/F would require a second array the same size than the input). For large arrays, probably U/F would win since the input array may encode potentially a lot of edges (say, if each index contains a number large enough) and DFS runtime complexity is O(Edges + Nodes).
Anyway, I think U/F can be really useful in the context of job interviews, there are many problems that can be reduced to connected components, after some massaging.
Here's an implementation I did a while ago [2]. Even though I love the algo, I don't really remember the details about path compression... time to refresh my memory I guess :-D
[1]: https://algs4.cs.princeton.edu/15uf/
[2]: https://gist.github.com/EmmanuelOga/bcafad14715a3f584e97
For the jump game problem, I'd expect DFS would still win almost all the time even when there are many branches because it doesn't have to explore every element of the input array except in the worst case (and you can greedily explore a neighbor without having to discover your other neighbors first), whereas to build a complete union-find structure would. Still, the fastest solution in general is probably just the single pass: if you have the insight that you can keep track of a 'max reachable index' and update it at each step to max(current-max, i + A[i]), bailing with failure if you hit an index > the current max and having no more jumps, or bailing with success if your max becomes >= the final index. (I never had this insight myself.) It could be slower of course, e.g. if the array was something like [bigNum/2, lots of 0s, bigNum/2 again in the middle, lots of 0s, end at index bigNum].
If I give you a description of what a BFS is, you as a programmer should be able to write one. A BFS is rather trivial. You shouldn't have to know how to write it, you should be able to figure it out. The same goes for implementing a linked list or the FizzBuzz problem.
As a programmer, you need to make up algorithms on the spot to solve business problems. You don't know the solution beforehand, you figure it out, that's your job. It's the key skill that basically separates you from a typist.
> There are more productive ways to interview someone; for example take a bug in your product and see if the candidate can fix it.
This is a different skill. It's an important skill, but finding errors in an existing structure and fixing it is different from being able to create that structure in the first place.
I'm working on something at the moment, and one of the key features is that while there's a fair amount of data, none of the structures are particularly big - and are very unlikely to ever become big.
So my thought process is that stupid brute force algos are absolutely fine for this domain.
If I have performance problems I can look into optimising them.
If I had hundreds of terabytes of data to start with, I'd take a different approach, and I'd research - not invent, because I don't care to reinvent a wheel if someone has already produced a much better solution - more efficient algos.
If none of the above work, then I'd consider improvising something and testing how it performs.
Would this pass your interview process or not? Do you want someone who's going to brute force an answer to your toy problem and think they've solved it with something that works but is inefficient, or someone who has memorised a collection of standard answers but maybe can't improvise something new, or someone who is going to check what's already available to save time, or someone who can improvise a super-efficient answer and do it even if it's not needed?
Who would you pick?
Do you really think this question has a simple answer?
Yes, that sounds very reasonable.
> Do you want someone who's going to brute force an answer to your toy problem and think they've solved it with something that works but is inefficient, or someone who has memorised a collection of standard answers but maybe can't improvise something new, or someone who is going to check what's already available to save time, or someone who can improvise a super-efficient answer and do it even if it's not needed?
First of all, let's talk about what I don't want. I don't want someone who can't solve the most basic problems. I'm not interested in all these details at this point in the process. Don't get stuck in analysis paralysis.
> Do you really think this question has a simple answer?
No, but it's not the question I am asking. My question would be, can you solve basic problems? I'm not looking for 100% accuracy in testing, that's impossible. Surely some kid fresh out of college will get an "unfair advantage" with something that's still on their mind, while some genius may have a bad day and fumble the test. I wouldn't personally pick BFS as a test either, but the fact that you should be able to solve it remains. The fact that "you may never need it" is irrelevant.
For all software businesses there is only one question to ask candidates: "Can you help us ship working software that solves the problem of our customer"
What I can tell you is that there are a number of books written on this subject if you need help identifying the correct interview questions to ask.
You're not someone who would look at the screen and just say "I don't know" (or thank me for my time and storm out).
Which is great and all, but it it's not a quality which correlates particularly well with the stated problem you are hiring for.
Now if you were hiring for the marketing department…
Repeat after me:
A good hiring process is one that will not be affected by the luck of the draw nor the personality of the candidate.
I've been doing this for a quarter of a century and I will tell you right now that the best engineers of my generation would indeed thank you for your time, never come back and quietly advise the extensive network of young people they mentor to avoid your company like the plague.
The problem with that is when the best solution to a problem is a BFS, you may never recognize or realize it, because you know nothing about BFS. You won't know what to research for.
I see it when people who don't know what calculus is go to enormous efforts to develop workarounds that sort of half-assed work.
I see it in my own work when I didn't know about a class of techniques, so I invented some crappy solution. For example, reinventing bubble sort when I could have used quicksort.
BFS is awfully basic knowledge. How do you know you've never needed a BFS? Maybe you never needed a BFS because a linked list is your go-to data structure? Maybe you've been reinventing bubble sort. (I'm not the only programmer who incompetently reinvented bubble sort, not even close. I just didn't know any better.)
cf. https://escapethetower.files.wordpress.com/2010/12/tais-mode...
It's hard to do research when one doesn't recognize there's a problem, nor know what question to ask.
>The problem with that is when the best solution to a problem is a BFS, you may never recognize or realize it, because you know nothing about BFS. You won't know what to research for.
Just because someone doesn't know how to write BFS code doesn't mean they don't know what it is.
> BFS is awfully basic knowledge. How do you know you've never needed a BFS? Maybe you never needed a BFS because a linked list is your go-to data structure? Maybe you've been reinventing bubble sort. (I'm not the only programmer who incompetently reinvented bubble sort, not even close. I just didn't know any better.)
Never had to write a BFS in all my years of programming. I am one of those programmers that write glue code and are not "real" programmers by the definition of some here in HN.
Actually, it does mean they don't know what it is. BFS stands for "Breadth First Search". If a node in a data structure has two links, one going down in the data structure, and one going sideways, breadth first means going sideways first. "Depth First" means going down first.
That's the algorithm. It ain't rocket science. There's no trick involved.
Look, I think the dev hazing ritual that is current hiring processes sucks, but Algos and Data Structs are the language that we speak. We have to be familiar with them.
If their response is "this is stupid, no one has to know how to do this" and storm out with the same indignation that is present in half of these comments then they are not the ones who dodged a bullet.
It depends on the position you apply for, I'd say.
Some jobs require C++ and algorithmic skills. If you don't know how to write a basic algorithm in C++, then you might not be the best fit - and you might not want to join the company as a junior developer.
That being said - sorry to hear that was your experience. That shouldn't have happened, but it does.
If it's down to syntax errors, and the logic is correct, what the heck does it matter? Almost everyone writes code in an IDE that will deal with those syntax errors.
One writes code that cannot be compiled while the other does. Who scores higher?
Now, let's say you are a big company and have 100 applications for that position and do the math...
EDIT: I noticed you edited your post so it looks less inflammatory. Not cool.
Which is probably the root problem. Almost all tech hiring is carried out like a war between companies that want results and candidates who don't want to be treated like shit.
Because BFS has two approaches - 1.) I know BFS or similar example and will write it with no thinking 2.) I am figuring it out in head while saying things to keep you pleased.
You don't need to know employee internal thought process. Practically, BFS tests whether you are able to BFS, which is cool by me. It is simple enough so that people who were really unable to learn it should really be filtered out.
(It is ok to not know name, obviously. Just ability to find a thing in datastructure should be question.)
I can't remember Djikstra's algorithm either, but I would happily try and write a 15 line brute force recursive maze solver in an interview.
Of course it's not something I expect anyone does day to day, but it's also the kind of simple problem that I'd expect almost anyone with a CS 102 level of knowledge to be able to reason out by just taking a few minutes with a pencil and paper. As an interviewer, even a brute force solution would demonstrate a good willingness to look at problems using your fundamental skills and reason about something you don't have a ready made solution to.
You'd fail the interview. The type of interviewers that ask this style of question are never interested in seeing the the naive brute force approach.
Implement -> Evaluate -> Refactor
I'd rather have someone who could caveman the first approach, recognize the inefficiencies, and improve the execution than someone who rattles off a memorized algorithm to a common problem.
If the interviewer is wanting the eloquent solution right out of the gate, then the manager might be hiring for the wrong position.
I tried doing it -- even with the knowledge of how it works, it took me at least a day to get to an acceptable implementation.
There have been interviews I have failed and instead of blaming the interviewers I took the time to actually study the problem I was given. This has helped me become a better programmer.
Interviews that require extra knowledge outside of what the job actually asks for are definitely broken.
I don't doubt you've experienced differently. But if you have, I think it's likely the interviewer, not the question. Lots of interview questions can be abused, not just basic algorithms and data structures questions.
I'm loathing the potential need to ever eventually interview for a tech position because even on trivial things like Error trait impls in Rust I end up opening 3+ pages of documentation to verify I knew what I was doing at least, or often figure out better solutions with methods not on my brains hot path of solving the problem.
Theres nothing pleasant about having your tools taken away from you and then being looked down at when you are like a fish out of water. The OP even talks about it when describing the drain of technical interviews - nobody wants to be judged upon at their worst by strangers. Its humiliating.
> Ughhh, should I tell him?
Yeah, that's where I stopped reading. This isnt specialized knowledge. If you know how to program, you can write a BFS. The entire algorithm structure is in the name. The only extra details you need to remember or figure out are "use a FIFO for tracking what to check in the future" and "make sure you don't go backwards". Neither is some great secret. They're obvious if you sit down and think through (or talk about with the interviewer) the structure specified in the name of the algorithm.
This person is either not a good programmer or has a very poor attitude about solving new problems.
Hiring isn't broken. I'd reject this guy too. Knowledge about a specific technology is a lot less valuable than general knowledge and willingness to explore.
Programmers need a zen place to concentrate and focus. "Homework" assignments should be a good measure to test skills and questions on decisions made on his and how would he improve a code given the use cases would be more comfortable and now we are level playing field. my two cents.
Around here, the trend is requiring a 16-20 hour assignment just after a brief 15 min phone call, almost before starting the process at all.
Not only it is a ridiculous amount of effort to ask someone who may already be doing 8 hours a day programming but it's also a problem for the company. Either they have to spend significant effort evaluating each candidate's submission or -more likely, sadly- they only give it a perfunctory look and discard many on first glance. And considering that often the person doing the evaluation has his own tasks to do and is doing it on some spare time, they will tend to not make much of that effort.
The result is the company still needs to do significant effort and the candidate gets frustrated because they have had to spend a significant amount of time and, after having to wait for a couple of weeks -at the very least-, they get generic and useless feedback saying simply that they did not meet the expectations or whatever.
I would not mind at all doing a two-three hour on-site assignment. If you're there, they will at least have to make a similar effort as you are. I find this much more fair both as a candidate and as an employer.
I've had this exact thought. I got interview homework last year, was told to spend "no more than 4 hours" on it, etc, was mildly interesting. The next interview we'd have a discussion about the code and I'd present my rationale for various design decisions etc. But then I got the email that the interviewer had reviewed the code with an engineer and they decided not to move forward because there was a mistake and they "thought there would be more testing"! I felt that it was quite imbalanced to have spent 4 hours on this task, only to have it rejected without discussion after a short review.
So in the future I'm going to suggest that I'll be happy to do whatever homework assignment as part of a pairing exercise. That way I can see what it's like to work with them too.
Your success rate will be no less than someone who spends 15 hours doing whatever bullshit assignment there is.
"If only the author did these very precise things that they just so happened not to do, THEN I would find empathy". I'm pretty sure that's not how empathy works.
He probably isn't a good "programmer." He is a web developer, and has projects that are basically CRUD input and output.
He can stitch together various different components to build a functioning end product. This is a fine skill for most agency type jobs, and he will likely have a long prosperous career as a contractor.
As an interviewer, I'm always happy to talk to the candidate about the question I ask. I'm perfectly happy to answer "What is a breadth-first search? Why does it solve this problem?". I'm perfectly happy to talk about algorithms with them, and ask leading questions if the candidate explains where they're having difficulty.
As a candidate, I'm not interested in working with an interviewer who doesn't approach the interview the same way. Remember, all interviews are bidirectional.
This person's stated reaction to the question was anger that it was asked. Most likely masked in person, but even masked tells us a lot. It tells us he didn't actually talk to the interviewer. If he had talked to the interviewer and got garbage back, he would have been angry about how awful the people were, not that some technical question was asked. If he'd talked to the interviewer and got useful information back, he wouldn't have thought it was a bad question. The only options left are trying to stumble through it silently and getting it wrong, or sullenly saying "I don't know" and moving on.
And that's the problem. A good programmer isn't measured by being able to make things. A good programmer is measured by being able to work with others and make a positive contribution in a group. Everything this person is describing is how to make a bad first impression during an interview. Maybe he's a great programmer, but he's utterly failing to actually convey that in the important aspects during the interview.
I wouldn't hire him, and this writeup is exactly why. He needs to demonstrate that he's someone people want to work with. This article does the opposite.
This is something I feel a lot of interviewees aren't aware of, you DON'T have to know EVERYTHING.
I didn't know what a BFS was (I am primarily a front end web developer), so in an interview, I'd simply ask "Could you explain what that is? I'm sure I can find some way to do it."
As an instance, I looked up "Breadth First Search" on google just now, and saw that its just a way to search a tree one generation/level at a time. Once I knew that, the naive approach is simple (I'm sure there is a better way). Start a queue with node(0,0), and loop until the end of the queue, if you don't find the correct value, add the node's children to the queue, and keep going.
I totally feel for the guy, I've been rejected more times than hired, that's for damn sure, and each time is a HUGE blow to the ego, but you have to pick yourself up. I feel he is a great contract developer (not a dig, I am also a contract developer), but not necessarily someone I would hire full time.
No, that's it. That's why so many are ragging on him; it really is that simple.
This system is corrupted but looks like it suits big corps just fine. I have never evet been asked about my real experience on large corp interview. They just don't care about your github. Small companies asks about experience, but unfortunately some small companies copy FANG approach to interviews, cargo cult is magnetic.
As far as I remember, I have never written any BFS code, and I would also find it absurd to be asked to do so in an interview. There is great library code that does this in any reasonable situation.
If you're the kind of shop that would rather write your own code than use third party libraries, then that's a really great sign that I shouldn't work there.
Do keep in mind that you're eliminating the places that wrote that "third party library" in the first place. Libraries don't just grow on trees (though they can help you navigate a tree).
Just a few weeks ago I had to knock out a test framework, creating an API from scratch (basically an object model on top of some websockets messages), because there's no library that's going to do what we need. Oh, I friggin' abused Python's import keyword to hell and back, but there was a lot of stuff that just needed to be written from scratch. Given there are a few tree-like structures, I'm sure I briefly weighed depth-first vs. breadth-first before hammering out the code. And this is nothing exotic, just a small company working in the industrial controls industry. And such a task is nothing exotic, it's why they hired me. But I think to effectively create something like this in an efficient manner, having at least a rough idea of something like BFS is table stakes.
One is not being asked to implement a red-black tree on a whiteboard, just something that I think a competent software developer could come up with from first principles. A company asks you, "which direction will you be searching, and how would you do that?", and you'll reject them. I mean this with due respect: you're probably right, neither party will want you to work there, and the filter worked. Hurray?
I'll tell you what grates me, though: the companies that insist they need someone like that, and then the new employee finds out that the culture is so borked, that said employee will never get to actually do that stuff. "We need test infrastructure." Turns out the reason they don't have any isn't for lack of someone to write it, it's lack of culture to do anything with it. As just one example.
Writing code in a vacuum is humongously dangerous even for simple things like piping strings. Its why so much C software ends up chock full of overflows, segfaults, and myriad security vulnerabilities.
Wouldn't it be nice to be able to use references / existing implementations while at the board being watched and timed.
But I wouldn't think for a second those people would be incapable of being good team members or productive coders. You just let them stay in their comfort zone and approach uncertainty in the ways they are comfortable with. They will know the best way they can approach solving a problem, and if you were testing for that instead in these interviews, they wouldn't be so harmful to participation in tech by "minorities" such as women or people of color.
I'm primarily a backend dev who did a little js a couple of weeks ago that required me to populate a dynamic tree with the results of an api call.
Although I think I went depth first, so I guess technically you're right....
If I had claimed a lot of algorithm-heavy experience on my resume, I would have expected my response to be met much more harshly. But, as my experience was focused more on API design and interactions with business stakeholders, it wasn't a useful question to gauge my competence. However, it was useful for gauging my personality. Like everything, context is vital.
That is actually informative on your programming ability, not regurgitating buzzwords (albeit BFS is a light one) or rote memorization.
Like just hearing these kinds of questions is infuriating because I often immediately ask things like "is the data processing complex enough to justify threading it? what are the synchronization points? if the data processing is variable, we probably want a job pool, etc". The performance of code is almost always noninutitive until you have an implementation done in order to optimize it, and questions about searching graphs are almost always these "optimize light" problems where they want you to really know how to do the navigation right because of my precious 10 cycles per branch but don't want to even consider the operating environment that could influence the decision in anything but a purely academic setting.
Be honest, how many of us implement our own data structures these days? I sure don't. I just build on or use whatever version of map comes with the language 98% of the time.
99.999% of front end developers do not solve those kind of problems.
Fun fact: I'm lying.
In general, I think it's enough to know what your abstraction does, rather than how it does it.
https://en.wikipedia.org/wiki/Leaky_abstraction#The_Law_of_L...
As it stands, any of the libraries that do DOM manipulation for me also traverse the tree for me ... so, again, why do I need to implement a toy BFS in an interview?
Also, if you know that all the companies do this, why don’t you just study before hand? Tree traversals come up multiple times in the article. I understand the author’s frustration but not their (early) insistence on not studying for an important interview. When they did study later I wonder how seriously they took it based on the tone.
And what's the likelihood of that happening with a well-used framework? Maybe the interviewer wants to see my ability to debug problems - great let's do that instead. You want to see how I work? OK, let's pair on something. Pinning this to "implement BFS at the drop of a hat on a whiteboard or in this project" is bullshit.
>Also, if you know that all the companies do this, why don’t you just study before hand?
Fine. I'll implement a few solutions to the problem in the languages I'm familiar with and put it on GitHub. Now the interviewer can check it out and we don't have to waste time at a whiteboard.
In my experience, higher than you'd hope.
Just because the interview culture has evolved to this awkward unrepresentative generally unhelpful filtering method, is no justification for "well just do it that way and you'll be fine".
If I'm the new monkey, and someone smacks me for touching the ladder, I'm going to ask why and push back if there's no good answer.
I don’t think it’s about the BFS, it’s about attitude.
The maze solving could be solved by breadth first too. It is algorithm that can be used in many different contexts.
How many software developers work on "unique problems" that involve hard computer science problems compared to the number that are just using an existing framework to solve business problems?
Tree data structures are really common in front-end.. like the DOM....
And most of the time you're going to end up using a pre-existing implementation....
There are positions that does not involve anything harder then BFS ever, but I would not say they are majority of them.
And the 20 years of professional development was after I had been a hobbyist writing 65C02 and x86 assembly language....
It makes perfect sense to not remember the name and that should be ok. But it really is not something complex - it is pretty much simplest algorithm used to explain the concept of algorithm to students.
My current employer asked me no programming questions even though I supposedly came in as a “Senior developer” in my small company.
He was more concerned about everything I mentioned and how could I help mature the organization.
Heck, he didn’t even care that I didn’t know any $cool_kids front end framework.
Whenever my last day on my current job comes and I don’t expect that to be for a few years, I’ll probably end up working for a consulting company as an overpriced “digital transformation consultant”, “implementation consultant”, or “solutions architect”. Do you really think they are going to ask me about my leetCode capabilities?
The same should be true for anyone at a certain stage of their career.
I don't get insulted over basic questions. Mostly because I worked in a company that did not asked programming questions. As a result had to work with few people who could talk design and maintainability such, looked like great socially and turned out they could not write the code except in simplest situations. It was not good and harm was long term, Largely because of resentments etc that build up in team who had to do someones work while that person was treated as superstar. Such person needs strategy to mask inability and those are all toxic - masking own inability by blaming others etc.
What are alternatives out there? Take home assignment, fizzbuzz, simple algorithm, trivia questions, requiring you to already know exact technology they use. Someone complains about every one of these. There is no hiring process that make everyone happy and fit everyone, but imo, as long as company does not go to some crazy extreme somewhere it should be fine. If candidate have to balance red-black trees then it is very clearly too much, figuring whether string is palindrom is not too much.
There is also something good to be said about repetitive hiring process where company can compare how people did on interview and then how they did in real life. As such, it will contain some generic or easy questions.
The inevitable response to that is "well that's an exception, it's only occasionally needed." True, as far as it goes. But if you exempt all of these "rare special cases," you've suddenly exempted 10% of the work. That 10% is among the trickier bits (though the hardest is always organizational and product).
I also hate to say this, because it's snotty, but as far as obscure algorithms or tricky, complicated algorithms go... BFS and DFS don't really fall into those categories.
I don't think that's the issue though.
The issue, as I see it, is not that you had to figure out how to implement BFS. I think many of us are confident we could do that under professional working conditions. If I had a day and some data structures to poke around with, I'd write a killer BFS supported by tests if I needed to (I've had to do similar things in the past).
The issue is that interviews expect us to recall this kind of specialized and rare problem solving like it's a day-to-day thing. We as candidates are being judged on how well we can come up with a novel solution on the spot to something that many of us will need to do once or twice in a career, and will be able to solve under completely different conditions.
In short, for most candidates, these kinds of questions don't test anything realistic, and a lot of people have issue with that. It's like judging whether you want to go to a chef's restaurant based on how well they did on Chopped! They might do well under pressure because they have practice with it because they're always in the weeds because their restaurant is poorly run. A terrible dining experience might translate to a win on a cooking competition show, because the show isn't testing the chef on the experience they provide you. Just as these kinds of interview questions don't test you on how you'll actually be interacting with code and solving problems day to day.
But it's about friction: I want my coworkers to be focused on the genuinely hard problems, not spending a day writing a BFS. The current interview process does manage to probe that.
Going a bit deeper, the whiteboard interview process is a good proxy for ability to prepare over the medium term (a month or three of consistent studying should give you as good a chance as anyone to get into a generalist position at a prestige company) and of IQ. The latter is controversial and most organizations can't test for it directly (owing to legal concerns), but a relatively high IQ is a core requirement of technical roles, and whiteboards provide a solid proxy for that when coupled with the opportunity to prepare for them beforehand.
That said, I'd always go for someone who has the ability to deliver on complicated, large projects over someone great at whiteboards or who has a high paper IQ. It's just that it's pretty much impossible to evaluate for that in a way that works on a general application pool.
I would say big companies that hire new people or generalist programmers benefit greatly from them. These types of questions test for intelligence at scale without outright being an IQ test. In fact, I think I read somewhere that Google engineers' performance is strongly correlated with how well they do on their interviews.
Sure, these questions might not test for conscientiousness, curiosity and general agreeableness, but that's why you have the other portions of the interview.
All this being said, I don't necessarily think these questions work at most companies where the engineering teams are significantly smaller and you can really spend a lot of 1-1 time probing knowledge and experience and reviewing coding exercises. However, I would still say basic DFS/BFS and using a hash to solve a problem is still a must. I use them on occasion, even as a generalist.
As much as I think certain companies shoot themselves in the foot by spending their interviews asking trivia questions about e.g. Rails (because that's what they use), it's not unreasonable that they might just more highly value having someone who can be productive in their Rails world immediately against someone who, while excellent, nevertheless needs a week or several to onboard the ecosystem. Or in other words, they think the goal question is answered in the affirmative more strongly for someone already in the ecosystem. A dangerous assumption, but possibly valid. There are always tradeoffs to be made in the specificity and category of your questioning, but interviewers need to keep in mind how they contribute to the overall goal's question.
For larger companies, it's more likely that there are more problems to solve, and more likely a need to get people working on them sooner rather than later, so the incentives start pushing for addressing the goal of hiring (if not for all positions, at least for many positions) by answering a simpler goal question of "is this person smart and gets things done?" (which is just high IQ + conscientiousness) and hiring en masse. If you put such people to work on any of the problems you can rightly expect they will advance them some amount, even if they have to ramp up on a programming language / framework / whatever feature of the problem's environment first, and as time goes they can shift around the company to where they're even more effective. In addition to being fast it's also very fair with respect to people's backgrounds, suddenly it doesn't really matter if you have a thousand widely used github repos or not, have a 10 year experience headstart or just graduated a bootcamp, if you have a degree or not, if you know the framework already or not; people from the "wrong background" can still be hired if they can demonstrate they are sufficiently smart and conscientious to start working on one of the various problems you need work on yesterday. The fact we have to proxy this with whiteboard hazing sucks, it's expensive for everyone involved compared to just asking for ACT/SAT scores or the results of a previously taken IQ test when available and giving an IQ test when not. In my own interviewing I try to proxy for "smart & gets things done" (because that's all my teams at my current company have needed) in a less asymmetric/aggressive way while answering other questions since we can't hire everyone. But even the aggressive whiteboarding is better than every job interview screening for highly specific backgrounds and/or trivia knowledge...
And I agree that BFS/DFS is appropriate, though needlessly so (i.e. there are even simpler questions that take less time), as a first step in answering the business goal which is simply verifying: can this person who says they can program, actually program? Unless you're willing to train people to program, you have to start the cutoff somewhere. It's modestly appropriate to answer the question of: does this person know their craft's basic tools?
This is where I have a problem. Why are we the only industry that has this expectation of months of preparation? Engineers don't do it. Doctors don't it. Professors don't do it. Why?
An analogy from finance: if you take a pen and a paper, and think about it for a few minutes it'll be clear that buying a stock and a put option is equivalent to buying a call option (and a bond, since you're also locking in some capital). This is fine, and most people can do that. But the brilliance happens only when such things are immediately obvious to you, in the same manner as you don't need to consciously decode English while reading this sentence. It's another question whether this or that particular company really needs brilliance.
(not accounting for the people who are just bad at writing anything on the spot in a high pressure interview situation, of course)
My guess is: not very many.
Let's make up a synthetic problem, like "the closest friend which has property X". Then you'd first check all of your direct friends for X, then check friends-of-friends for X, then check friends-of-friends-of-friends for X, and so on. You'd go on forever until you either find a friend with property X, or run out of time/space.
This is the classic BFS problem, and I can see how it would make a good interview question.
DFS or IDFS can generally use space proportional to the diameter of the graph, which is far smaller.
That caveat with BFS turns out to be so bad in practice that I've never seen the algorithm used in practice, outside of a classroom. And indeed, I first thought the point of the question was to elicit this complaint. The interviewer wasn't on that page, though.
The problem being asked was considerably more complex than "closest friend with property X". I don't recall the details, but perhaps it was something more like "find the ten shortest friend paths to (a unique but unknown) someone with property X, where those paths share no nodes".
My assumption for the Facebook graph would be that there is basically no way we can traverse it all, so your only hope is to find the path without expanding all the nodes. DFS will not work for that at all, but both BFS and IDFS may give you practical results.
This leaves the question of BFS vs IDFS, and that depends heavily on the details of the problem. For example, if the graph is already in RAM, then IDFS would be the best. But if the graph is not already in RAM, and you have to fetch it (from database or remote API), you'd definitely want the caching between successful IDFS rounds. And if you do that, then you might as well do BFS -- approximately the same memory performance, and much easier code.
As for usage, while BFS itself is not used this much, it's more advanced versions, Dijkstra and A*, are used all the time in graph traversals. For example, in many computer games, navigation apps and robotics planners.
(And back to original topic: if we had conversation like this during the interview, then you would likely get good score from me, even if I was fully convinced that BFS is the only way to go. After all, I am not testing for the specific bot of trivia -- I am testing for the ability to reason about algorithms)
Maybe, but for "find the closest friend with property X" basic DFS is completely useless. It's likely to give you some distant rando with property X. Fast, sure, but not useful if you're looking for a friend.
Besides, if you have cycles in your graph, DFS also needs to keep track of which nodes you've already visited, or it's never going to end. Or use iterative deepening, which you probably want to use anyway to prevent ending up with some distant rando. Slower than BFS but consumes less memory.
> "find the ten shortest friend paths to (a unique but unknown) someone with property X, where those paths share no nodes".
Ah, but that's a completely different problem.
Accessing properties of a known object is better handled with the selector pattern. I guess you might use BFS to implement a search feature for user-generated content on the fly? I don't think it's relevant to most FEDs roles making CRUD apps with backend searching APIs.
I agree with the sibling commenter: responses like these are very condescending -- and basically prove the main point of the original article.
And BTW:
Writing an Instagram clone in Angular doesn't really tell me much about your problem solving skills when faced with a unique problem.
Neither do your made-up puzzle problems.
Then the person could not really pull their share. They did a few simple PRs, it all looks good. You gave them the more complex task, and they just could not make it to work. After teaching them basic CS concepts for a while, you give up, and try to move them to backend -- and they do not do better there. Then to do data analysis -- no luck. You really do not want to fire them, but this seems the only way forward.
The resulting experience is painful and time-consuming for the team. You wasted many weeks trying to teach that person and nothing good came out of it. You promise that in the future, your interviews would always contain technical questions, and no one who does not know about big-O complexity would be hired.
The reality is that interviews are broken. Not because of this guys subjective perception that it is so but because for employers you just aren't getting the SNR to justify typical interviews. People who cling to that approach anyway are largely, IMO, motivated by ego and cargo cult (lack of understanding and creativity). In addition, in that context, interviews are also broken because in being worthless, they are demeaning to the candidate who isn't great at tap dancing on your command.
What does work is past performance and actually working together. Both are problematic data to get at so I don't think there are easy answers here. We do a resume review to see if they even claim to have the expertise we're interested in, a very short and simple "gut check" coding exercise (not tricky, just checking they can actually write decent code and tests), a 30min phone conversations where we check that both parties are aligned on what we're looking for, contract to hire, then exercise extreme discipline in parting ways with people that aren't great before converting to W2. Our SNR is pretty good. A lot of people don't want to contract to hire so this system has cons. YMMV of course.
I understand, I've felt bitter about interviews before, I'm sure some interviews were unfair. But I also recognize this bitterness is a weakness of mine, unproductive, unattractive.
The way the author indulges in this resentment would make me very cautious about recommending him regardless of technical capability. An employee who has low tolerance for the massive randomness/unfairness in the world probably would get sick of most companies pretty quickly.
The issue I think the poster is having is they just don’t understand how algorithm interviewers think - it’s totally reasonable to think oh, frontend has a DOM tree usually, so they should know BFS (even though you’d rarely if ever use your own traversal alg - leave it to the people actually researching it, not the person building a frontend).
On site interviews usually evaluate not only technical competency but also whether that person is OK to work with, especially during crunch times. Being able to point to a few github projects is good, but not sufficient. When faced with a question one cannot answer staying positive and trying a few options is often sufficient to get off the hook.
You don't ask a published drug researcher with patents or papers written to build simple molecules out of building blocks during the interview, but in software even senior engineers are asked to regurgitate things from CS202 for decades on end instead of actually acknowledging their accomplishments or talking about their legitimate capabilities.
If every interview you ever took is terrible, then you are probably the asshole.
On a more serious note, I’ll offer as a point of contrast The Sane Society[0], which puts forth that society can itself be sick–despite it’s being the status quo–detracting from the wellbeing of individuals.
[0] https://www.goodreads.com/book/show/40717990 by Erich Fromm https://en.m.wikipedia.org/wiki/Erich_Fromm
Another way to look at it that they're a ... human being, attempting to come to terms with a truly toxic and dehumanizing system.
In response to which my gut instinct is not to defend the system, as would appear to be yours. But to recognize, as the original author does, that the system truly is fucked.
And if we're to maintain our health and sanity -- at some point one has to simply decide to "just say no", and start looking for and building an alternative.
I got this quote after failing google interview in the last round.
"Success consists of going from failure to failure without loss of enthusiasm."
Winston Churchill
You're hiring a software developer, not an actor portraying a generic love interest.
I always wish this too. At my previous job a (also at BigCorp) candidate reached out to ask why they hadn't been selected so I started putting together a little email for them trying to give polite feedback and encouraging them to apply again in a few years (they were great, but we needed a more senior role and had no open junior positions at that time). I asked my boss to review it and make sure it was okay, and he told me that under no circumstances do we ever give candidates feedback because if you say one wrong thing it's a lawsuit waiting to happen. Having been on the interview side where I really wanted to know how I could have done better, I was a bit angry on behalf of the candidate.
Wow, how widespread is this? I've _always_ asked for feedback and I've gotten meaningful feedback maybe once.
Even just ignoring any liability, someone who's angry about being rejected might also respond with reasons that they are qualified or whatever and just burn up more of everyone's time. Then sometimes the reason that a candidate wasn't picked has nothing to do with them, and that's not really something you should share.
Strongly disagree. Personally, it would be such a weight off my mind if I heard I was passed over for someone with a few more years of expertise in the target domain, or were a well-known expert, etc., or that suddenly the company is no longer able to bring on another person.
Not having to guess if it was something I said behaviorally, or if I didn’t solve a problem to their satisfaction, would remove so much frustration.
I’m a smart person–I realize that there are many other smart people out there, even smarter than me! It’s perfectly reasonable and expected that I might be competing with some of them, and it is perfectly fair and good that they win out.
A step beyond that, a surprising number of people think that that particular law applies to any age. Even if it's thrown out it may cause legal or reputation problems anyway.
No.. because all you have to do is demonstrate that you followed standard procedures.
Your lawyers would respond to their lawyers with appropriate policy documentation, and their lawyers would tell their client that there likely isn't a case.
The only way there would be a case would be _if_ the person could find others who had received feedback.
Of course. But every piece of information the ex-employee has is potential evidence that could be used to support a discrimination claim, and since you don't know what other information they have it will be able to gather and how any feedback you provide will look in light of that, the simple solution is to provide nothing.
With that said, my interview process basically is:
* 30 minute intro call to dive into the CV a bit and see if it's worth everyone's time to go further
* 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job
* If that goes well, 30-60 minutes to meet with the team and figure out if everyone will get along
That's it. No whiteboarding, no FizzBuzz, no algorithms. If we make a mistake we try to recognize it within 6 weeks of the person starting in that position.
This advantages people who have actually used that language/framework for prior jobs. If that's a thing you want to optimize for, then that's fine. If you want to evaluate people as more generic software developers, it's not so great.
That's why whiteboarding algorithm questions can be useful. They're sufficiently abstract to generalize to lots of different 'stacks' and experience levels. If you just want to get generally competent developers first and then figure out where to put them later, then this type of question can make a lot of sense, which is why Google, Facebook, et al. use them.
It's certainly true that studying these kinds of questions helps, but if you're not too bright, I don't think that would take you very far.
When you’re doing tools for programmers, it gets a lot more complicated. That is not most jobs.
If you are good dev, you will pick up any language/frameworks quite quickly if you want to (there are exceptions, like switching to completly different paradigm e.g. from JS to Haskell, but that is not our case).
I think the 6-week "probation" period is an excellent idea. Since most of the time you can recognize if they are a good fit or not.
It can be a real drag to try and suss out who actually has real contributions or real original work on their GitHub. Our approach for hiring is to actually have people cherry pick out one or two items they're really proud of and have them send a brief overview / sample.
That approach is also nice, because it gives you a great interview starting point to dig into a technical item that they (should be) comfortable with and passionate about.
Making the person pick out projects they are proud of is a great idea.
We all know devs who write beautiful code but are impossible to work with ;-)
I don't do side projects. I work 40+ hours a week on a computer, when I get home, I'm spending time exercising, with family and friends are just doing nothing.
If a company doesn't think I'm "passionate" because I don't have a Github account so be it.
Also, I'm not going to do a dog and pony algorithm white board coding test. I'll draw out architecture on a white board but if you want me to code, sit me behind a computer and test whether I can solve a real world business problem.
I'm most likely being interviewed to either write/architect a bespoke internal app or yet another software as a service CRUD app. I'm not being interviewed to create software to put a man on the moon.
An hour of pair programming lets you know what it's like to work with someone. Are they reasonable to discuss things with, etc. On top of learning about their programming and problem solving skills.
I do like this "homework" interview variation: You get to work on a task at home before the interview at your own pace for a few days. Then you come in and talk about your design choices, and are asked to add a feature or two to your code.
How common is it to actually be able to do this? I've worked at Google and Amazon and Goldman Sachs; I can't show any of that code. I've occasionally dabbled in coding little scripts or projects at home, but nothing terribly challenging or complicated.
I have however dug into github code that seemed legit, with the candidate claiming to be one of the primary developers of a popular Xbox360 emulator. I surprised him by quickly finding obscure bugs, including a couple buffer overflows and a way to cause a math exception in the host process.
It does feel kind of unfair to those whose code is locked away under NDA.
I can't think of another industry that is as high paying as software development, with such a low barrier to entry (formal education matters less and less) with such transparency regarding the interview process (books, blogs, literal guides from the company itself). And HN is flooded with a couple of posts like this every single month, is it perfect? No. What is? At the end of the day this just looks like entitlement.
If the candidate has no resume and nothing to prove they have any skill then yes, give them a rigamarole. But for don't ask a staff artist to speedpaint you the view out the window with crayons in a lined paper binder in half an hour. They give you their porfolio, you inspect it, and if they are accredited and recognized you don't waste their time on quizbowl.
Arguing about it though is mostly pointless. The awareness is out there that these companies are throwing away not just the on hand candidates they turn down for failing their charade game but also the legions of potential employees turned off by the theatrics and immaturity of software hiring. The OP is absolutely right to say interviewing in tech is draining because you go from thinking yourself competent on the outside to interviewers trying to beat you into a sobbing mess on the inside. Its adversarial from the start at almost every company, it certainly contributes in large part to the lack of women participating in development, and businesses seem to be just fine with the outcomes since they know what they are doing is awful but so long as they are "hip" and popular they can get away with it, with an endless list of potential hires to give the rigamarole to.
This jumped out at me. What do you think is analogous to that accreditation in the software industry?
That doesn't preclude spending some time to insure your candidate isn't plagiarizing their cited works, but that is a problem other industries have solved well for years without turning the process into an adversarial circus.
I had the same impression, particularly driven by these quotes:
From this day on, I was even more disappointed — both with myself and tech hiring process — rejection, rejection, rejection. It honestly feels as if I am a complete failure and an unhirable candidate. How is this possible — I have received emails from people all over the world, who praise and give me thanks for the work I’ve done on my open-source projects and tutorials (and I say this as humbly as I can); people who see me as an expert on Hackhands; co-workers, friends and acquaintances from meetups, hackathons, conferences who apparently think I am a decent programmer—but I cannot pass a single tech interview. How?
TBH, the author sounds like someone who went to the interviews completely unprepared, believing that just because they have some open-source projects and tutorials, they deserve to be hired.
Nobody deserves anything. Most of my friends who went up for interviews with FAANG (or whatever is the latest acronym) studied and prepared for months even before applying.
I'm pretty sure doctors don't have to go get their high school bio textbooks and review cell structures to get hired at a new hospital.
It is absolutely insulting to someone who can prove a substantial history of productive software to ask them to spend hours doing trivial brain teasers for them. If you have open source projects under your ownership or substantial contributorship that the company you are applying for is using and they still treat you like a wet graduate coming off a brief affair with Java Swing you should feel insulted.
Doctors have to go through over a decade of accredited education and training to even apply to be a doctor at a hospital. It is a restricted and regulated profession. Software development is nothing of the sort.
> absolutely insulting to someone
Wow, this really sounds like entitlement.
You don't deserve anything. Nobody knows how you developed that "productive software". Did you have help from a friend? did you take 10 years longer than someone else would? Did you copy some of it? Did you work alone and would be useless if you had to interact with others and work as part of a team or project?
Sure, when you're a widely known developer with plenty of real accolade (not emails or tweets), then you can expect to be treated differently.
Until then, don't expect to be treated any differently just because you have some code on github.
If I'm applying for a Front-End Developer position, the interviews can ask CS fundamental questions, or things I maybe learned by reading Cracking The Coding Interview, or doing HackerRank problems; or they might ask specific questions about any frameworks or libraries listed on the job posting, or they might ask more software architecture / system design questions, or they might ask about the Software Development Life Cycle, what is Waterfall, describe AGILE, how do you write testable code, the deployment process, security vulnerabilities, etc.
Maybe all of that doesn't sound so bad to you, but for a young, mostly inexperienced developer who is trying to get a better job, it is daunting.
I would add that a lot of the job entails quickly learning new things and solving new problems. For example, just yesterday I had to work with RavenDB, which I've never seen before. The complaint that you shouldn't need to know how to, say, write a BFS because you never have to do that IRL has only surface validity when you consider that much of your job amounts to doing things you've never done IRL.
In other words, if you can't (re) learn certain CS fundamentals in preparation for an interview, perhaps you'll have trouble on the job as well.
This isn't to let interviewers off the hook, however. Standard whiteboard problems like "reverse a linked list" are still suboptimal, IMHO, and even with these, there are better and worse ways to handle them. Do you focus on the interviewees reasoning and use the problem as a basis for deeper discussion or simply focus on their end result? Do you treat Sr & Jr interviewees the same? Do you seek out curiosity and ability to learn or a specific knowledge set. IMHO, if the latter, you're probably doing it wrong.
If you're a junior that makes perfect sense. As a senior developer, you can spend as much time as a junior preparing for these entry-level coding tests and perform just as well. And that's the problem.
I'm a significantly better developer in all ways now than I was when I was a student and could rattle off answers to these questions without breaking a sweat.
If you can learn to be an expert interviewee in a couple weeks then what's the point of the questions? If they're testing such simple easily gained but useless knowledge (as noted by requiring you to study for it) then how does it even filter out good candidates from poor ones?
Also previous discussion: https://news.ycombinator.com/item?id=11579757
If you balk at breaking down a relatively simple and straightforward problem into approachable steps that a computer can interpret, then what exactly do you think that programming is? You don't need to _know_ the algorithm. You need to be able to think like a problem solver. And if you can't do that, then what exactly are you doing?
> Anyway, that did not go too well, obviously, because it has been a long time since I took an Artificial Intelligence course in college
You should be able to do this even if you've never done it before. You have a start, you have an end, and you have decisions to make to get from the start to the end. That's the literal definition of programming.
The only people I know who think that basic pathfinding is some voodoo dark magic artificial intelligence problem and not just a simple straightforward algorithmic process that you should be able to do in your sleep for the rest of your life immediately after the first week of Intro CS 100 are not software engineers.
Programmers tend to be good at putting their head down and solving a problem. They tend to be very bad at live coding for someone whose job is to judge you.
A hiring process that measures you on the latter rather than the former is broken. It's like interviewing a novelist by asking them to extemporize a speech for you.
It's very annoying that every attempt to make the case against the latter is met with people equating it with the former. They're very different skills.
Maybe for some people evaluating performance in live coding is a good proxy for evaluating their programming ability in general, but it's pretty obvious that there are a ton of excellent programmers for which it's a terrible proxy.
Please don't generalize about people this way. It's not useful, and it's almost certainly a bad idea to hand-wave away not being able to think through something trivial with an audience.
If someone asks you to identify whether a bird in a photo is having a good day or a bad day, then it's reasonable for you to say "Wait, what?" Because that's a research problem that covers a whole host of different subjects (bird psychology, for one) and doesn't have a solution.
If someone asks you to implement efficient image segmentation, something that you probably don't know how to do unless you have a PhD in computer vision, then it's reasonable for you to say "I don't know how to do that but I can go home and research how to do it".
But OP wasn't asked to solve a hard problem. OP was asked to solve an incredibly simple problem and got angry about it.
> It's like interviewing a novelist by asking them to extemporize a speech for you.
OPs given scenario is more like interviewing a novelist by asking them to put a handful of words in an order that constructs a grammatically sound sentence. If you can't do that, then they don't want your novel.
There is just too much legal risk from doing so. Too much risk of wording being misinterpreted and being turned around to be discrimination etc. To provide feedback you'd have to have so much oversight and absolutely ridiculous levels of paranoia about the potential interpretations of what you'd said that the risk is just not worth it.
The value giving feedback to candidates provides to the company is next-to-nothing as well, especially for the larger companies.
One of them was very important though. A friend of mine in college graduated from a degree program with a 100% employment rate but for 2+ years could not get a job. Anywhere. He was a really charming, funny and smart guy. Interviews always went really well...but nobody ever hired him.
One time, a guy who interviewed him called to tell him that he was sorry but they'd gone in another direction. He basically broke down on the phone and begged the guy to help him understand WHY this kept happening to him after 2 full years.
The culprit, it turns out my friend had a DUI on his record. He's never actually had a DUI but he was pulled one night after working at a bar and the officer arrested him for DUI anyway. There was nothing in his system but he had to stay overnight anyway for some reason. The arrest was never removed from his record and he had no idea it was showing up in background checks.
Once he got it corrected, he got a job almost immediately and is doing really well now, 15 years later.
I honestly wonder what would have happened if nobody ever told him about the problem.
I'm also not totally sure about the minimal value of feedback. I interviewed at IBM several years ago, and actually did get useful feedback from the hiring manager. I was referred by someone way up the food chain and the feedback was fairly non-controversial (unlike my background, the job was much more business than technical), so maybe this was unusual.
However, the fact that someone was willing to spend 5 minutes explaining why their decision–and outlining some steps I could take to make myself more competitive—gave me more positive impression of IBM than their 3,000 different Watson commercials put together.
We never had any lawsuits, but from that perspective I totally understand how the company I worked for (employs over 100k employees) saw every employee as a walking liability.
How about having them sign an agreement that the candidate would under no circumstances sue the company for the rejection? I would sign it in a heartbeat if I received some feedback.
The internet makes it possible screen a zillion candidates, so like dating it feels like there are a million fish in the sea. Why value anyone's time when there is so many to consider? I was thinking about putting my CV for a very senior role and before you could put it in they made you take this like web IQ test. Seriously? I would worry about anyone who go through that for a job that expected more than ten years high level experience. Pass.
Also, failing five face-to-face interviews smells of personality or culture fit issues, not tech issues, IMO. I've interviewed tons of people over the years, and the ones that pass the phone screen but fail the tech screen usually failed due to poor culture fit (or padding their knowledge a little too much). I would see if it's possible to message one of your past interviewers and ask for a honest opinion of what they thought of you. While you're unlikely to get a response (giving interview feedback is, sadly, a big HR no-no), some people might budge on your offer.
Good luck?
I do this problem constantly on my laptop when I'm looking for files and start getting annoyed at how long a search is taking. You start applying -maxdepth to a find command and fumble through directories perhaps and do a for loop. This is how I wind up doing a crude variant of k means clustering using cut, sort, uniq, and some creative use of awk when trawling through a bunch of log files.
But I do feel that anyone pretty serious about programming as a career understands there's little to be gained by more or less bitching about the state of hiring and a lot more to be gained by spending a few hours or so working on some problem sets occasionally. We're all busy and have to keep our technical knowledge up to date of course, but almost every well paid professional has to do this (doctors and lawyers are required to do this to even practice, in fact). I don't bother interviewing for FAANGS because my brain's fried and burn-out makes working on interview prep an order magnitude harder, but I don't go around blaming everyone for acting in their own self interest either.
I know many recruitment teams aim for soft skills first because they don't want to bother their technical staff if a candidate is not a good match.
Many algorithm questions are designed intentionally to see how you tackle an uncommon problem or even an unfair situation and to see if you have a strategy to solve it. Of course, a candidate invited for front-end position at a decent company knows how to tackle his common tasks regardless of how complex they are in comparison.
However, that is definitely not true about all interviews. Many companies just copy these interview formats without understanding what is the actual idea behind them. Or how to facilitate these interviews correctly with different candidates from different cultures in different situations.
But you shouldn't go to interviews with this assumption. I'm sure at least one of those BigCorps had a professional recruiter.
After all, hiring a professional recruiter is as hard as hiring a good software engineer.
He asked me a question like "You're shrunk down to a couple inches in height and put inside a blender. How do you escape?"
My response was "Is there anything else in the blender? Can I see anything nearby?"
He told me that I "already passed", but if it was an interview, we'd probably have a 1 or 2 minute conversation about it and then move on. The fact that I didn't start rattling off ideas, but instead asked smart questions, was what he was looking for.
It's easier to take a measure of someone if they can't figure out what they're being judged on. If they know how they're being judged, they optimize for just that one thing.
Now, this raises the question of why our society's method of educating people (or determining if that education has been effective) is not very well correlated to their real-world performance, but that's a whole 'nother conversation.
I work somewhere on the border between neuroscience and machine learning. Interviewing in a "neuro" group usually involves a lot of talking--what you've done on project X, how would you approach Y, what do you know about Z. Coding does come up, but in the context of stuff that I've done or would do on the job.
Applying for a very similar job in a tech company usually starts with me reversing strings on a whiteboard or abusing C++ templates to calculate factorials or something....
It's actually initially a bit surprising that BFS has such a simple algorithm using a queue, as mentioned elsewhere in this thread and in the Wikipedia article about it [1]. Might be non-intuitive on first look, but then turns out to make perfect sense.
function bfs(list, cb) {
while (list.length > 0) {
let i = list.find(cb);
if (i) return i;
list = list.map(i => i.cn || []).flat();
}
}When I interview people, I want to know if they can think. I want to know what their attitude will be like (to work with/near them). I want to know what gets them excited (in the context of work, mind you).
The older and/or more things a candidate has done in their life, the more accumulated wisdom they will have. This will translate into making better choices earlier (about approaches to problem solving). Testing against university compsci concepts is more likely to get a candidate who will either ignore a well tested and commonly understood library in favor of rolling their own (less-maintainable) code.
Also I've never heard of this guy, not sure his handful of Medium articles and cookie-cutter tutorials is sufficient justification for his belief that Google should be lucky to talk to him.
If the company doesn't extend an offer, it's because I didn't show them the value I can deliver their organization. Either I didn't present myself as a teammate that makes the group stronger or I didn't present the technical skills to make them realize the talent I bring individually.
Maybe I'm lucky -- it's a low sample size.
But I suspect that we all can do better at interviewing and at selling ourselves. Traditionally, that's a weakness in engineers.
It's also why, when I'm interviewing, I try to remind applicants what I need: give me something, anything I can use to sell you to my manager -- to argue "yeah, this cool guy is the right business choice". Help me help you. If you can't, you won't get hired.
I agree that it's common for interviewees to sell themselves well.
You know what I would be more interested in candidates knowing? Solving problems that have no immediate answers. For example, understanding how to architect a program without using a framework, Debugging a bug even though you know nothing about the library you are using (eg. Be able to read code and race the problem), and understanding the difference between algorithm and architecture in overall performance of a system.
You can memorise algorithms. You can’t memorise problem solving and architecture. Albert Einstein said something along the lines of, “Don’t memorise knowledge that you can look up in a textbook.”
What have you learned since becoming a programmer? Did you push your knowledge of programming or are you rushing to the next hype framework? I see many more of the latter than the former.
Knowing algorithms is like optimising for the flow of water for your tap in the house without understanding how the pipes layout affects the overall output. And that’s the problem when you only work on one small section of the program your entire career.
Apologies for the rant..
OK, I can accept the fact that in some environments, knowledge of BFS (and the ability to implement it from scratch) can be considered a must-have skill for a front-end developer. (Not in all environments. But granted, in some environments).
But can someone please explain how the need to implement a function like findSum in less than O(n²) -- and in particular: to be able to whip out the sorting trick necessary to achieve it, while standing in front of a shitty whiteboard with strangers staring at you --
Can reasonably occur in an actual front-end engineering role?
It's not even just the attitude. It's the competence too. If you can't code a BFS on the spot, sorry... that feels like far too low of a bar.
I would guess 99% of developers I've worked with couldn't do this on the spot and I've worked on a lot of teams at a lot of companies lol.
https://medium.com/@carlosreutemann/tech-job-interviews-the-...
The coding interview is not about memorizing algorithms!
The coding interview is about demonstrating that you can think from first principles and DERIVE an algorithm!
If you understand the problem and the strategy for solving it, you don't need to remember the algorithm.
I know what it does. Mechanically. I can visualize the recursive divide-and-conquer in my head.
I can implement it in any language.
All you have to understand is WHY the algorithm works.
What you are actually being tested on is whether you can derive A solution. ANY solution. And if it is inefficient, you can figure out what needs optimisation and where.
The very fact you recognize the inefficiency and you can speak up with ideas on how to make it better is data for the interviewer.
Perfect is the enemy of good enough.
If I ask a question and the candidate knows the most optimal solution then it's very difficult for me to assess most of those questions - because they aren't actually thinking through the problem, they're just remembering the solution and I primarily want to hire people who can figure out solutions - even if takes them a little bit longer, because it's indicative of their ability to actually go beyond what's already established in the field.
On another note, OP seems to rely on recruiters to approach him? Wouldn't it make sense for OP to actively apply to positions which may have better fit?
This dude most play League of legends
BFS is a trivial algorithm and you really should know it. It is only a few lines.
Do you work with things that have dependencies? Do you work with hierarchical data? What about hierachical apis? Tree traversal is a powerful tool, and not knowing how to use trees is a sign you may take the stick-and-rock route when it comes to solving problems
So many comments seem to be projecting onto, reading into OPs personality.
It’s true the interviews don’t test your real coding abilities. It’s probsbly very low signal you aren’t going to go in and write spaghetti algorithms (but they will at least be fast).
That isn't unfair, that's just a bad interview.
Last time I interviewed there I got pushed on just about every aspect of knowledge I had, going back over a decade+ of experience.
There was an awful lot of bullshit trivia questions buried in it, though, and a bizarre obsession with apparently expecting me to know every argument flag for a CLI off the top of my head.
bin/
sh
usr/
bin/
local/
bin/
var/
...But secondly, if months of prep is required to work at Google what you're saying is they're selecting for young people, rich people, male people - ie, all the people that can afford to be spending their spare time on interview preparation as well as holding down a day job. Go explain to a mother of 2 that the reason she can't get a job at Google is because she can't spend her evenings and weekends on hacker rank despite a job at Google never really requiring work at evenings and weekends.
As for old people: don't even try, Google has a huge age bias.
Maybe the problem is that they are writing on Tedium.
I sympathize quite a bit with his frustration, but he does a good job of making it difficult to sympathize with him. He goes on about how there are books written on how to interview at Google, yet it's patently clear he didn't even try to read one of them. It's one thing not to know BFS on the spot because you didn't want to prepare. It's another thing to be totally shocked that they asked the question. A few minutes of searching the Internet, or casually browsing the table of contents of several books, would give you an idea of what they want you to know.
And not to defend Google or other companies, but frankly, BFS is not some super complicated academic problem that only smart people can code on the fly. It is one of the more basic recursive[0] algorithms there. So even if you haven't memorized it, it's not ridiculous to expect you to "derive" it.
And equating maze solving with AI. Really?
I've gone to interviews without preparation, just because "Why not?" However, I don't go on a rant when I do poorly on it.
[0] Actually, it need not be recursive.