Not to mention that I would feel offended if I'm asked by a hiring team to solve complex logic task while visiting an office for a first time.

Usually what I do as an interviewer is to select a bunch of questions out of [1] github frontend developer interview questions and make a productive conversation, by asking for opinion on different ways of writing front-end code.

1 : https://github.com/h5bp/Front-end-Developer-Interview-Questi...

Kudos to the author for being so forthcoming about his experience. Maybe if enough programmers start making a big stink about this problem, something will actually get done about it.

Having a great resume and stellar github is why you get the call back, an inability to conduct yourself in a professional manner is why you didn't get the offer. Especially in newyork, a medium post from an employee could affect stock prices, you can't have a lose cannon working for you.

What's bugging me about the author is that he dismisses everything that doesn't have direct relevance to the position.

Projects get finished and you still want to work there. Projects get reshuffled and you're placed elsewhere. Your role in the organization changes.

If an interviewee showed such a myopic view of his future work I wouldn't be thrilled. He basically says "let me show you that I'm a one-trick pony", while the interviewer tries to ascertain his capabilities across several potential jobs.

Yes it’s stupid. Yes it’s not something you’ll ever actually do on the job. No it’s not a real indicator of your actual programming ability. But it’s what you have to do to beat this part of the game and move on.

And, yes it sucks, but it’s not THAT hard in the grand scheme of thing. Basically what’s happening is someone is saying “we’d like to hire you for a job that pays significantly above the national average, is safe, low stress and generally pretty easy when you think about it. All we ask in return is that you brush up on some things that you have already had to learn anyway.”

I would also argue that it’s at least partially about seeing how driven you are. Everyone knows that you’re probably going to get asked Algorithm and DS questions in an interview. There are literally several very popular books entirely dedicated to that fact. So you can either have a self-centered, egotistical, “I don’t think I should have to know this and I know better than everyone else so I am not going to learn it” attitude, or an open, eager “I really want this job and I know they will probably ask me some of these kinds of questions, so if I have to take a week to brush up on these concepts I am more than willing to do so attitude.” Which do you think makes for a more attractive potential employee?

Essentially that's what is going on. Easier to exercise your biases when the default is "don't hire."

If you know your stuff you usually can separate bullshitters from good people.

This has worked pretty well for me so far.

