Yikes... Interviewing sucks but half the reason interviewers ask these types of questions is to see your attitude and how you respond. Writing an Instagram clone in Angular doesn't really tell me much about your problem solving skills when faced with a unique problem.<p>> How many people can actually write BFS on the spot, without preparing for it in advance?<p>Ughhh, should I tell him?<p>> why would they ask me this question, what does breadth-first search has to do with front-end development<p>Tree data structures are really common in front-end.. like the DOM or JSON.
The thing that appears to me, most overpoweringly, is the bitterness.<p>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.<p>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.
> I really wish companies would be more transparent about their candidate rejection reasons<p>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.
Hiring is hard. It's very difficult to figure out what combination of activities/questions will correlate to actual job performance, not to mention uncover someone's day-to-day personality when their guard is up.<p>With that said, my interview process basically is:<p>* 30 minute intro call to dive into the CV a bit and see if it's worth everyone's time to go further<p>* 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job<p>* If that goes well, 30-60 minutes to meet with the team and figure out if everyone will get along<p>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.
I think developers complain way to much about the interview process. The fact of the matter is that it's very clear what type of questions will be asked for most technical interviews and there is a wealth of resources available to prepare. The ROI on spending a couple of weeks preparing is definitely worth the possibility of a substantial raise at a big technology company.<p>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.
Can we get a (2016) added to this?<p>Also previous discussion: <a href="https://news.ycombinator.com/item?id=11579757" rel="nofollow">https://news.ycombinator.com/item?id=11579757</a>
> <i>The first round started with introductions, followed by a coding exercise — write a maze solving algorithm. What the fuck?! Seriously? Mind you, this was an interview for a front-end developer position and I am not a recent college graduate anymore.</i><p>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?<p>> <i>Anyway, that did not go too well, obviously, because it has been a long time since I took an Artificial Intelligence course in college</i><p>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.<p>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.
"I really wish companies would be more transparent about their candidate rejection reasons."<p>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.<p>The value giving feedback to candidates provides to the company is next-to-nothing as well, especially for the larger companies.
There is a hiring infrastructure which is sort of like those dating apps that say they want you to find true love but really they want you to keep dating. I am thinking of a lot of HR at companies, recruiters, and people that enjoy interviewing. I have worked at startups that weren't really growing that fast but we're always interviewing to fill in the churn. Interviewing feels productive, feels like a company is growing. They say: We only accept the best so any test is reasonable. This tends to discount people's accomplishments and the idea that smart people can learn.<p>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.
The core problem IMHO is that a great many of the people hiring developers are not themselves developers and have little to no technical knowledge. Companies depend on these ridiculous hiring processes because many decision makers believe it allows them evaluate candidates that they have no other way to evaluate. They see Google using these approaches and figure if it is good enough for Google it is good enough for them -- not realizing that Google is an entirely different situation with needs that don't match their own (Note to 99% of companies in existence, you are NOT Google and Facebook). I speak from experience. I have been hiring and managing IT staff for 20 years. I also happen to have 25 years of experience in development and infrastructure. One of my priorities when taking over an IT division is to get rid of these useless tests and I have received push back from internal recruiters, HR, and non-technical management every time I have attempted to do this. It requires moving a good percentage of of the hiring process from non-technical management to the IT staff and its not an easy change. Recruiters and non-technical management see it as a threat to their positions. Until there is a realization that you have to know something about a topic to judge the skillsets of others I don't see this improving (I expect that to happen... never).
I disagree with the OP's premise. Yes, nobody is going to write a BFS or `Math.pow()` on the spot, but it's way too easy for people to bullshit about their experience to rely on that alone, so BFS and `Math.pow()` is what we've got to work with. While I'm a proponent of giving interviewers a bit of homework and making the interview a pairing session, there are plenty of people that complain about this being free labor (even if it isn't). OP mentioned earlier that looking these up is easy enough, so what's the harm in looking these up before the interview so you can get that out of the way?<p>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.<p>Good luck?
I'm not exactly a gifted programmer or anything but a BFS seems pretty reasonable in an interview depending upon the amount of rigor / efficiency being demanded. I remember doing it for one of my very first interviews where I was asked to implement a website crawler and hold onto URLs. Having written a lot of them while trying to scrape sites for info before every other site had an API, this was super fast for me and was a very practical problem. It's not like they're asking for a topological sort of a graph where you can use Prim v. Kruskal and now you have to make sure you remember that near the neurons that activated your memory of your 3rd week of sophomore year 2nd semester when you had a really nasty cold. If you haven't heard of breadth-first v. depth-first that should be simple.<p>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.<p>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.
In this regard, A lot of interviews are designed to test soft skills.<p>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.<p>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.<p>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.<p>But you shouldn't go to interviews with this assumption. I'm sure at least one of those BigCorps had a professional recruiter.<p>After all, hiring a professional recruiter is as hard as hiring a good software engineer.
I believe the fundamental problem is, most organizations interview in a style similar to testing in college: ask a question about a technical topic, evaluate if the answer is correct. This doesn't correlate especially well to how well a candidate will program if you hire them, but it's the method people learned in school for evaluating someone's knowledge of a topic, so it's what they use. Most developers, and most managers, have almost no training on how to interview well in order to determine who would be a good candidate, so they fall back on the only halfway-similar experience they have.<p>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.
Breadth-First Search (BFS) and Depth-First Search (DFS) are actually both pretty interesting algorithms (although relatively simple for the basic cases - there are some variations), partly because of their applications.<p>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.<p>[1] <a href="https://en.wikipedia.org/wiki/Breadth-first_search" rel="nofollow">https://en.wikipedia.org/wiki/Breadth-first_search</a><p><a href="https://en.wikipedia.org/wiki/Depth-first_search" rel="nofollow">https://en.wikipedia.org/wiki/Depth-first_search</a>
Many (most?) programming jobs are about understanding the tools and libraries of an ecosystem well enough to build something useful.<p>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).<p>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.
This guy probably got a negative reaction because he says "hiring is broken", when what he meant was "my strategy for getting hired is broken." The goal of "hiring" is for companies to satisfy their needs, not to guarantee that every smart person that comes their way gets a job. A "hiring is broken" article coming from the position of a hiring manager would carry more weight.<p>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.
Usually the people that says hiring isn’t brokens are the ones that benefit most from it. Algorithms and programming are not one and the same. The overlap but knowing algorithms tells me nothing about your knowledge of programming.<p>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.<p>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.”<p>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.<p>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.<p>Apologies for the rant..
<i>I was asked to write a function findSum(array1, array2, sum) that returns true if two numbers from two sorted arrays add up to a given sum. I was able to solve it with my eyes closed using a double for loop — O(n²) time complexity. For the remaining time I was able to reduce the time complexity by converting arrays to hash maps, then finding the difference by subtracting sum from the first list element and checking if that difference is a “key” of the second hash map.</i><p>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 <i>all</i> environments. But granted, in <i>some</i> environments).<p>But can someone please explain how the need to implement a function like <i>findSum</i> 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 --<p>Can reasonably occur in an actual front-end engineering role?
Yikes as an engineer and not a hiring manager, I do NOT want to work with this person, and I would thank the hiring manager that passed.<p>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.
Tech job interviews: the Tinder of labor marketplace<p><a href="https://medium.com/@carlosreutemann/tech-job-interviews-the-tinder-of-labor-marketplace-d5ea644e0501" rel="nofollow">https://medium.com/@carlosreutemann/tech-job-interviews-the-...</a>
Why does nobody get it?<p>The coding interview is not about memorizing algorithms!<p>The coding interview is about demonstrating that you can think from first principles and DERIVE an algorithm!<p>If you understand the problem and the strategy for solving it, you don't need to remember the algorithm.
On the other end of the spectrum, I have little software engineering experience but having dabbled in competitive programming, I can solve almost all algorithmic interview questions optimally within minutes if not seconds. I still failed half of my interviews though (including Google even though I believe I answered every question perfectly). Perhaps it's due to my presentation, or my lacking portfolio, or perhaps the positions have simply been filled.<p>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 candidate reminds me of someone who went on a date and is bitter they didn’t get a call back for a second, despite their qualities that obviously made them the right choice as a partner. Dating must be broken...
The 2016 discussion on this very article <a href="https://news.ycombinator.com/item?id=11579757" rel="nofollow">https://news.ycombinator.com/item?id=11579757</a>
I'm going to join in and say: you should be able to puzzle out the pseudocode for a BFS, not from "memory", but by thinking about the structure of a tree and asking yourself what would be required to touch each node at each level before moving on to the next level. It's not fantastically difficult, and if you can figure it out just by reasoning about trees then you're a smart problem solver that I'd like to work with.
I think the real reason programming interviews have become torturous is to discourage people from changing jobs. It's a kind of unspoken anti-poaching agreement.
I used to feel like the author of this post, but trees have come up at each of my last few jobs.<p>BFS is a trivial algorithm and you really should know it. It is only a few lines.<p>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
Is it just me, or is HN, normally a much calmer and more reasonable forum than almost anywhere else on the internet, actually a little bit flamey and ranty when you get on the topic of tech interviewing? I've seen reasoned conversations about world politics, war, gender issues, etc. etc. on here, and never as much sturm und drang as on this issue. I do not necessarily exempt myself from this statement, btw.
The google interview really isn’t that bad. In fact it’s kind of unfair in the sense that someone who just did leetcode for a month can pass it while also being a terrible coder.<p>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).
If I had to resolve BFS problem I wouldn't bitch about it like this guy, because the only thing you need to know is how to move across the tree. The rest - you can come up with that - it's not that hard and it's showing your thinking process.
I don't get the entitlement of people who try to interview with Google. The ROI of a few months (or in my case years) of preparation for a Google interview is huge. In Google you are supposed to work on things for a year before it comes to fruition (and you get promoted), but people are patient. Getting to know a few algorithms is like real work: you put in the effort and you get a nice paycheck at the end.
Why is it that people who post on Tedium find it hard to hire people or get hired?<p>Maybe the problem is that they are writing on Tedium.<p><a href="https://www.youtube.com/watch?v=_f4oJ-DQdSY" rel="nofollow">https://www.youtube.com/watch?v=_f4oJ-DQdSY</a>
I stopped reading in the middle.<p>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 <i>try</i> 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 <i>shocked</i> 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.<p>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.<p>And equating maze solving with AI. Really?<p>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.<p>[0] Actually, it need not be recursive.