Since then I think one of the best approaches is to come up with work related problem, leave person to solve it with computer, keyboard, internet etc. with no time limit (if candidate can't solve the problem, they will give up and just say it after 2h or so). Quick chat about the code afterwards will tell you in 1 minute if person understands it and didn't copy pasted solution etc.

I spent a few minutes trying to recall how it would work and I couldn't, and it seems like a fully working Math.pow is a little complex for a gatekeeper question – or maybe I just forgot the trick.

Even for a front-end developer, I think that algorithms matter, because developers have to understand what they do.

And the OP's solution in O(N2), as well as the other one with hash maps, seem quite bad (it can be done trivially in O(Nlog(N), and optimized to reach O(N))

Interviewing should be about finding a fit between a worker and work that needs to be done. The best predictor of that is past success doing similar work. It's not about imitating Google's process, and except in increasingly rare situations, it has very little to do with academic computer science.

And there is never a need to treat anyone rudely. So don't.

    crontab -e

    30 9 * * * cd /mycode && git add . && git commit -m "Woo!" && git push

    service crond restart

The best approach to getting hired (especially if you know you are good) is to reach out via your personal network. Get in via contacts and recommendations. Always keep pushing your existing coding profile at every point of interaction.

Is that really necessary?

I was going to turn down the position in the end due to cultural differences. In the end I didn't get the position due to lack of technical proficiency though I was only asked behavioral questions.

Waste of time.

You must have lost your mind.

And that's not even going into the salary/H1B issue, the problem is much deeper than that.

- I was an advocate at first, but take home exercises are pretty much useless. Because they at best won't fail you. And of course you could have written a new sorting algorithm that works on O(n) but what you'll get back is a complaint about coding style

- Having a github might be nice but as the article says it seems to be also in the category "won't fail you". It seems to barely matter

- And of course companies like Google ignore everything and make a test out of your interview, fail/pass grade, period.

People are probably missing an empathy component or working outside of the "SV tech clique" where if you don't code for 12h per day and doesn't know all libraries and algorithms by heart you're not even considered

So just who the hell is passing these inquisitions? What's really necessary?

I think it comes from a decade of experience of being asked to jump through increasingly ridiculous hoop sizes over time, and complicity cooperating with this nonsense system in an otherwise analytical logical calling.

The challenge is finding these. Careful filtering can help, but it seems to be largely a numbers game.

This becomes increasingly difficult, as more companies are infected with these faddish processes every day.

And there's a cost, of time and money and contentment. To help reduce this, consider spending increasingly less time on opportunities you deem unlikely to work out, based on past experience.

I often prequalify jobs--sometimes companies respond, sometimes not, but that also provides me with useful information.

Once you bring someone in for an interview, you owe them a phone call, with email as a backup.

I'm 100% self taught, having never set foot in a CS classroom, and this is what I do for every interview process: 1. Find everything you can about company and their interview style; 2. skim over Algorithms in a Nutshell; 3. Take an hour to refresh Big O notation; 4. Read up on "best practices" for the technologies the company uses.

Finally, after the interview always follow up -- say something nice and memorable, be humble and express interest in learning their technology stack _before_ your first day on the job.

I find it takes 2-3 company's before I hit my "interviewing stride".

I wonder if just writing a brute-force maze solver, and then explaining that you are aware better solutions exist...but that you didn't have any memorized, would have sufficed.

Is this Hacker News or Script-Kiddie News?

They treat you like hobo that came to their kingdom begging for a cookie.

They are the kings and queens and you are nothing just a pathetic beggar.

It's really exhausting and painful to go through it again and again especially when you know that most of the companies are just wannabe hipsters or the same corporate hellholes.

They pretend they are on the same level as Rob Pike and alike but what most of the people do is they write shitty code, shitty UI and shitty everything.

Google is definitely worse they cannot really make a compelling product that would DIRECTLY earn them money .It's all about ADS.

A typical adult has the spare time to study 3-5 algorithms prior to an upcoming interview, and the algorithm question lottery has room for several hundred.

This means that the practice of trying to stump them with algorithm questions provides a strong benefit to hiring managers: can this candidate read my mind even before I've decided what it is I will ask of him?

They're selecting for psychic powers and do-what-I-want-ness. Which is what most management in the United States (elsewhere probably, but I'm an uncultured redneck type... wouldn't know) values.

The two job offers I did end up getting went something like this:

1. "Show me a project you worked on. Tell us about it. Tell us about future features. Okay, implement one of those features right now."

2. approaching me after an event I spoke at "Hey, are you by chance looking for a job? We'd love to have you with us." at "interview" "tell me about your past experience, some projects you worked on, and how you learn new things."

I feel like both of these "interviews" tackle two very important things as a software engineer--can you use what you currently know to add a new feature? And if you don't currently know it, do you know how to find it out?

I didn't know a lick about React, SVG, animation, databases, lodash, es6, or trees, before I started working at my current job. But because they were able to see how quickly I could learn new things, I started as a contractor (to "test the waters" so to speak) and impressed them by proving them right.

And I think that's exactly what companies should strive for--hiring people who can pick things up quickly. Of course, consulting firms may not have this luxury, because they need to deliver now now now, but for SaaS companies, I don't see why this method wouldn't work.

Some areas of programming will require specialized math knowledge of course i.e. basic linear algebra for general game programming, and various algorithms depending on your specialty. But in any programming field you will almost never be expected to research new algorithms from scratch - this is the job of scientists - and your job is just to implement those, and know enough to choose the right one for the job.

This is just a long winded way of saying, I think a lot of HR departments need to clear up for themselves what it is they are trying to recruit. If they want people researching, you are going to need the algorithm/math/physics chops inside and out, but if you are building 98% of the not so super theoretically revolutionary products out there in the world, you really just want to hire people who know how to pick the right tool and then use it i.e. code with it. And to know how to pick the right tool, you do not need a PHD in CS.

HOWEVER. One candidate had a PhD and was very agreeable, had lots of experience in other companies in our field. So I skipped the programming test, since I figured a PhD with loads of experience must be able to code...

A colleague of mine saw the candidate as they were leaving and ducked. I asked them why. "Well, I personally lead to them getting fired a few jobs ago." Turns out Colleague worked very closely with Candidate and Candidate can't code worth shit: Colleague ended up personally redoing a ton of Candidate's botched work, Boss noticed Colleague working way late for no good reason, and after several chances, had to let Candidate go since they couldn't do their job.

Anyway, I've come to the conclusion that I need to ask in-depth technical problems, but I'll phrase it like this: "I'd like you to describe an A* path-finding algorithm the best way you can (pseudocode, diagrams, assembly, whatever). I'm not looking for a 'correct' answer, or syntax or class diagrams. I want to watch how you solve problems of which you only have a vague knowledge. If you'd like to refer to some resource, feel free to ask, and I'll tell you if I know, or I'll find out."

I suspect this is the point of the technical question, but it's hard to tell what interviewers actually want.

Now, about the real problem -- It has to be solved by both the parties, for instance, somewhere in the middle of the article the author mentions he was asked to write the BFS algorithm. In this particular scenario, the interviewers should NOT expect the candidate to actually remember the algorithm and write the solution right away like a bot (or a human who has used it very recently) would. Here the interviewers can be more humble, more human. They should check whether the candidate holds the problem solving skills which is what is essential and NOT whether the candidate has a computer-memory. Here, they could explain what BFS is, how it works, and then give the candidate some time to come up with a solution.

Again, interviewers shouldn't expect a correct solution for the problem, it's the attitude of the candidate towards the problem, and the way he/she thinks about it -- that should be enough to give some idea about the skills he/she holds for problem solving.

The idea is simple. Don't just drop some Dothraki (or some language the candidate does not know) algorithm names, and ask what it is instead, skip the names, explain the problem in simple words and ask for solutions.

> it has been a long time

> I vaguely remember

> this would have been a trivial problem to solve from memory, but that’s besides the point

> Do I remember how to implement those algorithms? No

> I am not a recent college graduate anymore who has breadth-first search memorized

> I haven’t implemented BFS in years, there is no way I can come up with a solution right here and now

> If, and when [...] I will go look it up

I normally wouldn't point it out since it sounds really condescending, but after https://news.ycombinator.com/item?id=11554894 I don't know what to assume anymore:

They don't want you to remember or memorize solutions, they want you to be able to implement it given just an informally explained approach (which you may also be responsible for coming up with).

Converting ideas into code without having seen the code before is a realistic, desirable and not at all uncommon skill.

I don't think it's unreasonable to expect a candidate to be able to write code given the description "These objects have a value and links to similar objects. We want to find a certain value by first looking at all our nearest neighbors, then at their nearest neighbors, then at theirs, and so forth.", even if they had never heard of graph theory or BFS, or seen code for it before.

The real issue is why is a front end developer expected to have an education in algorithms? Part of the problem is that programmers doing the interviewing like to show off, instead of focusing on the requirements of the position. I remember the first time I interviewed someone. His resume said he knew C++, so I asked him about the intricacies of templates. That revealed that his knowledge of C++, like that of many people in the early 2000s, extended only to "C with classes." Gave a negative evaluation. But in retrospect, all our code was C with classes so what did it matter? I was really just showing off that I had read TCPPPL.

If you evaluate two similar candidates, candidate A on their github and candidate B on their performance on Hackerrank then it's incredibly hard to fairly compare those two candidates without adding subjective bias.

In practice what happens is the company goes "oh well the person with a github clearly has more initiative". But is initiative part of your evaluation process ? - have you ensured you've fairly allowed all candidates to demonstrate it, or have you ended up evaluating candidates unfairly on totally different metrics.

If you're hiring you can vastly improve your hiring process by doing two things: (1) Adopting a standardized structured interview where questions map directly to your needs and (2) using a work sample test (getting candidates to do a small piece of work that resembles real-world work as closely as possible).

I've been tested on code, but it's never been these inane tidbits everyone went through getting their CompSci degree. Anecdotal, I know.

1. If they just went by open-source contribution and prior experience, the pool of "qualified" people would be immense. You need some way to narrow them down, and it's fine for a company to pick their way, be it CS questions or how handsome someone is (joking) or how easy they are to talk to and interact with (charisma). It's not just about pushing code--lots of people can do that.

2. Questions like these are not totally unnecessary. Even though you won't be dealing with CS questions regularly at work, they still show that you put the effort in to learn them, and that you can think critically and on the spot to solve problems.

I don't think hiring is as broken as people make it out to be. Just learn the science and study up on it a lot before... I even bought a book that is a summary of common CS problems that interviewers ask. It's not a big deal for me to just read it up for a couple hours a day for a couple days before my interview. Good companies are looking for people who are ready to put a lot more effort in than just brushing up on Dijkstra's algorithm.

Note: One of the greatest things I learned from 5 years of undergraduate school has nothing to do with coding or science. It's the ability to just shut up and get some work done. Even if it's hard, unnecessary, or it's difficult to understand the motivation behind being assigned it, it's a useful ability (for growing professionally) to just crank out some work when you're told to do so. Many times, it takes doing the work to understand why you should do the work. Then that lightbulb turns on and you realize how much you've benefited from learning Dijkstra's algorithm and applying it to something; it's pleasant.

I've been rejected many times. And every time, I come away from the process annoyed and disappointed, but certain that I would have been useful to them had they hired me. I research companies thoroughly before going into interviews, and don't waste time interviewing for positions that I don't think I'd be interested in / qualified for.

I also have decent GitHub activity, handful of open source projects that demonstrate my abilities. When I started my new job search I assumed that this mattered, but in my experience it really doesn't. I still get asked extremely basic questions that I'd hoped my GitHub would eliminate. In some instances the company that rejected me had some open source projects, and it made me feel better about myself to see their poor code quality.

Nevertheless, I am also starting to have doubts about the industry. I've wasted a lot of time on take-home challenges, introductions, technical phone screens, on-site interviews, etc. to be rejected without explanation. As an introvert, it's all very exhausting. Why should I, as a computer programmer, have to be an amazing socialite that my colleagues would like to vape & play air hockey with? I just want to work on interesting problems. I'm not stimulated by extravagant team lunches or interrupting meetings to play with the company dog. I'm not stimulated by fancy windows and games and snacks and toys. I'm happy to have technical discussions all day long, but I really don't want to work in a frat house.

I feel like there's a lot of pressure from the industry to be someone I'm not. Also, it seems like the Joel Spolsky idea about only hiring exceptional programmers (at the expense of risking a merely /good/ hire) has seriously penetrated the industry, making the system highly risk-averse in terms of hiring. I feel like no amount of prior job experience or open source work will make a difference. Every time I interview, it's a clean slate, and if I don't nail _everything_ it's a certain no-hire. Even if I did well in prior interviews with the company, they simply won't risk it. I would really like to know what the reasoning is, but they never provide feedback.

I will say that I've been hardened by the experience. I'm better at pitching myself, making appointments, talking to people in a structured way, preparation. I think if any startup founders lack experience as sales(wo)men, there's plenty of opportunity to dial-in your skills by pretending to be a job candidate strictly for practice.

1) Simulate a real work environment. This means a dev machine with full access to the web. One thing I'm looking for is how good the candidate is a finding information they don't know.

2) Customize the questions for the job at hand. A software tools dev is a very different position a firmware dev. I wouldn't, for instance, expect a firmware dev to know much about regular expressions. And I wouldn't expect someone interviewing for a scripting job to know much about alignment on ARM.

3) Test your questions on coworkers and friends. You need to get a baseline. Is there enough time to answer the question? Are people coming up with wide spectrum of solutions, or do you keep seeing the same response over an over? Are there parts of the problem that people find unclear?

Companies simply cannot give a reason for rejection. It is a "fake/legitimate" legal liability HR says exists opening the door to discrimination lawsuits.

My advice is never interview at a company at which you do not have some prior professional introduction (network, friend, foaf, etc). These people will be able to give you the real feedback on why you were or were not hired.

Some recruiters with longstanding relationships at the companies they are placing at will also be able to find out, but may or may not be honest with you.

You seem more than capable enough to get a good job but in my experience, interviewers are looking to see how you react to being stumped. If it's anger/frustration/clamming up then that's a turn off for a lot of employers. They're looking for more than the right answer.

I wish Sahat had reached out to more of his network before responding to random recruiters. Tech interviews as Sahat experienced them are broken, but tech hiring is slightly less broken especially when you leverage your network.

*note this is the same comment I made in the other thread. I stand by it. https://news.ycombinator.com/item?id=11579757

Read a single user's Tweets going back a month and even your best friend starts to look a little nuts. Do it with their git history and you'll sometimes get a very different impression of their work habits, too.

In my experience, these services tend to make people look worse, not better. But I can't always give the benefit of the doubt when I'm making a critical hiring decision.

The thing I learned about applying to jobs last time I went through this is that if your primary goal is obtaining a source of income, you need to send your resume to ~10 people a day, every day, and go on every possible interview, and do every possible thing people ask you to do.

You'll still lose a lot of jobs to these techniques, because they're effectively random, but since it's random, your odds of success increase with volume. Eventually you'll hit a position that you do just randomly happen to know the algorithm they're looking for, or they don't ask CS theory questions (I'm self taught, so theory is a weak point for me as well), and you can talk about/demonstrate your actual job qualifications, rather than some contrived talent that's entirely irrelevant to the position.

There are a few companies that make it a point to mention they avoid the kind of interviews you've been getting. Perhaps try to seek them out rather than rely on recruiters

https://gist.github.com/ericlw/16b55e038028e1e4768e

Because Hired.com prescreens companies and have a limited pool of both types of companies and types of candidates, it is easier to get a better sample size based on type of role.

I primarily talk about some of the arbitrary offers, instead of the interview process. But you might find it interesting too.

When I hired a programmer for our doomed to die VC life support funded fart of a project, we put her through numerous rounds of comp sci bingo and algorithm hell. Why? Not sure. Everyone else does. I mean, hiring in IT is shit, why should we break from the industry norm? Why should we want to care about the candidates? Right? I mean if Google can do it...

The ridiculously over-the-top interview process is one way to signal to hiring candidates that they will actually need some form of skill or experience to work at that company, and that it will therefore be an exciting, resume-building place to be for the next two years. Unfortunately, since the boring, stodgy companies slavishly copy cargo-cult practices of the young, hip, trendy, and popular companies, that signal was already being swamped by the noise by 2004.

But still, if the other 10% of the time is designing the system, it can wreck the project if you do a bad job at it. And no amount of futzing with NPM is going to save you, no matter how good you are at it.

It also depends on if you want the guy to be more than a front-end bug-fixing guy in the long run.

I see you have never worked in the defense industry before.

Shifting to CS, how do you even know a specific algorithm/data structure might help with your problem if you don't have a rough idea of its specifics?

It's easy to dismiss an example case as solving a maze, because that's been done to infinity. But real-world problems are rarely so cleanly defined.

It sucks that we have to do it under the pressure of a 45min-1hour conversation, and I totally get that the stakes are high and so nerves are a problem. In general I think the best way to handle this stuff is to give candidates multiple paths to succeed.

I think the nerves problem is slightly overstated though, because I do think many companies do give candidates multiple paths to succeed. For instance, if you have trouble performing well in an interview setting it's pretty crucial that you have a wide array of work on github proving you can code and that will give you an opportunity to have some complicated but familiar code that you can talk about in the interview. If someone comes in with this but is shy or gets frustrated or something, as an interviewer I'm really going to try and pull the magic I see in their github out of them in that interview. Keep in mind that people hiring engineers really want the candidate to succeed in most cases. It's so difficult to find good talent that while I'm never going to lower my standards to hurt the company, I'm definitely on the candidate's team in an interview, trying to get them to shine as best I can.

Author spends their time building software; Hired Google employee spent their time studying to win the interview game.

So let me rephrase this. Isn't it possible that a developer knows about computer performance but at the same time does not know <insert your favourite algorithm here> by heart?

Do you really think that "knowing BFS by heart" equals "knowing everything there is to know about computer performance"?

In your scenario, a developer might just google BFS if that is really needed (when a custom component is needed). Is this so important that he/she has to know BFS by heart beforehand during the interview?

So many factors go into hiring someone. Often it comes down to little things that have nothing to do with someones ability to do the job. Maybe a particular member of the team really didint like you or the manager and you went to the same high school and you have a connection.

It's crazy how often I will have a developer flat out rejected after a technical screening from one company only to go to another company who loves them and everything they do.

I believe the biggest misconception is that just because someone COULD do the job means that they will or should get the job. A lot of intangibles affect the final decision.

Your frustration is understandable. But you also have to ask and understand how our industry has come to this point. There are concrete reasons for it, and despite this process not being the best, it's the least evil when hiring is done at scale.

The process is here to stay. If you want to work at some of those companies, don't overthink it. Just prepare for interviews. It'll also give you a refreshing perspective to software development.

PS: The startup's not American, American startups have an inflated ego.

  def findSum(array1, array2, sum)
    complements = array1.map{|x| sum - x}.reverse

    i = complements.count - 1
    j = array2.count - 1

    while i >= 0 && j >= 0
      return true if complements[i] == array2[j]

      if complements[i] > array2[j]
        i -= 1
      else
        j -= 1
      end
    end

    false
  end

Hiring is Broken: Yes it is,but not the process,but the people. When you interview in a big company(especially a profitable one) you need to realize they are not looking for a typical skillset. Big (for profit) companies tend to keep their softwares behind closed doors. Hadoop was open sourced by google atleast a year after internal usage ,the same goes for Bazel(Blaze internally) .These were open sourced because they had much better versions of the same software that were consumed internally.When you reach such levels,performance factors are as important as

- ability to ship fast - writing clean/testable code - and all the other things that we programmers/coders are good at.

I am not saying that we aren't good at optimizing. But they are not really looking for the horde. This could also explain poaching college professors/PhD candidates for jobs.They need to people to push boundaries,not implement/build things from existing technologies.There is only so long that you can spend in a domain without having the need to extend that domain which you have been working in the past 20 years for.

Regular start-ups and other companies need a product.They need to make a mark in a field by pleasing the customer who would be using their products/technologies and who are looking for a service alternative mostly.

That is my justification for such interviews.This changed the way how I even handled interviews.

If I am asked these algorithmic questions,I generally smile and ask them if they want a Computer[1] or someone who can use a computer.I Immediately steer the conversation to what do they expect from me and explain to them what I can do.Often this clears the air and helps me(stress on the me) decide if I would like to join them. What you need to realize is that its you who is joining them.The impact that the organization will have on you is normally a much larger of magnitude in comparison to what you will have on the organization. The environment you end up working in will mould you in ways that you cannot anticipate.

PS: There are a couple of people who do the job hunting for the massive salary hikes and those sort of factors.I guess none of my arguments apply for them .

[2]:https://en.wikipedia.org/wiki/Human_computer

Corporate feedback is mostly BS. And the rare line from bozo recruiters offer little of substantive value. It's safer for him to say nothing at all.

However, I was taken aback by the author's refusal to try to solve BFS. To me, it feels like someone should be able to reinvent it relatively easy - that it's akin to a linked-list, palindrome or FizzBuzz question.

The typical answer is that they don't :)

The risk of choosing the wrong person is so great, that it's often better to not choose anyone. If there is any doubt what-so-ever, it's better to not make a a hire, it can be too damaging to a team, manager, company.

I've tried so many different "coding interview" scenarios. But I found the best one was a real task that a real staff member would be expected to do, extract it out into its own example, and before I talk to someone, they present their solution to the task, and the only thing we talk about, is their solution. If they can dissect and discuss their solution eloquently, and reason about trade-offs, short-cuts, talk about what they may have done better....

Of course, it can also be a simple case of, "is this person an asshole? are they going to rub my team up the wrong way? yes? fuck them."

While I don't interview for engineering jobs, we do bid on municipal contracts which are dominated by this concept (cover your ass, hire the big guy). A different animal indeed, but in a employment hierarchy where employees are held accountable for performance of new hires, it seems similar incentive would exist.

https://careers.stackoverflow.com/

[0]: http://jsfiddle.net/5g7se8qL/7/

[1]: http://stackoverflow.com/questions/16173259/javascript-maze-...

If you are looking for a computer scientist, ask for one in the job req. No shame in that, it would save everyone time.

The skills required to build a product or service people will pay you a livable wage for are not the same as those needed to write an open-source library. I've seen people with terrible coding skills make successful products with a "Rails for Dummies" book on their lap as they go (they hired pros later to clean up the mess), and I've seen excellent coders flounder with terrible ideas and business execution.

Personally I'd love to jump off the hiring hamster wheel, but realistically - outside of consulting (which has its own share of nightmares) - I don't see that happening even if I do come up with the perfect idea in the shower tomorrow.

I expect they can all do BFS, because your interview process apparently requires that.

Yes, if you need such a thing and it's not immediately obvious how to do it, off to StackOverflow you go to find some example code, but these are basic "do you understand fundamental data structure / control flow" type questions. It's not like they're asking you to implement a theorem prover or something.

Oh, you think you're a front-end dev and will never need to do anything else? What happened to striving for growth (personal and professional)? Why not learn how to write a BFS instead of writing a rant about your pride in not knowing it? Are you really just proud of doing your one thing, doing it well, and have no interest in ever branching out? If so, it is not surprise nobody will hire you (who needs a single-use tool?). If not, then also no surprise as you've shown a complete lack of desire to learn (who needs an inflexible employee?).

I am further sorry to tell you that your github history is irrelevant. I've seen _my_ code on github under 10 names. None of them mine. I'd never trust anyone's github profile - no reason to believe they wrote the code, they did it themselves, and how many attemtps of guess-and-check they needed (or not). You know what I do trust? Your ability to prove your "skills", in person, under realistic pressure, on demand, and on a schedule. You know, by solving a problem perhaps a bit out of your comfort zone. Maybe a simple maze?

Which is absolutely OK. If that's what you're going to do - regardless whether it's sensible or not - then potential candidates can either ignore your ad, and save everyone's time, or apply to you knowing what to expect. If a large enough number of desirable companies do this a candidate might decide to brush up on CS 101 and interview practice.

That's honest and courteous, instead of ambushing candidates in the interview stage - when they've taken a precious vacation day and taken the time flying out to see you. And it saves you time - any candidate you get should know what to expect.

I as a developer can't understand why anyone skilled wants to be employed.

I was employed for about 7 years and now I'm a freelancer. I don't have to discuss with my customers that I want to work from home, I just do it. I get more money than before, I spend less for health insurance and taxes, I start working when I want and not when some manager wants me in the office. And job security seems a bit odd considering that everyone is searching for devs and the demand seems to increase every year.

And the best thing is, I don't need to do dumb interviews anymore. When I freelance people just ask me for solutions and give me money for them. When I look for employment for doing exact the same stuff I do as a freelancer, suddenly they want to know the weirdest stuff and ask me to do dumb tests.

Not being able to do write a basic BFS algorithm suggests a) you didn't do any interview prep and b) whatever you've been working on hasn't involved any non-trivial algorithms.

It doesn't mean you're a bad programmer but if you can't answer a basic BFS algorithms question I wouldn't trust you to touch code with any non-trivial algorithms in it.

If you ask and your interviewer gets glassy-eyed or gives you the laughably generic "it shows how well you think algorithmically" you know that you are being interviewed by someone who has little clue what they are doing. It is a great way, from your side of the table, to understand if your time is being wasted right out of the gate.

1: http://blog.benroux.me/4-steps-to-making-your-interview-suck...

I have actually noticed that most tech companies(at least they ones I've had to deal with, namely Facebook, Google, Amazon, and Microsoft) are doing all they can to take the guess work out of interviews with training sessions, resources, etc...

All the OP needs is to change his attitude from cynical to optimistic and I promise, things will change for him.

Also, BFS (and DFS) are as basic as you can get with algorithms. Either of them is not longer than 10 lines of codes; just remember that BFS uses a Queue and DFS a Stack...

"You are in front of PC/Mac/Mobile screen, type www.cnn.com into browser, and press enter. A fraction of a second images show up on the screen... How? What happened? Tell me all you can from key press interrupts to underwater fiber cables".

This question never failed me. It always shows how deep does one go in their computer science adventures.

Many companies require this as a first step, before even talking to the candidate.

Apart from the problems being totally unlike what your future work will be like, the time constraint proves .. what ? That a candidate can "think fast" ?

What about code quality, architecture, design patterns, build systems, concurrency, etc ?

Here's what I've decided to do when they reply with a coding interview task:

I charge my clients 50 EUR an hour. If you want me to spend 3 hours on a coding interview as proof that I can code, then I'll expect you to pay me 150 EUR as proof that you can pay.

I think this is fair. Otherwise, I'm going to knock on someone else's door, were I can talk programming with an actual person, share "war stories" and get excited about building something cool together.

Instead of standing there with nothing its better to be straight up and just say "No idea mate" and then name reasons why that is but how you'd solve it in a normal situation. It is a lot about human psychology, showing them that they want/need you, not vice versa.

Sometimes all it takes is balls and a good amount of "I don't give a fuck" attitude.

I wouldn't let anyone treat me like Sahat got treated.

God, happened to me this year, highlights:

    - "Do you like to wear a tie to work?"  
      (perhaps because I'm 40-ish)
    - "Tell us about your worst boss."  
      (from three guys with frowns and folded arms)
    - "Do/talk through this sorting problem on the whiteboard/webpage..." 
      (With people watching, clock ticking over $100k in suitcase, gun to head)

This is an absolutely awful way to interview. However, the author should learn some patience & attack the problem. You deal with the cards you're given - it took me 2 1/2 years of applying to jobs before I lucked into get a job in the tech industry after grad school, and lots of wtfs in many interviews after I entered tech. Learning how to take it on the chin and keep going is an important skill for success - he could learn something from sales in that respect.

My one piece of advice: read Nick Corcodilos's Reinventing the Interview:

http://www.amazon.com/Ask-Headhunter-Reinventing-Interview-W...

The basic idea is demonstrate you can provide value to the company, and you have the skills to do the job. If you're stuck with a disinterested interviewer asking irrelevant questions, make it about the job you'll do and your ability to succeed in the job. He has concrete suggestions. I say, if they're not open to that and it is clearly not working, tell them you it is not going to work out and stop the interview rather than enduring another miserable experience.

I almost want to joke that it's Sahat should have done a bootcamp, since that seems to have been Haseeb's advantage; he learned everything about CS very recently and freshly, in an environment where he would be absorbing material that's tech interview fodder. Coupled with Haseeb's intelligence and quickness in absorbing said material, he must have impressed his interviewers. Whereas, an experienced developer like Sahat is worse off- ironically, by not being new to the field, he lacked the advantage of seeing like a fast learner. It's almost like ageism but specific to how long one has been programming.

And on the subject of hacker bootcamps- I've heard a lot of them not only teach programming, but how to optimize one's interviewing skills. If bootcamp graduates are doing well because of that, does that mean there should be bootcamps for experienced devs who want to switch jobs, just so they can ace interview questions? And is that really what this industry has come to? Memorizing algorithms and strategies for passing data structure logic puzzles in cram schools just to get a job?

Sometimes the questions aren't even related to data structures or algorithms. I'm OK with those because at least you can somewhat prepare for them. I've once had an interviewer ask me obscure questions about Netscape 6 (this was 2016 btw).

> I much prefer “homework” projects, even if they involve me working “for free”, because I feel like they ask for actual programming skills rather than the “guess the algorithm” lottery of phone screens and whiteboard coding.

Me too but when you're interviewing with 3+ companies at the same time while working at your current job, it gets difficult. There was one time where I had spend my Saturday afternoon maybe 6-8 hours completing their "homework" project. I got a call back from them a few days later for a follow up interview and they flat out didn't even bother to ask about the project I had completed for them. What was the point?

Tech interviews suck.

Vimeo, Facebook, Google, ... they hire elitists and those design the interviews. And honestly I doubt their work is at the end of the day more efficient then that of most other "regular" companies.

Well, OK, throw in a sociability / not-a-psycho score using LinkedIn or twitter or whatever.

I'd outsource this to gild.com who seem to know what they're doing.

Methinks management will be surprised at how well these 10% do despite not passing the usual "What happens when I flip all the color bits in a red-black tree" or whatever shibboleth is being used these days. Admit it : most work, even at Google, doesn't involve knowing how self-balancing trees work. On the other hand, getting things done matters everywhere.

Everybody can't work for Google, and there may be some that could work for Google if they were better at interviewing the way Google does (and these other companies do).

The author harbors some hostility towards the recruiters that have landed him these interviews. I'm a recruiter, and I too harbor some hostility towards recruiters when they behave badly.

The recruiters in all of these situations seem to have done the author a service, and there are no explanations of the recruiters behaving badly (other than the going silent/no feedback scenario).

Telling recruiters to "F* OFF" is just blaming the messenger. They didn't design the interviews, they didn't conduct the technical interviews being complained about, and they didn't make the decision not to hire. They simply facilitated the process and relayed the message.

Blame recruiters when they behave badly. Lying about salary ranges, 'bait and switch' jobs, etc. Don't blame them when they do their jobs, just because you didn't like the outcome.

I guess I'll go back to building my own projects, because none of this sounds enjoyable.

It is definitely a broken process in many companies.

My recommendation is to apply to smaller, lesser known companies. Much much less bullshit and time wasting. There are enough jobs out there that you don't have to deal with this bullshit.

Time spent on learning extraneous knowledge solely for the purpose of passing interviews for jobs that don't actually utilize such knowledge is a massive waste of society's resources.

There is a school of thought, baffling to me, that suggests that knowledge is mere rote memorization of facts, so the best way to test people in anything is to check their memorization of the relevant material. This interviewing style derives from that school of thought.

This is, of course, utter bullshit, especially given that the details of the topics chosen are almost entirely irrelevant to the actual job of a software engineer. A working programmer who re-implements a red-black tree from scratch is almost always doing it wrong. Someone has already built that and debugged it and optimized it, and you should be using that implementation, not redoing it from scratch yourself. The "programming trivia" interview style is like interviewing an architect by handing them some iron ore and asking them to smelt high grade steel out of it. That's not what architects do. They buy premade steel smelted by experts, then use it to build other things.

The solution? Real-world programming as an interview. Either give them a toy problem, or pay them to do some minor bit of actual work on your system for a day or two, if that is feasible. Then get out of their way. Give them a laptop and the Internet, leave them alone for a few hours, and see what they can do.

Afterwards, do a code review. Then discuss their programming and engineering philosophy.

Why don't people do this? It takes a lot longer, and requires the interviewer to think more. It's much less cognitive load for the interviewer to memorize some obscure data structures and ask candidates to recite their construction.

OTOH, I totally agree with the conclusion of the article: long interviews of technically complicated stuff is just BS. The last time I had to do this, I started refusing to answer questions after about two hours.

it's hard to unlearn habits, and what's good to us might not be good to google.

EDIT: someone is sour, did I say something that didn't add to the conversation?

The follow up phone interviews are what really matters (before the onsite of course) with actual engineers and go more in-depth with coding questions (among other things) at least.

I remember my recruiter was a really knowledgeable guy and he knew his stuff even though he wasn't an engineer. We had a nice chat and he was able to keep up with my (basic, obviously) responses of how TCP works, how to implement inode-based filesystems or whatever information you can read out of a stat call... Nothing too fancy but still it didn't sound like rehearsed script to me.

At the end of the day, it is not about what the company can do for you, it is about what you can do for the company.

It may minimize "humanity" for potential interviewees, but it optimizes for lack of heart ache on their end.

Is my guess.

If you have to stop and reason your way back through DFS, I'd say there's no way you'll get this done in 45 minutes. You need to know this stuff cold.

Rote memorization is useless, of course, because you won't be able to adapt or modify these algorithms. But there's a kind of memorization in the level of sharpness and mental prep you need to have when you walk into those interviews.

But we know that most of the time this isn't true. <1% of software developers write sorting algorithms on the job, and even fewer of those actually need to know which one is Bubble and which Quick and which Heap without reference.

If I'm a multinational company, I want my accountant to know what transfer pricing is. If I'm a self employed joiner, I don't.

Problem solving tests are good. Memorization tests are terrible. We have search engines for that.

I have experienced (on both sides of the table) situations in which it just hasn't happened. 'Can you do X?' 'What is X?' 'Never mind, let's move on'.

The article might go over the top a bit with self-pity, but personally I just see it as suboptimal behaviour.

http://danluu.com/programmer-moneyball/ - Dan Luu explains better than I can.

I think fundamentally the idea of paying developer X 40K and developer Y 80K (because developer Y has been twice as effective in the past) is broken, because it negates the impact of environment.

If you pay someone 150K GBP in London they can live next door to the office, have TaskRabbit like services perform all household tasks for them, and spend their time exercising and reading 24/7. They will kill it.

Pay them 30K, and regardless of pedigree, they're going to struggle.

Somewhere in there is a balance and I argue it's far less to do with certification and more the circumstances of life which as an employer you have huge discretion to influence.

Basically, it's about steelmanning. Why is someone bad? Is it that they're inherently genetically dysfunctional? Or is it that they haven't been coached well or have a difficult environment?

Given good faith, most of the developers I know have the ability to be amazing. I include myself in that (am I that good? dunno, impostor syndrome innit). But they are stifled by needless nonsense. Management, open office, low pay, commute, stress, basically. Kill the stress and you get your '10x engineer'. Keep the stress and your '10x engineer' turns into a chocolate mousse.

Actually, they are more than just words. Try not to conflate the abstract data structure itself with the language-specific implementations which can vary quite significantly. Also your flippant, dismissive attitude on quite important CS concepts wouldn't take you far. It's better to frame your argument like this ... "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for" which is quite reasonable as most devs CS-minted or otherwise will agree with you. & also while it might not be useful to rote memorize every single CS concept, it's sensible to at least have a passing familiarity. Why? Well, not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.

Hey, whoa, stop right here. std::map and std::unordered_map are not at all the same thing, and if you're going to be using them in a manner beyond "trivial" it's important to know the difference between them.

There's a big difference between the words "just hire them" and what you meant by those words.

First of all, the point of the interview isn't to determine whether somebody is bad, or improperly couched. Surely interviewers would love being able to do that, but it's not possible to do it in a couple of hours.

During the interview all you get to do is to apply a noise filter to get rid of the incredibly bad ones. Because without that filter you can get people that are a very bad fit and that can cost you the project and the morale of your existing employees. It's incredibly taxing to fire somebody. Every time it happened to see a colleague being fired, internal discussions, personal attacks and bad feelings happened internally, every single time and not just at one company. And then in big corporations, because of the risks involved in firing people, you get an even worse effect - you see them "promoted".

And with a noise filter you can naturally have many, many false negatives, as in people that are in fact good, but won't pass the test and interviewers are willing to have that risk, instead of risking false positives.

Of course, from what you're saying, I think you believe everybody can be great. Well, yeah, I think everybody can be great at something useful, but not everybody can be great at something specific. We software developers are too idealistic at times. I don't see surgeons going around telling other people that everybody can be a surgeon. That would be a preposterous thing to say.

On the other hand I do think that if companies want good people, they should invest in education.

> The whole principle here is that there exists a growing portion of developers who can't be bothered with interview ping pong.

I can agree with that. I'm not into interviewing myself. I'm not into switching jobs that often either. I can't be bothered with that because I've got satisfying things to work on already. Capitalism and the free market cuts both ways, right?

I think really what we're arguing about now is the distinction between hiring for a Google position (pushing the absolute state of the art) and hiring for a position creating accounting software or something.

I don't think that it's reasonable to expect to be hired into a top tier position as a kernel hacker at RedHat or a database expert at Google with an English degree and a few weeks of github commits.

I think that most software development jobs don't need the level of technical chops that are being asked for - and that many of the developers that actually have this level of ability just don't need the company (this post might be an example of that).

Some of the job requirements I've seen make me think along the lines of - 'hell, if I can do all of that, why would I work for you for peanuts?'.

It greatly surprises me that anyone enough in touch with tech to even be reading Hacker News in the first place would choose to read my comment that way.

I'm not saying you're wrong or trying to defend my writing. I'm just saying there's no way in a million lifetimes that I would have anticipated even the most remote possibility of someone taking it that way, and even after reading that you saw it that way, my prior is still so heavily weighted towards the obviousness from context that I still wouldn't ever expect this and doubt that if I make similar comments in the future, they will adequately account for someone reading it in the manner in which you did. It's just too unlikely of a perspective.

A similar question could be "Can you print in order all the elements of a given tree/graph?", would you find that more fair compared to straight out using the word "BFS/Breadth First Search"?

What's this?

I do think it's important to have a fit on teams, and I have hired people with awesome skills that were terrible cultural fits more than once.

But I'm not going to fill out personality quizzes unless I am desperate. And I work really hard to try to make sure I'm never desperate. :)

I later discovered his resume was an identical copy of his coworker's resume (both were submitted several months apart for the same job).

An average software developer earns about $85,000 in Sydney, so you're right, they're priced out of the central city's market. Senior software engineers make $100-150k, so even they make only up to 15% of a median downtown home.

I lived in Macquarie Park, a suburb of Sydney (which is ~20 minutes by public transit from the center of the city). The median price for a house there is $619k. That's well within reach for a senior engineer, although admittedly more of a stretch for an average developer.

Software engineer salaries in Seattle average $111k. As you've said, the median home price there is about $500k, which is very much attainable for someone earning six figures. The average income in Seattle is $37k, showing that (just like in Charlotte) software developers make about 3x as much as the average resident, and are in fact one of the few groups not yet priced out of central housing.

https://www.glassdoor.com/Salaries/sydney-software-engineer-...

https://www.glassdoor.com/Salaries/sydney-senior-software-en...

https://www.investsmart.com.au/property/nsw/2113/macquarie-p...

http://www.indeed.com/salary?q1=software+engineer&l1=seattle...

http://www.deptofnumbers.com/income/washington/seattle/

What? Obviously this isn't a great interview question, but this seems massively pointless. I don't think there is an obvious way of doing this that doesn't just turn the call stack into an explicit stack (which, again, is pointless). And the recursive code is the only code that could possibly be understood by someone whose whole world isn't dominated by understanding those ~12 lines.

EDIT: also, ya know. Who cares. I have not even heard of a software engineering legend where solving anything remotely similar to towers of hanoi was necessary.

Tbh, that could be a negative, there were a lot of lousy programmers at Yahoo. Doug Crockford worked there, so there were a lot of really good programmers too, but you can't know just based on working at Yahoo.

Sorry, I forgot that I was talking to oompaloompas

You are my hero. If you ever end up having an HR department you can put in mediocre software developers to do the menial tasks. Most mediocre software developers will out do your average HR drone. For hiring and interviewing use the very best people that you have.

Otherwise, a reference will only add to the burden you have to overcome with the interviewers - they will consider not only your qualities, but the referrer's qualities as well. "Richard vouched for Jane? But Richard is writing testing software, and we're hiring for backend. We don't need a SDET or we would have hired Richard."

If you have the "mental dexterity" to coming up with your own solution which is identical to Dijkstra's pathfinding algorithms in terms of complexity within an hour interview, you are a god among mortals.

And that's what they expect - a solution to a problem that is equal to the best minds of our field. I say this from experience: I was expected to do exactly that, and criticized when I came up with a O(n^3) instead of O(n^2).

I thought that was a great question. It got me talking about something I cared about, knew very well, and showed my normal thought process and development process outside of an interview. It also gave the interviewer plenty of things to ask about, to "quiz" me on if they wanted, or to just make sure I could actually code.

If I'm ever in a position to interview someone one-on-one, that's most likely going to be my main question.

I went on a lot of interviews (maybe close to 100) before starting my own business, and I'd say at least 9/10 of them were very positive.

By positive: I felt we both left the interview a bit happier than we went in. We both had a legitimate good time, and enjoyed it. It wasn't a grind, both people got to know each other.

I'd say I had a 10% offer rate. The most common "why didn't you select me?" follow up answer I got was "we need someone who is an expert in XYZ language." Sometimes it was even that they need someone who is an expert in ABC library (when I was already pretty-much an expert in the language.)

The ones that did lead to job offers I didn't want after the interview.

The other 1/10 was because they had me take an IQ test, or do some really super long project, or meet with literally all 20 people in the company, or they made me sit in the lobby for 2 hours past the meeting time.

Such trivia is the opposite of useful hard work; preparation for it truly wastes time that could be better spent on other things; a can-do attitude would imply rejecting or ignoring requests to do such things.

As a result, the people who actually do take the time to complete it will not be completing it because of a good attitude or work ethic, yet you will mistakenly believe they are.

Yes, I do. I don't act genuine because when I'm my genuine self, I glare at everyone in the room with the rage of a thousand suns.

I don't know if people can tell that I'm hiding it or not, but when I try to hide and act enthusiastic, I get the job, when I don't, I don't.

Companies that have the kind of engineering culture required to produce safety-critical products already treat software engineers like any other engineering discipline and expect them to act with the same rigor has other engineers. That's actually why I cringe every time I hear about a Valley software company wanting to pivot or branch into products like that.

"This person didn't study for the interview, so what did they expect to happen?" Oh, I don't know, maybe to be asked questions directly related to the position, amongst other things.

So please, take your time, skim their resumes and maybe do a bit of github code reviews before inviting someone to sit down. Hell, do it while you're taking a shit in the office if you, as an employer, are overworked. There's a pun in there.

I have no problem with thinking engineers should be able to understand and implement algorithms. I have a real problem with thinking they need to know them off the top of their head.

Wouldn't a more reasonable approach be to give an algorithm and ask the person to implement it? If that's what they're actually going to do (since most of us aren't PhDs) day-to-day, and they may more likely find an appropriate algorithm on Wikipedia and implement it, isn't that more relevant?

What algorithms have you seen in practice in web frontends? I have seen nothing even minor, not even binary search or bublle sort.

It's kind of like that date that you both absolutely loved over a long weekend, but the other person refuses to respond to. You can't really be mad, except think bitterly, "...really?"

If you're ever in Chicago, hit me up and we can grab some drinks.

Source? or just trying to justify your own shortcomings?

Job hunting is a big deal. It's real work, and literally everyone who's doing an interview has been interviewed, almost certainly in the same process. I studied up before my interviews, and I worked to manage my energy and capability when doing them. The article's premise that they should walk into an interview room and mystically get evaluated on traits that you can't directly measure, or compare objectively, is ridiculous. I read the article thinking this is the same type of guy that probably complains about having to see homeless people in SF. Completely entitled.

I take offense to the premise that I don't have empathy for the candidates - evaluating a person for a job is a deeply emotional affair. I have to walk a fine line between the needs of the candidate and employer. I can't hug you or take you out for drinks, as that could result in a lawsuit. The best I can do is find the interview question that lets you show off the best of your talents.

Asking for empathy without giving any in return isn't going to get you very far.

I've seen this directly happen - the interviewers were two Asian and one White male, who came to this job as their first outside college. Looking over the engineering department, I saw, with one exception in fourty, young White or Asian males. The one exception was a lone Asian female, who had a doctorate in CS.

Hiring "People Like Us" doesn't help a company.

You can find full exams with answers of CCNA and every Microsoft cert imaginable, I've worked for companies that incentivise certifications, and i watched coworkers use these 'tools' en masse to gain easy pay bumps and pad their resumes.

I've had two interviewers ever to ask me technical questions that actually tested my knowledge or capabilities. I look good enough on paper so usually interviews are with a couple managers and if there's a culture fit I'm in. Doesn't matter if i dont know a damn thing, if my resume says MCSE on it.

Microsoft and others further incentivise these certs by giving bonuses and breaks to companies employing certified individuals.

If you think people being hired because they passed a test they cheated on is 'more objective than other fields' then maybe i just have a warped view of how objective other fields are

That is the illusion many people have convinced themselves of but literally 0 of my coworkers could answer the questions I was asked simply because don't have similar responsibilities despite us applying for literally word-for-word identical job ads.

The reality is, unless you do X regularly, you simply aren't going to be able to impress people with your answer to X.

> Source? or just trying to justify your own shortcomings?

is clearly, unequivocally unprovoked and needlessly antagonistic (what do my shortcomings have to do with my point ... either you engage with the claim or not, but use ad hominem insults is not a valid discussion tactic. Yet you seem to assume no responsibility for your completely unprovoked hostility, and continue on with sarcasm, even sarcasm about your own ridiculousness.)

In terms of data, obviously no study is perfect and we should not simply base everything on a single study, but the 2012 PISA results offer at least some evidence < http://www.oecd.org/pisa/keyfindings/pisa-2012-results-volum... >.

The particular sections of the actual study that cover poor performance of those who focus on memorization is not available in the free sample (Chapter 2), but it was reported on, e.g. here: < http://hechingerreport.org/memorizers-are-the-lowest-achieve... >, including this:

> The U.S. has more memorizers than most other countries in the world. Perhaps not surprisingly as math teachers, driven by narrow state standards and tests, have valued those students over all others, communicating to many other students along the way – often girls – that they do not belong in math class.

> The fact that we have valued one type of learner and given others the idea they cannot do math is part of the reason for the widespread math failure and dislike in the U.S.

There is also the discussion from Google that test scores and brainteasers do not predict later-on job success < http://www.newyorker.com/tech/elements/why-brainteasers-dont... > (and many algorithm interviews are absolutely the same kind of brainteaser nonsense).

From the NY article:

> The major problem with most attempts to predict a specific outcome, such as interviews, is decontextualization: the attempt takes place in a generalized environment, as opposed to the context in which a behavior or trait naturally occurs. Google’s brainteasers measure how good people are at quickly coming up with a clever, plausible-seeming solution to an abstract problem under pressure. But employees don’t experience this particular type of pressure on the job. What the interviewee faces, instead, is the objective of a stressful, artificial interview setting: to make an impression that speaks to her qualifications in a limited time, within the narrow parameters set by the interviewer. What’s more, the candidate is asked to handle an abstracted “gotcha” situation, where thinking quickly is often more important than thinking well. Instead of determining how someone will perform on relevant tasks, the interviewer measures how the candidate will handle a brainteaser during an interview, and not much more.

The other thing we have to fight against is self-selection. It's not necessarily in everyone's interest to publicize that their riddles and algorithm hazing process isn't working. Especially not for start-ups which need investors to feel like they are crammed to the brim with stereotypical nerds or something. So if you go looking along the lines of "well, my company uses riddles and we have hired well" you're already done. You haven't hired well. Your company (if it's a startup) probably isn't even remotely proven yet, even if it's well-funded, and the verdict is out on whether the people you rejected really should have been.

Could I have dug up a library to do what I needed, sure I guess. Easier to take 20 minutes and just write the tool.

The article starts with:

>This is a story about my interview experience in the tech industry.

I also work in the tech industry, I was sharing my experience of interviewing in the tech industry.

More specifically i was responding to a comment that said:

> Hiring in CS / IT is massively more objective compared to most of other fields.

They are very keen on getting employees with existing certs or getting current employees to actively be getting more certs.

There are specific incentives from microsoft based on how many employees have certain levels of microsoft certification. it comes with discounts and marketing materials/privileges (Who doesnt want to say they are a Microsoft certified Gold support partner?)

As such, it is conveniently ignored that the guy with an MCSE isnt going to get fired because their gold level partnership lapses if they dont keep X number of MCSEs on staff

Your post was unwarrantingly personal similar and reeked of projection. Like I said - you're not relevant to my original argument if you're truly good at it and actually spend the time to care. Others don't. You're not who I'm talking about. Christ, you're taking this more personally than you should be....

Also, for what it's worth. Since you used your real name here, I looked you up on linkedin (sorry). The interview process there was the absolute worst and most impersonal series of interviews I've ever experienced in my life. I absolutely refuse to work for them after this: https://news.ycombinator.com/item?id=11451431

The interview scenario is just not similar to on-the-job coding. It has different social pressures, time pressures, access to help, access to privacy, etc. etc.

Plus, for someone like me (I studied machine learning and stats, and all data structure knowledge is self-taught post college, yet I have 6 years experience writing scientific code, performant database stuff, etc.) I am always hearing about data structures and algorithms that are supposedly "fundamental" but I never even heard of them before and have yet to need them in a job.

Basically, all of my experience, and all of the experience of hiring software developers in any of the companies I've been in just completely suggests what you're saying is actually not true. It's just a story we tell to allow us to keep our crab mentality hazing rituals.

I don't think it's controversial or insulting to say so in the least. It's a solved problem in every major language and most fringe languages. Spending time re-inventing it is just obviously wrong.

It's not insulting or judgmental to say that it's wrong. It's just a fact. I do not understand being offended or angry about my statement of that fact. If we're talking about what is effective engineering and what is not, writing your own argument parsing tool for actual business usage (as opposed to doing this as a pedagogical side project or something), without evidence of some exceptional corner case, is ineffective engineering. It's practically the definition of ineffective engineering.

It borders on category error to compare homebrewing argument parsing with an overreliance on microframeworks extending all the way down to leftpad. Argument parsing is almost always supported directly by the language implementers in a standard library. And even if it wasn't, it's such a critical task with huge overhead for handling corner cases, cross-platform details, etc., that the value of a central implementation is obvious. A left pad operation ought to be part of the standard language (which is actually what the leftpad debacle was about, Javascript's incredible failures as a language), but it's too trivial to compare it to something like argument parsing.

> The pseudo-code of BFS is all of 20 lines, ...

If it's only 20 lines, that's great because it means it was easy for the other 500 library writers to write it, write tests, and observe and fix issues over time. So, whew, that's 20 lines I totally shouldn't waste my time on, plus unit tests and routine maintenance I don't have to commit to.

And also, given the wide acknowledgement that a good programmer should be writing at most a few hundred lines of code per day (otherwise it's probably mostly junk), 20 lines of code is not trivial.

Probably most programmers write a whole lot more than that per day (especially if counting copy/pasted code), but this is in part a sign of a bad programmer, or perhaps more so a sign of the anti-quality constraints placed on them by most employers.

If your goal is to simply know how someone explores a problem, fine I guess. I don't agree with your approach but I can see your point. But if you expect a working implementation, that's unreasonable in my opinion and I believe you'll be rejecting many fine candidates using that method.

In this case, someone who didn't have the time to visualise exactly how the bfs is operating shouldn't be writing the algorithm. Pretending like you don't need to know the details of how it traverses the tree when you needed to choose the specific implementation for this algorithm to be performant is a lie. It's not like Guassian elimination, where the concept is far more abstract, this is a concrete idea of how you're moving through the graph and shouldn't be some black magic.

On top of this, who writes this code and doesn't test that it does what you expected it to do on sample data. If you bfs implementation was bust, then you'd miss nodes or revisit them, which becomes immediately apparent from testing the algorithm you're writing.

> It ought to require an exceptional circumstance to stoop to implementing it myself.

Maybe the problem here is that I see a bfs as a fundamentally simple algorithm. Saying writing it yourself must be an exceptional circumstance sounds about as crazy to me as saying no-one should ever use for loops, they expose you to making mistakes with an index you may forget is zero-based, please use anonymous iterators instead. When something takes 5m to write, is heavily tested by default (as it will be a feature under test anyway and possible flaws will be highly obvious) and is at the same level of abstraction as the code you'll be writing around it, then just write the damn thing.

EDIT - Try writing a BFS that operates on an acyclic graph that outputs the value of each node, that compiles and runs and prints at least two node values that has a bug. Try writing bugs into this, it's actually difficult to screw up.