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
Ta da!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?
It worked. He's working at a top company for several times his former salary, he had several competing offers with HUGE bonuses and equity offers.
However, I don't know if I have the commitment to do that, and I'm not sure if everyone SHOULD have to do that.
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 was rejected twice by a large company, which both had a much saner interview process (take-home excercises and much better in-person interviews), and I still think very highly of it (and I know the people that did get in and they were indeed very good).
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?
If you are a company and have to select between two front-end developers where one has a vast portfolio of production apps that you find impressive and the other knows BFS by heart (but has never shipped something to production), who would you choose?
If the developer doesn't understand performance (or at the very least, basic tree operations like searching/sorting/traversing), they're going to write some horrible code. Google and Bloomberg have their pick, they don't want a shitty developer.
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.
Gives you an intuition of the proper way to implement something before you know the big picture.
This isn't what interviews are testing: they are testing if you can implement the algo. That is rarely important.
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.
What discipline are you hiring, and what do you define as "familiar with"? If I am hiring an electrical engineer, I expect them all to know what Maxwell's equations are and what they represent. I would only expect an analog, mixed-signal, or power systems engineer to know how to apply them. Even then I would expect them to look up the equations.
Engineering has been standing on a foundation of reference books for as long as the discipline has existed. Engineers are expected to know what the principles are and how to apply them. They aren't expected to do all this from memory. The PE exam is a mostly open book test for that reason.
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.
The last 3-4 years have been at larger corporations. Major retailer and a division of SAP. Haven't always been at larger corps, but after doing the startup thing for a couple of years, the stability is relaxing.
I also had job offers from some companies that would be maybe "mature startups"? Not sure of a good term, but around 5-7 years old, profitable, ~50 employees, etc. One of them had zero programming exercises of any type. Just tech discussions. None had the questions discussed in this article.
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.
If you could go back in time to before they've ever seen it, well then yeah, I agree.
Point out that in a real life scenario you wouldn't do this because it is so more efficient to use the work of others, but then solve the problem so they can measure your problem solving skills.
A recursive implementation of depth-first search should only take ten minutes to write. OK, here, I'll do it without looking anything up. Start time 8:55pm.
#include <stdio.h>
#include <memory.h>
const int WIDTH = 32; // adjust to suit
const int HEIGHT = 32; // adjust to suit
const bool WALLS[WIDTH][HEIGHT] = {
// enter maze layout here, true = wall
// this isn't a test of file IO knowledge
// make sure the outer perimeter of the maze is
// fully closed with walls
};
const int START_X = 16; // adjust to suit
const int START_Y = 16; // adjust to suit
const int GOAL_X = 16; // adjust to suit
const int GOAL_Y = 16; // adjust to suit
bool search_maze(bool **searched, int cur_x, int cur_y,
int start_x, int start_y) {
const int DIRS = 4;
const int DIR_X = { -1, 0, 1, 0 };
const int DIR_Y = { 0, 1, 0, -1 };
searched[cur_x][cur_y] = true;
for (int i=0; i<DIRS; i++) {
int new_x = cur_x + DIR_X[i];
int new_y = cur_y + DIR_Y[i];
if (WALLS[new_x][new_y])
continue;
// if moving in this direction lands us on the start
// point, or searching starting here returns true,
// then we're done and our current pos is on the path
if ((new_x == start_x && new_y == start_y) ||
(!searched[new_x][new_y] && search_maze(
searched, new_x, new_y, start_x, start_y)) {
printf("Go to %d, %d\n", new_x, new_y);
return true;
}
}
return false;
}
int main(int argc, char **argv) {
bool searched[WIDTH][HEIGHT];
memset(searched, 0, sizeof(searched));
printf("Starting at %d, %d\n", START_X, START_Y);
search_maze(searched, GOAL_X, GOAL_Y, START_X, START_Y);
printf("Goal at %d, %d\n", GOAL_X, GOAL_Y);
return 0;
}
End time 9:12pm. So 17 minutes (what's that rule about estimating software dev time?), and I haven't run and tested it yet, but it should show what the interviewer wants.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
Unless someone in your network has enough political pull to ensure you get bypassed around that shit, then network-based interviews are absolutely no different than other kinds.
Only way to bypass that is to start your own company or know somebody in a powerful position.
My impression of what reaching out means today is a chat over coffee, lunch, or less preferably a phone call.
Contacts are also good at helping you find unposted jobs. You have to "Reach out" first.
Contacts can also recommend you to a hiring manager. The best hiring managers trust a reference based on a long working relationship over 30-45 minutes in an interview. But you have to "reach out" first.
And it doesn't need to be "best friend" level of personal connection, it's someone you often see at that AngularJS meetup or whatever- after three or four pleasant conversations you'd be surprised how invested they can be to hire you- especially because they already know what your skill set is and would only look at you if you fit the problem they're having.
This is the value proposition of going to Meetups, Conferences, Talks, etc. You start to see who the "regulars" are, and persons in a hiring position tend to bias very heavily to people they are already familiar with.
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.
they are entitled to interview in whatever way they choose, but you should recognize that it is a highly idiosyncratic process that has been widely criticized by many many many people.
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...
A better reply might simply have pointed out that there isn't enough information to draw such a conclusion.
We detached this subthread from https://news.ycombinator.com/item?id=11581129 and marked it off-topic.
I used to believe this myself, mostly because I didn't have a strong CS background and was still successful at carrying out software projects at a relatively high level.
The truth is, as I learned more CS I learned that these things are actually pretty crucial. Not necessarily for executing one single project, but for building a large system that scales reasonably? Absolutely. I spent years reinventing the wheel of basic data structures and algos simply because I did not know them or how to use them.
Bottom line: I would not want to work with the me of 5 years ago because I wrote shitty code while proudly proclaiming that CS was theoretical bullshit that didn't matter in web development, and I think many people who make these types of claims really just don't understand how applicable a good CS foundation is.
I'd agree that ideally you want some kind of work sample as well. Either an OS contribution, github or even small project written specifically for the interview. You can't ask someone to write enough code on an interview that you really see what happens when they have to structure a real project (ie: thousands of lines) or work within a real system (ie: millions of lines). This is where CS foundations in interviews have their relevancy.
Should a programmer you hire be able to reason about CS problems? Yes. Do they need to be able to write out the best possible solution to a problem on a whiteboard within 15 minutes? No.
The white-board sessions only really serve to intimidate people who aren't good public speakers, think better with some time and peace and quiet, or simply haven't bothered to memorize code they never have to write from scratch.
Legitimately bad candidates could just as efficiently be eliminated by having a casual discussion about a CS concept that relates to the job description.
The author of the article comes off as defensive and blame-shifting. I'm not surprised he didn't get hired. Since when is it ok to say "why?" when someone asked you to perform something in an interview? Do you really think the multi million dollar news agency will need you to program a maze at some point, so they're testing your ability to? Just how dumb do these engineers think recruiters are?
Steve Yegge thinks people disregarding CS questions in interviews is the Dunning-Kruger effect in action. I think he's right, but I have no way of knowing - due to Dunning-Kruger...
Some of it stems from something very wonderful about our profession - we are flexible about how people can acquire this background. In law, you must do a 3 year JD[1], and you must typically pay way over 100k for it. Alternate paths toward learning this material are pretty much illegal (as in, we'll put you in jail if you try to practice law if you haven't done the 3-year degree, regardless of your master of the material).
For instance, I was a math major, and I only took a bit of formal CS. However, when I did self-study to try to plug some of these gaps (partially for interviews, partially for my own education), I was surprised with how much I actually had covered from a different angle. Many of my math (and later, in grad school, Industrial Engineering) professors ran "labs", some for a bit of extra credit, others as an optional set of assignments. I took graph theory through a math department and stuck around in the lab and so forth to implement some of the algorithms, to learn about how some types of proofs actually contain an algorithm. BFS, DFS, minimum spanning set. That all involved building trees, lists, using pointers. In numerical analysis, I did a lot of matrix algebra manipulations. And so on. If CS were run like law, it would be illegal for someone like me to work as a programmer, because my degree isn't an ABET accredited CS degree.
The downside to all of this, though, is that there is no recognized credential. I don't object to being taken through my paces, I object to how random, capricious, and redundant the process has become. I read a blog article about a programmer who took the bar and studied for 100 hours and passed. Think on that for a second and compare it to the amount of time people spend preparing for and taking what are essentially white board exams in technical interviews. The bar, an exam that is considered one of the most brutal rites of passage for a learned profession? In some ways, we go through that every time we do a new round of interviews when we change jobs!
Actuaries have to show understanding of relatively advanced math, but senior actuaries don't (to my knowledge) get grilled on integration by parts or some specialized set of partial differential equations when they interview. Why? Because there is a proper exam for their field (and unlike law, actuaries are free to obtain this background through multiple educational paths, they often major in math, but hardly always).
Another problem is the capriciousness of the tech exam/interviews. I believe that a "bill of rights" so to speak slowly evolved between examinee and governing board over time in true professions. The nursing and medical boards, the actuarial exams, the bar - these fields have a tough exam (or series of exams), but they are consistent, there is a clear study path, there is a commitment to grade them fairly, there is a clear study path, if you fail, you get feedback or at least a score (the bar doesn't write you back and say they "decided not to pursue your candidacy further at this time"), there is often a second (or additional) change at the exam, and, most importantly, when you pass you get a lasting, public credential respected by your peers in the field.
People often describe these exams as the most brutal, anxiety ridden, stressful events of their professional lives. This is why, I believe, they slowly evolved that "bill or rights" that protects the examinee.
Unfortunately, in tech, I believe we experience these exams over and over, but without any of those benefits.
I am a-ok with requiring people to show competence, but the way we go about it is, I think, badly broken. I believe that this process accounts for a great deal of attrition in the field, as well as people deciding not to enter the field in the first place.
[1] yes, a bit of handwaving, it's not quite that simple in some states.
My point being, it depends on the role, and the expectations you have for the future of a candidate in your company. Are you hiring a guy to bugfix or implement a couple of features on your web app? Or a guy to design and implement from scratch a app that should have some hope of scaling in the future? Or a guy that can tackle a tricky performance problem you're having?
I'm not claiming the current status quo is alright, but hiring the right people is hard. Knowing CS basics and generalities of the field doesn't hurt either...
The fact is that most developers spend 90+% of their time futzing with NPM, dealing with Apple's review process, or renewing SSL certificates. Low-level algorithm work is something very few engineers need to know.
So if you want to hire a "guy" to "design your water heater", ask him about the water heater he designed in the previous company, or a water cooler he designed for the neighbor community...
Honestly, regularly referring to the reference material as you need it rather than trying to remember or derive every single pressure equation off the top of your head sounds like a good idea when designing a potentially explosive boiler.
So, to clarify, you're advocating that programmers be hired based on resume, references, and a conversation about prior projects? I'm not sure I agree with this. It seems you'd be selecting for ability to present yourself as a good programmer over actually being a good programmer.
What is your objection to attempting to verify someone's programming skill directly? It's certainly not an easy thing to do, but it doesn't seem apparent to me that it's impossible or not worthwhile.
If the standard "whiteboard algorithmic brainteaser" is not a high quality signal (which I'm not sure I grant, Google seems to think it is, and they claim to have the data to back it up, though they're probably much, much more false-negative tolerant than most), it seems like there's plenty of dials to twist to try and increase the signal-to-noise and cost/benefit.
a) Length of interview (one hour? full day? trial run of several weeks?)
b) Topic (algorithmic vs. brainteaser vs. some attempt to simulate the "real world" to some level of fidelity?)
c) Interface (Whiteboard vs. on computer vs. something else?)
(I'm being a little disingenuous with the whiteboard vs. computer thing. I don't get the value of writing on a whiteboard. I'm kinda hoping someone might be able to elucidate that.)
There's probably not a one-size-fits-all. Depends on your tolerance for risk, how senior you're trying to hire, how tight the job market is, etc. But I really would hesitate to work at a place that just took people's word on their programming ability.
This is how I've hired for every open position in my company. You'd be amazed how easy it is to weed people out based on a conversation. It's very rare that someone can talk the talk without actually knowing what they're doing. There are too many obscure concepts and it gets clear really quickly if someone is bullshitting or has no idea what they're talking about.
I think he is, considering this is the way every other engineering discipline does it. Please don;t fall back on the licensure issue, either. The vast majority of engineers in industry are not and do not need to be licensed. They still get interviewed this way.
When I hired a plumber, I hired someone that was insured, had multiple good reviews online, and was able to give good, descriptive, and in depth details of the job he was going to do. Generally, a programmer will not insure their work, and usually you aren't hiring for a single job that can be designed and discussed in detail up front.
Even so, some of the contractors were still pretty damn shoddy, and I've had to fix their work (or hire someone else to) in the past.
Part of the problem is that I don't know enough about construction codes and the reasoning behind them to ask, eg, what kind of slopes and diameters pipes need to effectively carry sewage, when it's appropriate to use one type over another, etc. If I could, I would.
Because being a programmer for years doesn't guarantee the person will have any skill. I met a programmer who had been working for 10 years, and couldn't write a program to swap two variables. I don't know why, but for some reason experience is not equal to skill in the programming industry.
In Portugal I was very amazed by the large amount of women driving buses, taxis and garbage trucks (for instance). Back in Brazil I must have seen at most five or six but in Portugal it is a very common sight.
Now for this kind of specialized trade jobs like plumbers, electricians and auto mechanics I personally never seen a woman doing it in both sides of the pond.
Instead this process is left to the individual corporations. So, you get mixed results in judging quality, because there is no standardization.
- Job boards: Mainly indeed.com, to be honest. Lot of recruiters on both, but they do a pretty good job of indexing real job posts as well. I think that's where I found my current position.
- Targeting specific companies. Got my previous job this way. If you're looking in and near Minneapolis itself, Best Buy, Target, US Bank, United Health, Ameriprise, etc are almost always hiring. So are Medtronic, 3M, Ecolab, etc, but they're not right in Minneapolis and depending on where you're at might be quite a drive. If you see a job listing by a recruiter and it mentions Richfield, MN it's almost certainly Best Buy (like this one - http://www.indeed.com/cmp/Palnar-Inc/jobs/Ui-Developer-c059f... ) or US Bank (which is actually using about 25% of Best Buy's HQ now). Best Buy hires a lot of their front end devs as contractors, so if that's what you're interested in, you probably won't find a listing on their own website. I was a Front End contractor there for 18 months. Not a bad place really, although the front end dev contractors are definitely 2nd class citizens. If you're looking for a job at Target, they host (almost) monthly meetups in their pretty cool Plaza Commons (across Nicollet Ave from their HQ). Free beer and food, some interesting talks, and there are Target recruiters there usually - http://www.meetup.com/Skyway-Software-Symposium/
- Recruiters. A lot of junk here, but there are actually some decent ones out there who aren't complete idiots. Turning the "Looking for a job" flag on in Linkedin was enough for me (just make sure you turn off notifications for your network).
Anyways, hopefully that's helpful (not sure if it will be). Unfortunately, I can't be more of a help directly as we're not hiring at my office currently (I think we just filled our latest openings).
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.
In general, these things are well implemented in either the base language or a library, and thus both easily searchable and well covered in practical examples. It's unusual for 9-to-5 non-R&D developers to be solving a problem which hasn't been solved before at the algorithm level, the job usually revolves around connecting pre-made components together and specializing them. As such, you really only need a loose knowledge of the fact that things like binary trees exist. Being able to hand-write one isn't useful and may be a liability depending on the temperament of the developer.
Your hand-rolled implementation is unlikely to perform better by any metric than the pre-made one, and it'll probably be less platform independent and more buggy simply because it's newer and looked at by fewer people.
In 95% of all software development today, rolling your own version of any off-the-shelf algorithm is a mugs game and actively bad practice because it places the foundations for technical debt. You really don't want to be hiring people who roll their own just because they can.
Now, if you're going to be working in the R&D or experimental areas of software development, kind of where the Oculus driver crew are at the moment (as an example), then sure, you definitely need to know the inner details of these things.
The problem is that we're interviewing everyone as if they're going to be writing high-performance drivers, when most of them are never going to work at that level and wouldn't want to.
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.
Edit: Ok, let me add some nuance here. I think we both probably agree that implementing a shortest path algo perfectly in an interview setting is beyond reasonable or useful. But I would expect an engineer to be able to have a discussion about it that shows me they understand the basic concepts and given google and a bit of time could relearn that. But without the complexity of shortest path I would not expect basic BFS to be outside of the scope of an interview. I guess that's just where I draw my lines.
Author spends their time building software; Hired Google employee spent their time studying to win the interview game.
So someone who wants to be hired has to spend a lot of time and effort learning stuff that are only marginally useful - knowledge isn't bad per se, but it might be a bad allocation of resources.
I'm not saying that it is so in Google's case, only that I've seen and participated in interviews where questions had no relevance to the job description.
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?
bool bfs(int x) {
q = new LinkedList<Node>;
q.push(root)
while (q.size != 0 && q.peak() != x);
return q.size ? true : false;
}Oh, well...
The person who has to try to understand what the hell is going on and how to add new features after the original developer has moved on to other things probably cares quite a lot. The difference between a good programmer and a mediocre programmer is not that one can solve the problem and the other can't, but that the good one can solve the problem in an easy to understand and easy to maintain way.
So 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.
I'm guessing 10%.
BFS and Dijkstra's aren't really the sort of thing you implement from memory, you figure it out fresh each time, unconsciously plagiarizing from your past experiences.
Also yes it's a basic graph algorithm everyone learns, but its inherently much more complicated than BFS which is a simple traversal. It's like bubble sort vs radix sort ... which makes this kind of a loaded question.
Unless, of course, you mean if all academic papers and material that describe BFS suddenly vanished and you had to come up with a solution yourself in 30 minutes with someone looking over your back. In that case, I agree, it's a red flag for whatever position you're interviewing for.
BFS is not much more than a loop, a queue and a set to keep track of state (which nodes to visit next and which nodes have been visited). I can't think of many algorithms simpler than that to ask outside of things like fizz-buzz.
If you are arguing for whether algorithms are an effective way to gauge a candidate's skill then you should state that.
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
endIt just means "hey, try out this guy" and they won't be throwing away your CV into the pile of hundreds of thousands of CVs they get every year. You still need to go through everything like everyone else.
Not all ventures require lots of savings. (Time? Definitely). It is conceivably possible to try and bootstrap something outside of working hours.
The original author was able to devote much time to GitHub projects, so it's not a stretch that the author might be able to bootstrap an idea.
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 .
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."
There's a cost (in terms of time & money) to onboarding someone, integrating them into the company and team, and getting them to be productive. That's a reasonable investment for a long term gain, but for a short probation, it rarely pays off for the organization. The churn itself just isn't worth it.
Moreover, it means the candidate is in an uncertain state. Should they keep interviewing if it doesn't work? Should they change their lives and relocate? Etc.
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.
Should all front-end developers be able to create a maze solving algorithm on the spot, during an interview, under time pressure?
[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.
That's bullshit. Sorry, but it is.
If it was such a big risk, companies would:
1) Do much better jobs at retaining employees (that are known to be good).
2) Be in a lot of trouble currently, because companies hire all the time and fire all the time.
If you're having this problem you seriously need to reevaluate what you consider damaging. Hiring someone your team thinks is an idiot is not damaging.
Making your current team go home and talk to their roommate/spouse/so each night about how "we really need to fucking hire someone, this is ridiculous" while making your devs set through interviews is damaging :)
This is a great way to hire "People Like You". Look around at your team. How much diversity is there in age, race, gender, hobbies, college education, or even favorite TV shows? How many would be willing to tell you that you're wrong, and stick to it in the face of a (to you) completely logical explanation of why you are right?
What you qualify as a wrong hire is not necessarily the wrong person to hire. If you're so afraid to hire the wrong person that you will never hire someone you don't instantly like, you and your company will suffer for the lack of different views.
Even that "asshole" can make you think about things in a different light.
So the fix is in and the bosses nephew is going to hired or your frat bro you watched south park episodes with. HR makes you interview multiple people to make it look fair. Obviously its going to be a hostile interview experience. Maybe if you're a clone of Knuth and totally wow the interviewer, the bosses nephew will get kicked to the curb, or if you're cooler than the interviewer's frat bro, well, thats a strong maybe. But basically if you walk into an interview and they ask you about algos that a dog whistle you're not getting hired. Either the fix is already in, or you're a minority, either way you're not getting hired once the questions about red-black trees get unleashed. The interview is already over at that point unless its a 1 in 1000 meteorite strike, it does happen, just almost never.
There are way too many skilled programmers for way too few positions or else the system would collapse if just one employer defected. That hasn't happened, therefore there are too many applicants for too few positions.
The reason you hear nonsense about "not enough skilled programmers" is because they didn't mention they have to be white or male or members of the interviewer's fraternity or fans of the same TV show. There's no shortage at all of excellent programmers who happen to be minorities or unrelated to members of management.
I assume you don't live in the US or if you do, please elaborate because in the US there are virtually no such risks with at-will employment. It's so incredibly easy to fire people in the US that such an idea is actually ridiculous, yet people keep bringing it up all the time as if it's real.
Plus, it's sociopathic: If someone has a job already, having them quit that job, start working for you, and then get fired and end up on the street because it didn't work out... man, that's a jerk move. The manager owes it to the new hire to be confident that they'll work out.
Worse, if you have someone who just doesn't play well with others, there are no grounds for dismissal. You end up having to cook up some sort of severance package for genuinely toxic staff, and hope they hate the environment as much as others hate them.
"Please take this package. In the long run it will be better for everyone" and hope they see the light and walk.
1 the people that interviewed / recruited that bad egg will be scorned as the people that brought that idiot in
2 often people think the bad one will get better so they invent a lot of time into making it work. Time that could be better spent elsewhere.
3 typically groups have a very limited headcount. So if you bring in a bad person you've used up that slot and won't have anything available for months (if ever)
4 have you ever worked with a negative person? It really zaps the energy out of going into work.
5 the damage that a bad hire can also be great on the code base, let alone morale. Some junk stays in the code for years
This risk can be great, but the team and company can be organized such that the risk is extremely reduced. A pairing schedule, for example, can be very effective.
1) This person is talking directly to clients day one, solo
2) Their code is pushed without review...
3) They are making high-level (C-level, maybe a bit lower) decisions for your business
Otherwise, yeah... a bad employee can do some harm. But, it's that employee's fault, and the other employees will realize this.
It is the business's fault if they go a year under-staffed because "they are afraid."
The second is MUCH more damaging: shows your leadership is not bold, they are misguided, and they don't know what to do to correct course if something goes unplanned (sub-performing employee).
(My apologies, to zappo2938, I didn't dive into your code, though I did skim it. I didn't want to create a new top-level comment about the maze problem.)
Or they could find some obscure (and unrelated to their product) algorithmic problem that's been solved before but isn't posted on StackOverflow, and you can complain about how it's just trivia and not a useful problem.
No matter what the question is, there will always be some reason that the job interview is a waste of your time and you could have spent your afternoon off curing cancer instead.
They want to know if you can solve problems. The maze is an (imperfect) test from which they hope to extrapolate whether you could solve future problems. The future problems will not all be written up word-for-word on a Q&A site.
There was nothing about being a new creative and novel solution. And in terms of time gained and effort expended, this "LMGTFY" technique is the best.
Again, I like working on things that aren't on StackExchange.
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.
The "Technical" part was just trivia. Never-mind that I was sat in front of a computer and could have googled everything asked, I chose not to do that.
So yes, I stumbled when asked "what does the using keyword do". I explained how it relates to IDisposable, disposeing the object at the end of the block scope and avoids needing try/finally blocks.
But clearly that wasn't the script, because they kept asking "Are you sure it doesn't do anything else? Are you sure isn't used anywhere else?".
Eventually I realised they were talking about "using System.Linq" etc, and all they wanted to hear was the word "namespaces".
Talk about interviewing by numbers, had I wanted to I could have googled every question and given them perfect descriptions.
What could they possibly have learned from that interaction? I learned I didn't want to work there, so it helped me I guess.
But I find implementation things more helpful (in person, not by phone!), because it's not about whipping out the right answer, it's about watching how the candidate thinks and approaches problems. It's about how they work not the end result.
I like the "write a function to multiply" because it can be extended to any level. If someone aces the positive numbers case you point out negative numbers, if they ace that you can talk about efficiency, or bounds checks, exception handling, efficiency or whatever else you think they'd like to talk about.
This type of recruiting seriously turns me off because you can tell they're hiring minimum wage call center workers to read a script and filter out the 9/10 candidates that can't answer a few administrivia questions. It makes me think of them more as an industrialized recruiting center than a company that actually cares about their workers, which is probably the wrong message to send to potential employees.
I just googled it. Oh, I know what it is now.
If you haven't been exposed to it, it's just jargon. That's the point. You are testing for jargon rather than ability.
It is the distinction between saying 'implement FizzBuzz' and going silent, and actually explaining what it is. As an interviewer it is easy to forget that whilst you may have asked a question 20 times, this may be the candidate's first encounter with your terminology.
Steelmanning as applied to interviews, basically.
In other words, it's OK if you don't have a formal education in computer science, but when you don't have it, you need to make up for it by learning on your own, because this is basic stuff that high-school kids are learning. And it's even worse when people do have that education on their resume and don't know BFS, because it means they cheated on those courses.
And what would you prefer for a hiring test? Straight IQ tests? A requirement for public, open-source contributions? Or are you speaking of querying databases and fading out divs? I think we can all agree that neither is entirely fair.
And keep in mind that for all the pain involved in the interview process, the only alternative is optimistic hiring for a test period, except that doesn't work because it causes distress to everybody involved if it doesn't work out. This is why many companies now prefer internships, because thus they are dealing with young people that don't have big expectations.
Depending on what their listed requirements were, I think it's reasonable to expect you to know standard terminology, though I wouldn't count it against you if you asked to be reminded of the details for one or two things.
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?
And if you're hiring a front-end pay him as such. If you want him to know more than front-end beforehand, pay him extra.
specialist = know one thing well, many things a little
only know one thing = useless one-time-use-tool whom i will contract for exactly my one-time-problem and then move on from
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.
After two years Amazon called be back for a second interview. I told them that I am not interested if they still have that kind of questions. They said they don't.
I flew to a different country for that second interview and guess what! They still asked those kind of questions.
Smaller companies could just email applicants their hiring process detailing what they expect at each stage. Tiny amount of work that will save a ton of lost time & hurt feelings.
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.
I'm mostly scared of the lack of a "guaranteed" salary. I'm a consultant for IBM Watson. My skills are in demand. I could probably go on my own for about $150 an hour; work less and make more. I'm afraid to take that leap though. I have a family I'm responsible for and live paycheck to paycheck now.
I also have similar experience in my job search but I attribute it mostly to me just being a failure at interviews.
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.
But luckily I'm usually in the hiring manager's chair these days and my interviews aren't easy but they're not a stupid game.
But as I said earlier its usually bad to stand in silence with no answer and let time run out. Better to admit whats going on and try to explain what the issue is.
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)
I gave up as well, am now writing a book on software, unsure it will sell.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.
this is patently false. There are very strict requirements for enlisting/being commissioned [0], including minimum and maximum age for new members, minimum aptitude tests, and either be a us citizen or a resident alien. Also many people are disqualified for having a criminal record.
> but the physical requirements and "culture fit" does a very good job of selecting for young males.
yes, this makes sense. "Culture fit" must be the reason that every single military in the history of the world from every culture ever has been heavily male dominated.
/s
[0] http://www.military.com/join-armed-forces/join-the-military-...
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.
It's worse when they give you an easy project that takes you ~30 hrs to complete, they state it "doesn't have to be finished," then disqualify you because "why didn't you use a graph database for this problem?"
Oh well. Same company was using Mongo+Node on a new startup from when they were still in year one. Wish them the best..
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.
Sure, BFS is 'easy' but it's not really something that stays fresh in your memory after years of not having to use it.
I completely agree with his point that it if you have to study for an interview, the process is broken.
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.
Dev jobs outside of that little bubble tend to have very different interview techniques.
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.
My immediate thought is that if I have to implement a breadth-first search from scratch it probably means that I or someone has made a terrible mistake someplace.
Also, I'd want more information. Am I just getting some values then doing some recursion? How large is the maze? The stack? Are these spherical frictionless chickens or do I need to worry about real-world constraints?
Or for someone else's mention of the Nth from last item in a linked list, my first questions would be "Do I know the length?", "Is this going to need to be repeated?" and possibly "Do I have enough RAM available to create a ring buffer of N addresses?"
I'd been writing lots of mathematically intensive code for building and solving large scale linear programs for about a year, and I interviewed at a job that was doing lots of math-ish business analysis. Code would certainly be written.
I was incredibly busy, and mainly spent my interview prep on math I thought would be relevant, though I really didn't adequately prep for the interview.
One of my interview questions involved some simple (really, I must be honest there, it was simple) recursive tree traversal. I blew it, and I'm pretty sure this is why they didn't hire me.
Six months later, I had to use quite a bit of tree traversal to model a series of conditions that had to occur in several possible patterns for a manufacturing system. Because there were various combinations of events that would "pass", I used trees to model the system, and I needed to recursively determine, in the event that the system didn't pass, what possible paths (including the least cost path) existed to bring the system into compliance.
I picked up my old reference books, reviewed for a couple days, and started writing code. As I did this, I started to feeling kind of embarrassed about the questions I had failed, since I was now reminded of how basic they actually were. I was chatting with a coworker about it and mentioned the interview, and told him that I could see why they didn't want to hire me.
He's my buddy, so he tends to say nice things, but he said (paraphrasing from memory): "but wait, doesn't that prove the opposite? The moment you needed to do tree traversal, you knew exactly where to go look. You know about these algorithms, you've done them and taken exams on them in the past, you just don't walk around ready to implement these algorithms on the spot."
So ok, BFS is so basic that I'll probably never forget how to to it again. But right now, this moment? I'd have to reason back through it. To get really sharp (especially since I won't know the questions in advance), yeah, I'd have to hit the books for a while.
Just how many times do I need to re-take my Data Structures and Algorithms midterm?
The only way to really see how someone thinks is to just hire them, work with them for a while, and fire them if they can't do the job. You can either pay the costs of hiring and firing (like on-boarding, benefits, administration, severance) and get useful signal about their performance, or you can spend the same money by throwing it away on useless shit like HackerRank-style trivia tests. Per applicant, the HackerRank thing seems cheaper, but you typically have to spam it across many more applicants, endure losses due to great candidates who won't agree to your bullshit hiring process, and still end up firing people sometimes when they pass the trivia but (surprise) it didn't mean they would be good at the job. So overall, it's just as expensive.
You spend the money either way, might as well get useful signal out of it.
That's the worst idea ever
The first thing that jumped out was that you are trying to fit programmers into a bell curve, when they're really distributed by the power law, see: http://blog.benroux.me/4-steps-to-making-your-interview-suck... That was kind of a side piece to your blog, though.
Secondly I wanted to give you some ideas I've had on a similar topic, just to throw them out there:
Apple has a three-step interview process that I found interesting. First they ask a question about a language (your choice in language) to see that you know at least one language well. Then they ask a question about an algorithm, then they ask a design question (how would you design a chess game? What classes would you use?)
Another thing I've found is that programming skill is the low bar. It's important, but what you really want in a candidate is someone who can self-manage, who knows how to get things done. Can I assign this person a task, and they will be able to finish it on time (or let me know as soon as they realize it will be late)?
So in an interview, I ask questions to figure out if the person can get the computer to do what he wants. Then I try to figure out if he's a good self-manager. Unfortunately I haven't figured out a way to determine that in an interview, but I'm still working on it :)
That seems like a pretty quick way to end an interview. Although if they are asking dumb questions, they probably won't be a huge loss.
I kind of get what you're saying but it could easily be construed as openly challenging the interviewer. And I'm sure some small set of interviewers could appreciate something like that. But I'm willing to bet most people would find that to be an uncomfortable position to be in.
Are you serious? This is your one interview question? Do you realize this is the kind of thing the Sahat was writing against?
Instead of actually asking them about their relevant skills, experience, and capability you think it's fit to judge a candidate on what amounts to curious information on how a computer works.
Is that what you're hiring for? Someone who's spent more time reading wikipedia articles than actually coding? We're in the business of creating things, not harvesting trivia.
Yes it doesn't matter if someone's written and maintained code, documentation, tests, and has collaborated with dozens of other individuals for a repository used by thousands. All you need is to do is ask him your pet trivia question.
It always shows how deep does one go in their computer science adventures.
Knowing about the adventure of one electric signal from keyboard to underwater fiber cable has nothing to do with computer science. By your own words, you're testing for the completely wrong thing.
I am a VP at a medium size company and I do plenty of interviews
Here's a secret then. The candidate, whoever he or she is, will always try to answer your question. In fact, they'll try to satisfy whatever problem you put them up to.
"What's your favorite method of tying shoelaces?"
"How many golf balls can you fit between the earth and the moon?"
"What do you do for fun?"
The candidate will take their time and rack their brains trying to provide an answer to please you.
Some will give a good answer and some will give a bad one, but that doesn't mean your interview question is a good one.
"Let's see, I guess the wifi radio is going to have to do an RSSI measurement..."
It actually gave me goosebumps when I realized that I was so caught up in it and how excited I was getting.
Yes?
The point of an CS education is just as much to study well known algorithms and re-apply them to new contexts as it is to invent new ones. In fact, for most professionals, I'd argue the weighting is well slanted towards reapplication.
Our dev team previously used FizzBuzz, and found that every applicant was passing it. So they wanted a new take home programming problem, and internally their most important criteria was 'demonstrates algorithmic thinking.' They mostly write and maintain simple Django webapps, so I thought this was a bit silly, and suggested if they wanted to measure that, give candidates a problem easily solvable with topological sort. Unfortunately they bit hard and only found out afterwards that pretty much no applicants solved the problem correctly. We still hired four people from that round. So in some sense, turnover within a year will mean that none of our dev team can pass their own interview.
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 don't consider asking a developer about basic data structures and their properties as terrible. This is foundational knowledge that is useful for nearly every programming job. Knowing about lists, hash tables, trees, etc and their operations or tradeoffs is extremely important.
Similarly, having a developer that can reason about the runtime and memory complexity of the code they write is important as well.
These are the "lingua franca" things that I was speaking about in my previous post. Even if particular developers think that the above things aren't useful to them, I would argue that they are probably wrong and just don't know how or why they are.
But before that, I'd used them for 10-15 years without knowing the name because it doesn't matter. Take a hash table. Python calls it a dict. C++ calls it an (unordered) map. Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing you want in a new language, but otherwise they're just words.
Actually in usage I type {} in Python and it is what it is.
I'm not arguing that these things aren't useful at all.
I'm arguing that the distinction between the CS-ified person that has spent the effort to learn what the words mean to pass interviews is not substantially more knowledgeable or useful than the version of that person that will have to find it out in the future. It's marginal.
Basically it feels like a sort of 'table manners' test. You've put the fork on the wrong side of the plate, so you can't eat dinner with us today, you scoundrel.
Don't take this to mean that I think that computer science is useless. Far, far from it. It is simply that I think that relying on jargon is testing whether someone genuinely has a CS degree (or equivalent without certification). It's not testing whether someone is a good programmer.
If that's what you want, just ask for it. Let's not waste each other's time and money.
The anger here exists because people want good faith interviewing, and instead they get "bloody hell the last 20 people were crap I can't be bothered any more" interviewing.
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'.
They fire people quickly, sure, but they don't "just hire them" either.
You seem to infer that the phrase "just hire them" means you do absolutely zero interviewing, which was not my intention.
When I said "just hire them" I meant "do some obvious stuff, like talk about their experience, ask a high-level question and expect a discussiony answer, not short, commoditized trivia, and if based on that stuff it seems reasonable, then just hire them and don't obsess over cramming more dumb trivia filters into the process."
I took it for granted that everyone reading this would understand that basic interview (e.g. talk to someone, ask about their resume items, have a discussion) is always necessary.
The "just hire them" part is meant to say that people should not get stuck up their own ass with trying to put together a ridiculous number of commodity filters up front before getting to that conversation stage, and that the conversation stage should function more like a rolling basis hire than like a process in which you tediously examine every candidate first, then go back and eliminate and re-interview, etc.
I think the Netflix process fits what I'm saying very well.
The article might go over the top a bit with self-pity, but personally I just see it as suboptimal behaviour.
http://danluu.com/programmer-moneyball/ - Dan Luu explains better than I can.
I think fundamentally the idea of paying developer X 40K and developer Y 80K (because developer Y has been twice as effective in the past) is broken, because it negates the impact of environment.
If you pay someone 150K GBP in London they can live next door to the office, have TaskRabbit like services perform all household tasks for them, and spend their time exercising and reading 24/7. They will kill it.
Pay them 30K, and regardless of pedigree, they're going to struggle.
Somewhere in there is a balance and I argue it's far less to do with certification and more the circumstances of life which as an employer you have huge discretion to influence.
Basically, it's about steelmanning. Why is someone bad? Is it that they're inherently genetically dysfunctional? Or is it that they haven't been coached well or have a difficult environment?
Given good faith, most of the developers I know have the ability to be amazing. I include myself in that (am I that good? dunno, impostor syndrome innit). But they are stifled by needless nonsense. Management, open office, low pay, commute, stress, basically. Kill the stress and you get your '10x engineer'. Keep the stress and your '10x engineer' turns into a chocolate mousse.
From my point of view, an interview really isn't an exchange between equals, but a meetup where two parties meet, state their demands and evaluate each other. It works in both directions of course.
>> From my point of view, an interview really isn't an exchange between equals
If you design it that way, sure. It doesn't have to be like that.
The whole principle here is that there exists a growing portion of developers who can't be bothered with interview ping pong.
If you don't want them, great! Everyone wins. You don't need to convince us, we won't be working at your company anyway.
Again, are we speaking of giving out straight IQ tests? I think there's plenty of people that would be against that, plenty of people that consider IQ tests to be fundamentally flawed. And if not IQ tests, how do you measure problem solving and learning ability?
Maybe you give the interviewee something to do, like an algorithm or a piece of code to develop on the spot, right? But maybe your personal expertise doesn't match with what the interviewer wants or needs. And the interviewer has to give you some problem to solve in some way.
I remember that at a coding interview I was given the problem of programming a Lego Mindstorms device to detect obstacles and do stuff. But then the problem was really about reading a document on the C subset used to program the device, along with the several couple of functions needed to control the motion and read the sensors. Was that measuring learning ability in any way? Of course, if you think that the skill of reading a technical document with precise instructions is so rare. But that wasn't real world problem solving.
So how can you test real world problem solving? Do you give candidates a homework? Ah, but then you run into another problem: the good candidates, the ones that might actually solve your homework, are rarely interested in spending their time on such things, because most good people already have jobs and a life and things to do and you can consider yourself lucky if you get their attention for a couple of hours.
In that light, I don't think it's that unfair to give problems to solve that rely on basic algorithms and data structures, especially for companies where the problems solved are much harder than that.
BFS and DFS are the bread and butter of tree/graph problems and every software engineer is expected to encounter them at least once in their life. What if you want to debug a complex data structure or just a tree and want to print out its contents in order? Is it really such a weird thing? It's akin to asking to do a for loop through a list to print the elements, except slightly more complex (but certainly something that should be achievable by intuition rather than by memory).
It is intuitive, which even further pushes the question "Why do I need to know this to be an effective programmer"?
Actually, they are more than just words. Try not to conflate the abstract data structure itself with the language-specific implementations which can vary quite significantly. Also your flippant, dismissive attitude on quite important CS concepts wouldn't take you far. It's better to frame your argument like this ... "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for" which is quite reasonable as most devs CS-minted or otherwise will agree with you. & also while it might not be useful to rote memorize every single CS concept, it's sensible to at least have a passing familiarity. Why? Well, not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.
Please try to avoid this. We can discuss without resorting to attacks.
>> "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for"
That's what most people are arguing for I think, so I agree with you there.
>> not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.
By doing this you are throwing away developers that have made their respective companies millions in revenue. It's not hypothetical. One day, a non-CS trained developer will come across a tree and use it. And then they'll learn.
I think what I see as the real concern is a case of "not knowing what you don't know." If you aren't exposed to at least the fundamentals of this broad base of CS knowledge you aren't going to know that they are available to you when you need them. Learning about a tree when you first read about it is great. But that person will still have huge gaps in their CS knowledge compared to someone who systematically studied it.
I also don't think this is so much about having a CS degree, as it is simply having studied CS in some fashion. I've worked with plenty of talented self-taught developers who took the time to learn these things on their own.
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.
ok. It wasn't obvious to me lol
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"?
My favorite questions are when companies ask actual problems they're having and try to get the interviewee to suggest solutions and/or implementations.
You speak about the problem domain, but the primary problem domain we are facing first is programming. And without a shared vocabulary, you can talk with other software developers, but you aren't going to be very efficient in that communication. So going back to the problem domain, as software developers we are supposed to master whatever problem domain we are facing, in order to efficiently communicate with the business side in their own domain-specific language. How are we supposed to do that if we haven't even bothered to learn our own domain-specific language?
But it goes deeper than that. Many software developers these days rely too much on libraries, without knowing how they work. And this hurts them a lot.
This is all about standing on the shoulders of giants. And it all starts from the most basic data-structures and algorithms. BFS is right up there with the characteristics of a List or a Map. It's common knowledge that everybody should know. And this common knowledge is half of "Introduction to Algorithms" by Cormen et al. So instead of reading another fluffy piece on Agile methodologies or on soft skills like the "Pragmatic Programmer", or other such bullshit, maybe people should read this one instead.
One recent problem we had was one of scaling out our micro-service-based infrastructure. And I've heard from colleagues wild ideas like "oh, lets introduce an external queue, like Kafka". DevOps for some reason think external queues are the solution to all problems. Yeah, great, but this isn't a freaking webpage reading from a database, we've got singletons, as in producers of truth that need strong consistency in their decision-making because we aren't that smart and you're just moving the problem around, because locks don't freaking scale, no matter how smart your queue is. Or "we'll just add Akka Cluster or Finagle or whathaveyou, should take care of it". Dude, yeah, we've got singletons, which means we need to do sharding and have a protocol for failure detection, so maybe we should talk about that first.
This is just a recent example. Developers are so eager to jump to the latest fads and the latest cool things, without thinking for a second if those solutions would work, only because they can't imagine how these tools are even implemented. And this isn't something that a superficial Google search can fix, because the unknown keeps piling up, the more complex the system is, until the shit hits the fan and you throw your hands in the air and bring in external consultants to fix it. And if you think the UI is spared from all of these problems, think again. I've seen dozens of Javascript-enabled interfaces with performance issues, only because of the "thundering herd" problem happening due to sloppy event handling. How many UI folks understand how Facebook's React works? Not that many.
Interviews exist because employers need a way to quantify and qualify your ability. Typical computer science problems are a (flawed, but concrete) way of doing that. No reasonable interviewer expects you to recollect breadth-first search flawlessly, on demand, onto a whiteboard. But they do expect you to be able to reason from a problem statement to something approximating a solution. That's fundamentally what programmers do. You should have the chops to think in this way, and you should be eager to try. Emoting "what the fuck?!" and claiming you can't, or won't, because you're not a recent graduate is an excuse and a cop-out.
A few popular open-source projects don't necessarily speak to your talent as a programmer. A 960 day GitHub streak is trivia, not a signal of anything useful. (If anything, it marks you as a target for burnout!) A few Hackathon wins and a couple hundred GH stars are the artifacts of a successful hobbyist, not a proxy for professional ability, or a gateway to employment.
My recent hires are all just people I met at events. I'm told by people outside the company that they're all very happy workers.
We do not do technical interviews. We talk casually about past work and what people want to achieve. After hiring we usually find out they have a different skillset and then we find the right tasks to match experience vs. career path.
Knowing this works for my team I would never want to go back to full-time employment at a place with HR ever again. HR has become an insular group of "specialists" who do not deliver value to organizations, and often ruin them IMO.
It's just really hard to decipher one's ability when everyone puts technical experience on their resume because they took an online class or read a book on some thing once.
GitHub stars are worth much more IMO. It shows that other developers value your work. That says a lot.
In the end, we have to realize that most developers are just average. Why go through the ridiculous process of finding average developers who by luck (or some homework) happen to solve the problems you throw at them perfectly?
I'm always happy to get a kudos on GitHub. But those of us who don't play the game of promoting our own code on social media, or who have code we can't post on GitHub, would be at a significant disadvantage in a hiring process based on that metric.
Never underestimate the value of hard work, preparation, and a can-do attitude. It eclipses natural talent every time.
If you think that AT LEAST one part of the hiring "process" isn't broken, you're living in lala land.
Lets just pick one: recruiters. You're telling me that every single tech recruiter you've come across is excellent at what they do, an amazing and decent human being and has amazing communication skills?!
(Generally/Most of the time) Recruiters don't--and yes, they should--care about candidates. They're interested in pocketing their cut of the candidates salary, so as soon as the company says they're not interested in the candidate, the recruiter is done. Most people don't get call-backs even informing them that they're out of the running, much less a reason as to why they weren't deemed qualified.
Recruiters--especially tech recruiters are NOTORIOUS for being bottom-dwelling scum. I actually know a few good recruiters, but they are--by far--in the minority.
The fact that you don't recognize this indicates that you've either had extraordinary/atypical results, or aren't very familiar with the "process". Dude.
Edit: spelling, puncturation
How do you know his skills aren't useful to the market? That seems like a terrible thing to say.
Maybe I am conceited, but I can't convince myself I am an inferior programmer because of it. I can make money for your company. I can work well with a diverse of group of people. I take pains to conduct myself with integrity. Shouldn't all that be the central measure of how people are hired ?
In under 45 minutes? Are you really concerned with their ability to even naively solve an algorithmic problem in that time frame? I would think not. No, this is not only flawed, but it's so deeply flawed (and easily exploitable), that you're not even interviewing for skill set anymore, simply either 1) someone's luck for having been exposed to the problem before or 2) their ability to remember things they don't use day to day.
Congratulations, you're hiring lucky people or idiot savants.
She was offered the job on the spot.
Yes, absolutely.
If having source code and demonstrated traction for a few open source projects to review don't speak to one's talent as a programmer, then what does?
A professional programmer, the one hired by a company to work alongside other professionals - as opposed to one working by themselves on small projects - is capable of presenting previous experiences and applying them to new problems. Unless you want to be put in the basement and handed small chunks of work to solve. It's about how you mentor juniors, resolve disagreements on how to proceed, deal with set backs and changing requirements.
Given the whole post is about how terrible the interviewing process is the above quote is the most telling, and backs up the GPs point - not being prepared to have a conversation about your previous experience when interviewing for a job is pretty bad.
Almost in any interview I had, I been asked about CS stuff. Never anything related to my field.
I don't blame them. They ask about what they know and what they think it's important, even if it's not relevant to the position.
The author seems to have a chip on his shoulder...
Front-ends almost always involve working with data. It is increasingly common for front-ends to have filters, searching, sorting, etc... of that data as well.
Doing that efficiently is key to ensuring a fast, responsive UI.
Wrangling with divs and CSS may take a disproportionately large amount of your time but that doesn't mean it's the most important skill to look for, nor does it mean the CS questions are somehow irrelevant to the work.
There are some positions where you don't have to care if people can really problem-solve; as long as they can tweak CSS until it works right-ish, or know the particular arcane implementation details of installing some WordPress module, they can do the job. But there are a lot more positions where you want someone who can solve the problems that need solving, pick up new technologies as needed, and just generally be a flexible and productive contributor in a way that doesn't relate to the fiddly details of one particular technology.
Wait, really? I've had to do more than that just for internships, the bar for perfection at many companies is just that high or higher.
I agree with the rest of what you're saying.
Heck, what if I picked 5 problems from a national level math-Olympiad. You've surey studied high school math right? Should be able to solve them in the 5 hour interview I invite you to!
I didn't even want to go to the interview which landed me my new job. In my previous phone screen they were looking to hire a single person.The perfect fit. Probably not me - what the hell do I know about video players? And it's one of those interviews where they'll boot you to the curb if you do poorly in the first half. Whatever, I'll go anyway. And as luck would have it, I didn't get booted. I did damn well. And in my final phone screen with the CTO, I got asked how to find the Nth last spot from the end of a linked list.
I really wasn't good at interviewing for a long time. And from the outset, I didn't know everything I needed to get the job I wanted. It was consistent studying and a buy-in to the bullshit that interviewing is that landed me a new job.
There is another side to this which leads me to ask why companies feel they have to be so defensive? My wife is a registered nurse on a cardiac critical care ward. If she doesn't know what she's doing actual people can actually die, something that is a rare outcome for even the worst software developer. Nevertheless, she has a BS, and work experience, and when she interviews they don't require her to stand up at a whiteboard and prove she's a nurse all over again. They respect her experience, and the questions are more about process, work habits, personality, etc. In the software development world we appear to have zero respect for experience, and I wonder why that is? Have employers been burned so often? Or is this more of a geek cred gauntlet thing?
On the one hand: the interview processes this post describes are hilariously broken. Stand up at a whiteboard and implement breadth-first search from memory! You know, like no programmer at their desk staring at their editor ever does. I think "that's the one where you use a queue, right?" is a fully valid and complete answer to that dumb question.
I also think you're within your rights to demand that your interviewer implement Kruskal's minimum cost spanning tree from memory at the same whiteboard before you have to do BFS. That's an extremely simple and important graph theory algorithm that nobody memorizes either.
These interviews are nerd status rituals. Really good candidates know this and game them. If you know anyone like this, ask them for stories. I've heard some great ones. But obviously, this isn't a good way to select software developers.
On the other hand...
The idea that "front-end developers" shouldn't need to be able to implement a BFS (at all) bothers me a lot. If you're a software developer, you should grok basic conceptual computer science. You should be able to work with a graph. If you're doing web work, you're working with graphs all day whether you grok that or not!
I've been doing front-end work for the past month, and I've had to do more low-level profiling and performance work here than in the previous 4 years of low-level systems work.
As a self taught programmer things like binary search trees and linked lists are a foreign concepts (especially as a self taught frontend developer). When I am asked to solve a problem in a way I've never encountered before, people are pretty open to explaining how the problem works.
I don't get frustrated if a problem seems arbitrary or obscure because that's typically not the point. The point is, if you're going to join my team, how do you approach a difficult problem; do you get upset? do you clam up? I don't want someone like that on my team. I'd say most people would prefer a teammate who is resourceful rather than one who only wants to solve problems they're comfortable solving.
For experienced people, it's not what you know, it's who you know. You tell your connected friend that you're looking for a job, he tells you who's hiring and gives you a recommendation.
You still have an interview, but it's no longer adversarial, it's a formality, it's friendly, it's just a screen to make sure you're not faking it. One of the people on the other side of the table has seen your work before, so is on your side. So when you get those stupid questions, it's a joke that you all laugh at. You handwave at it, and it's enough.
There are obviously problems with the above process -- it leads to hiring friends rather than the "best" candidate, but I'm surprised that we've moved so far away from it that the obviously well-connected OP is having so much trouble.
Those went smoothly so I was asked to fly out to Los Gatos, CA.
On-site I was supposed to talk first with the senior engineer I had already interviewed with over the phone. He was out sick so they changed at the last minute.
In walks a guy in a fedora with full tattoo sleeves. He glances at my resume and laughs saying he hasn't looked at it at all and really knows nothing about me.
He proceeds to ask me detailed questions about Node.js. I told him that I was very clear with them on the phone, that I've played around with Node, but I hadn't used it to any serious degree (at that point in my career).
He continued with the Node.js questions for a while, some of which I knew because they were the same as the browser (console) some of which I wasn't familiar with at the time (EventEmitter).
He then asked me some simple JavaScript, Backbone, CSS questions all of which were easy. He then asked me a C# question and I knew that too.
We shook hands and after he left, the engineering manager came back in and I was basically escorted out. He said I was good but that I wasn't what they were looking for.
I've had some retarded interview experiences but that one took the cake.
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.
Has his network moved forward in what they do? I've found with my own network that so many of them are in the same (or equivalent) spots they were when I left to advance my career. Not precisely positions of power which I can take advantage of for the next step forward in my career.
> To be fair, I already knew about Google’s idiotic interview process that is optimized for hiring book-smart academic candidates who know their algorithms and data structures cold, so my expectations were rather low to begin with. I also did not get much sleep that day, so my problem solving skills weren’t at its peak.
The author is already annoyed, antagonistic, and planning for failure. He knew what he was up against, but didn't adequately prepare to succeed by studying. And didn't sleep the night before.
And none of the reasons for not succeeding are the author's fault, in his mind.
You can claim that the screening process is dumb, and in some ways you're right. But at the same time, this process does select to some extent at least against the people who make excuses instead of bringing their A-game when it counts.
If you want a job at a place like this, you can do it: commit yourself to a plan of action for success that involves real work and preparation. Wanting to change the industry practice of the top tier firms is interesting and all. But if you want to get in, work and preparation will reap more rewards than complaining.
If Google wants to ask crazy algorithm questions, that's at least sort-of reasonable. There's at least a hypothetical chance your work will involve that knowledge.
But I've interviewed at companies who's entire tech stack is a simple CRUD web app, or a simple RESTful mobile app, who's so-called "big data" is less than a few gigabytes in total, and they still want to throw algorithms and brain teasers at me. These same companies then post some inane blog post about the "developer shortage" and how "we can't find talented people".
If these companies could actually find the candidate they're testing for -- this hypothetical hyper-intelligent developer who had a IBM-Watson-like memory of every CS algorithm and it's application in every language, that person would get completely bored working there and quit in 3 months or so. These companies could never retain the type of person their own hiring process exclusively selects for
---
Hiring doesn't need to get fixed, companies need to get honest about what they are and what they actually want. To restate this in 1-10 scale : Many companies delude themselves into believing they are a 9 or 10, and are trying exclusively to hire 10's (and hypothetical 11's that don't exist).
When in reality, most companies are in the 4 to 6 range, they only need people in the 4 to 6 range, but are rejecting 7 and 8s type candidates, because they aren't a 10.
This process itself isn't broken, so much as the businesses holding the power in the process are delusional about...everything (what they are, what they need, who could provide that, etc).
A) Has good experience
B) Has the ability to reason about problem domains even if they can't scribble out a perfect implementation with all edge cases considered on a white board in under 30 minutes.
C) Has good interpersonal skills.
For example, Lifion interviewers who wanted me to write fibonacci couldn’t tell me what the sequence definition was, they ‘taught’ me that C++ classes default visibility was protected or that REST was a protocol, they didn’t like when I said they should use a relational database if mongodb lack of multi documents atomicity was such a problem. That was so mind blowing that I started writing down on my phone all the stuff they said.
I might write an article about all that too actually.
During my interview, the interviewer asked me where I was getting my CS degree from, and I replied that I wasn't getting a CS degree — my major was chemical engineering. He was silent for a few seconds, so I'm pretty sure that wasn't the answer he was expecting.
What I remember about the interview process is that I was asked to implement some kind of odd search/sort algorithm. I remember thinking "why would I have this memorized off the top of my head when I could easily Google the best algorithm suited for the task?"
In high school, I don't think there was ever a chemistry or math exam that I didn't get a perfect score on, but I would also take much longer to finish than the other students. I frequently ran over the allotted class time and worked well into the lunch period (luckily, I had nice teachers who allowed me to do this). In college, I remember perplexing the physics professor, because I got 70s-80s on the quizzes throughout the semester, then I got a 113 on the final exam. I told him the only difference was that I was given 20 minutes for the quizzes, whereas I had 3 hours to complete the final exam. The extra time made all the difference.
So I wonder if a lot of companies are missing out when they look for 1) people who have a lot of simplistic CS algorithms memorized and 2) people who can work quickly on the spot. I may not be able to write a FizzBubbleRedBlackSort algorithm on a whiteboard in ten minutes, but give me a week and I'll have you a parallelized implementation of quantum monte carlo that runs on a hundred thousand cores.
It isn't a question of whether you can do it, it is whether you can find a 'good enough' solution in an optimal amount of time. It is testing your creativity and problem-solving abilities.
If my PM ever walked up to me and said, "Hey, I have this project, and I need you to have it back to me in an hour," I would laugh, then escort them over to their boss, who would also laugh at them before they walked back to their desk in shame.
It's not testing anything but whether or not you're good at studying for exams.
Google studied their own interview process, according to Lazlo Bock, examining tens of thousands of hiring decisions. The study concluded that their process was no better than random chance at finding good candidates. They continue with that process nevertheless.
I have a rich network of Silicon Valley connections, built over 29 years of working for Valley companies. What I hear time and again is that many highly-qualified and productive people have a terrible time finding work.
Simultaneously, Silicon Valley companies testify before congress and complain to the press that there is a serious shortage of technical hires.
If companies can't find enough good candidates, and good candidates can't find enough offers, and one of the most prosperous companies in technology, with the most famously rigorous hiring process in the industry says that their own process is bullshit, then yeah, I'd say that hiring is broken.
Of course, if you happen to be prospering, then it doesn't look broken to you. You're prospering, after all.
And of course, if some joker comes along and says that the process that hired you is broken and gives results no better than random chance, of course you aren't likely to agree. After all, if it was luck that gave you your prosperity, then luck could just as easily take it away again.
The story we like to tell is that the technical interview screens out bad candidates. It's just a story, though. Google's research says it doesn't.
Is that such a big surprise, though? How many times in my three decades in software has a product launch depended on someone being able to solve a brain teaser in front of a critical stranger? Zero. How many times has a company's success depended on someone writing the right code on a whiteboard? Zero. How many times has the bottom line depended on someone coming up with the right algorithm or data structure off the top of their head in a conversation? Zero.
Technical interviews, if they measure anything at all, measure things that don't have much to do with technical jobs. So it shouldn't be a big surprise that they don't do better than chance at predicting someone's performance.
If technical interviews don't work, why do we still use them? Why does Google still use a hiring process that its own research says is bullshit?
Maybe it's because we don't have anything better.
I think it's because on some level we realize that we don't actually know how to distinguish good candidates from bad ones, but we don't want to admit it to ourselves. We want to think that we can pick the right candidate, because it can be so costly if we don't.
So we ritualize the process. We rely on a bullshit hazing ritual. We wave a dead chicken over it and tell ourselves that we are screening out bad candidates and hiring only the best.
Only we're not. If we were, then maybe companies would still have a hard time finding enough candidates, or maybe good candidates would still have a hard time finding jobs, but not both at the same time. And the company with the most 'rigorous' hiring process in the industry wouldn't be concluding that their own process is nonsense.
Yeah. It's broken.
Once I found a company that actually _needed_ me, the experience became a positive one - they went out of my way to make me feel comfortable.
I wish there were a way for candidates to pre-screen companies, rather than the other way around. It's a waste of time on both parties if the company isn't actually in need of a new hire, but just dabbling in the option pool.
To each their own on their personal time, but you can't seriously expect that being associated with a stigmatized hobby is going to gain you anything.
It's such a silly thing, but humans are animals and we have annoying or shitty things like pack/tribe mentalities.
There are three attributes you need to select for to identify performing employees in intellectual fields.
- General mental ability (Are they generally smart)
- Work sample test. NOT HAZING! As close as possible to the actual work they'd be doing.
- Integrity (The first two won't matter if the candidate is a sociopath).
This alone will get you > 65% hit rate. [1]
http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...Hell one of these companies should hire me to do data driven recruiting.
Every employer I've worked for has made the experience farcical. If not at the start, then over time. You interview for one job, and eventually end up doing something else.
A full time career that doesn't pay enough to buy a home. And they say software developers are overpaid.
I think the end-game for me is to just go camping with a laptop or something. I'll code for fun, rather than trying to meet this 'market demand' which provides people with studio apartments, temporarily, in exchange for ~all of their productive hours.
If you knew the correct answer to e.g. the BFS algorithm, you'll get thrown another question that they hope you don't know.
When interviewing, the thing I want to see most is how someone works through a problem: can they solve from first principles? do they go via trial and error? do they ask for a computer to google things up/a book?
Picking raw CS problems is an easy option, as its something that you should be able to solve, and it means I don't have to require you to know Angular/React/Flavour of the month (new tools are easy to teach the right candidate).
You're not going to immediately know the answer to everything that comes up in your job; so evaluating how you solve the unfamiliar is very important.
It absolutely includes talking to people. But not people you don't know, in a very high stress situation, under the pressure to solve the problem in thirty minutes :)
That is sometimes required, definitely. But I'd say that situation only applies to the .01% of real-life programming situations.
Almost all are simply playing "programming trivia." They name an algorithm or a data structure, and then evaluate whether you can recite it from memory. That's it. There is no problem-solving element involved. It is purely a test of whether you can memorize and recite.
This requires a lot less effort on the part of the interviewer than the style you describe, and also bolsters their ego and makes them feel clever when they find a candidate who can't recite properly.
Seriously there's a job with your name on it if you're interested.
When I interview candidates I sit with them for half an hour or so to get to know them. Then I give them purposely broken, poorly written piece of code which I tell them to pull apart. This proves incredibly effective as even if they miss some of the more obvious errors I can at least point them in that area and then see if they can see the problem on their own. There are about 100 different things to talk about so it really gives me an idea of the level they are at, and also the type of programmer they are; passionate, lazy, smart, meticulous, inexperienced, confident etc. Then if I feel they are worth a second interview, I get them back to sit with me and my team for the day to see how they fit in with the team. Then all being well I offer the job.
I disagree. I think we do know what we want, but there is no cheap/easy litmus test for this. If time, money, and opportunity were free, the way to find out if someone is a good programmer is to work with them for a long time.
Okay, now find a cheap way to do that while both sides of the interview have to juggle full time jobs and other interviews.
I've never had a web-app that failed due to performance. I can't recall any that ever have, except Facebooks' attempt to use HTML on mobile.
UI performance has little to do with algorithms, and only occasionally requires opening the profiler to hit 60fps with some tweaks to bone-headed nested loops. Or maybe reconsider your use of Angular!
Front-end apps fail because long-lived mutable state is a powerful engine of complexity, and algorithms do not solve complexity. I am constantly telling my team (CS back-enders prepare yourself!) to ignore performance concerns. O-whatever has zero-impact on delivering simple, extensible, bug-free web apps that please its users.
But admittedly, crafting good software isn't as objectively clear as implementing a mathematical function that makes your server code perform. The proliferation of front-end frameworks and compile-to-js languages indicates that writing FE software that works remains a far greater challenge than writing FE software that hums.
To that point, maintaining a popular github repo for a library or app that demonstrates your ability to write, maintain, and extend FE software is still the best sign that you know what you're doing, and that you like what you're doing. Conversely, knowing a lot of algorithms as a FE candidate tells me nothing about whether your first PR will be your last.
On a happy note, Netflix didn't ask me a single question regarding algorithms! Their interview's focus on OOP made sense, even if it didn't fit with my own focus on ClojureScript and FP.
That said, it's perverse that there's a cottage industry around software engineering interview training on both sides of the table for the crazy questions that are being asked. No one wants this, but sadly, once you're in the door at these places that do these sorts of interviews, the motivation to affect change approaches zero.
There are some companies that have tried to make this a fairer assessment though, e.g. Foursquare http://engineering.foursquare.com/2016/04/04/improving-our-e.... Putting this sort of effort into an interview process is time-consuming, but if the software industry is going to make its interview practices assess candidates more fairly, it's going to take effort.
Coding contest skills are very unfair to senior developers because they are out of school long time and do not have the time or motivation to engage in coding competition. And this also creates different incentive models. I have seen people who flunked very elementary CS courses (OS, networking etc.) to spend more time coding competition to get hired in big companies. This is really weird because they have to learn these things to become a real developer and they are gonna learn these things in company's time which they should know already. That being said, I personally think, problems like maze solving and inverting binary tree are fair questions. These are not exotic DP problems, these are just simple problems.
OTOH, the whole years of experience thing is unfair for new developers who do not have the experience but smart enough to learn and outperform many developers with experience who just memorized APIs over years of experience. There must be a healthy compromise between these two types of hiring.
Developers like to think they're on top of their game straight out of school and are able to design and develop 100k LOC apps off the bat. They could use a healthy dose of humility, because those that can are few and far in between.
The sorrier reality is that most of them spend their first couple of years learning how to work in a team, and then next 5-15 years picking up good habits and design patterns, and subsequently learning to not systematically use them once they know better. (I can't say first hand what comes after, but I would imagine yet more of the same.)
So while I lined up clients and started transitioning from the current job I applied for a couple positions (note that as an executive I did this by contacting other executives (when possible) at firms, not filling out forms on the website).
I had a few phone interviews, and these were fine.
But a couple times it would get kicked to HR and they would send links for personality tests - before I ever talked to anyone.
I guess if I was desperate for a job (really glad I didn't take one) I might have complied, but I decided I didn't want to work for a firm that approaches recruitment like that.
What country was this in? In Ireland that qualifies as employment discrimination on the "civil status" ground.
Oh, single person. Ha, it is illegal to discriminate on the basis of civil status. They meant it as "one person".
If you apply to a Web company without much web dev experience (or knowledge) then yes, it'll count for less.
But that's true of anything. The bay area is probably the easiest place to get hired in tech right now as an engineer.
There is no such regulation in the tech industry. One bad hire I made faked his technical capabilities and I regretted it a lot when I had to work with him. I hope I've now learned how to spot that type of candidate (without resorting to interview hazing).
Way back, I was part of a 4-person team that did some phone interviews of contractors. We asked some pretty basic questions, based on their resumes, and after the call voted on him/her. One of my questions to see if they knew anything about C++ was just to ask if they could tell me what a class was. A bunch of candidates couldn't answer that question.
It really isn't that hard to ask some basic questions and talk about work experience, to get a handle on whether someone is actually a competent programmer or not. If you're looking for top-tier talent, this might not be sufficient, but most jobs do not need top-tier talent anyway.
BTW, why didn't you check references?
I don't doubt for a minute that there's some kind of alpha geek thing going on with a lot of interviews. But it's also a reflection of the fact we don't have a widely-accepted accreditation body that can vouch for people.
As the infamous CodingHorror post points out, an awful lot of programmers can't actually program. That means interviews have to check for more than culture fit. It also drives extremely high selectivity, and when you know you'll be rejecting 90% of your applicants it becomes that much harder to give everyone a smooth and welcoming interview.
Of course, none of this deals with the problem that (as Sahat found) many software interviews don't actually check for relevant skills. That's just stupid.
When getting licensed in a new state (ie move from Montana to California), you just need to submit basic paperwork, background check/get finger printed and then you are licensed for the new state (no need to retake an exam). All these comments seem to indicate nurses have insanely high selective pressures to weed out people who suck. It's really, really not the case. The stories I hear about certain nurses who completely lack common sense are astounding.
When my sister gets a new position (even when she started travel nursing after only 1 year of experience), she has a phone interview with a company hired by the hospital to find travel nurses. They may or may not contact her previous employers/references and then she finds out within a day or two if she has the job. It typically takes her 1 week to get a new assignment, 3 weeks tops if she is being exceptionally picky and trying to work in a specific area/hospital. That's all there is to it.
She's gone through this process about 6 times in the past two years (I've even seen her do a phone interview while at a wine tasting! -- and she was offered the position) and she rarely stresses about these interviews as they are not technical.
Every time credentials come up with respect to this industry there are a whole bunch of people who complain that credentials are meaningless because people can just cheat or coast their way through. They go so far as to include CS degrees themselves in that category. What makes you think the education and credentials for nurses are so much better than for software engineers that nurses can be hired based on credentials and software engineers cannot?
License requirements are by state, but yes, there is a licensing process.
> Does she have to have a certain number of continuing education hours every year?
It depends on the state, but yes, some states require a minimum number of hours of education to renew a license.
Reciting the implementation of some obscure algorithm from memory is entirely irrelevant to the daily job of a software engineer. Being able to do that does not make you a good software engineer, and most good software engineers cannot do that.
They do these "programming trivia" style interviews because it makes them feel clever and superior to the interviewees, and because it's a lot less work for them than conducting an interview that actually probes what level of software engineering talent the candidate has.
Frontend devs can do many tasks that systems engineers (who can supposedly whip out algorithms in their sleep) cannot do: - Make pages render properly in all popular browsers - Make responsive UIs - Align text of variable length in the vertical center of a page - Know when to use tables and when not to - Understand when to use a SPA app and what not to - Make SEO friendly pages
etc.
All this has nothing to do with said algos. I really think that people who don't understand this should not be interviewing frontend engineers.
React, Angular, Ember, etc, are all basically just giant tree diffing algorithms. The DOM is a tree. Understanding how to manipulate trees is important. Memorizing algorithms, less so, but it's absurd to suggest that front-end developers should get a pass on being able to code generalized solutions to problems.
More and more, "front end" is coming to mean "the whole application," and the difficulty is moving away from the gritty individual DOM manipulations and into writing structured algorithms to process large sets of application data and wrangle state, which you then throw into your deterministic renderer of choice.
It sounds like when you say "front end developer," you might really mean, "person who is comfortable with HTML and CSS." In that case, sure, that has nothing to do with algorithms, but that person is also not a software developer.
They were disappointed, they wanted to see runnable code right there on the whiteboard.
I think you're right, you should know basic conceptual computer science. I felt like I did a good job of explaining that I understand enough to do a real implementation if I had to, with man pages and my IDE and so on. But nope, they wanted a piece of acrylic to be a compiler, and that's just wrong IMO.
Anyways, I interviewed a company my friend Nate was working for, on a lark (my company was sort of winding down).
First question I got: "explain Bellman-Ford routing". Bellman-Ford is one of the simplest distributed systems algorithms there is, and certainly the simplest foundation for a routing protocol (it's what the RIP protocol does). I had, prior to that interview, implemented RIP twice, in two different jobs.
I totally bombed the interview! My mind just went blank. I could explain how link-state routing with shortest path graph reductions worked, but not how a much simpler algorithm worked.
The interview made some clucking noises about how interesting it was to be interviewing someone who wasn't a Stanford CS student.
The next interview asked me to implement Towers of Hanoi non-recursively. I refused.
Obviously, I didn't get an offer.
What do you do if you have a nested data structure (like a tree) and want to print it in order? You write a simple BFS on it.
It's not even a question where you need prior knowledge on the algorithm, it's just logical. He could've easily asked "Print the contents of this tree to screen" and it would've been the same.
I can see how some questions like implementing quick or merge sort can be annoying, most libraries have a sort() function that usually implement either (or similar), you don't often have to write them yourself, but a BFS does not fall into that category in my opinion.
What I have a problem with is the assertion that a front-end dev shouldn't have to grok BFS. Not "be able to implement from memory", but "be able to quickly implement on demand given a few minutes research".
This is a great, great point.
I'd like to add one more: Admitting when you don't know the answer. I've been in a number of recent phonescreens where we'd ask a technical question of a simple "good/bad" sort. My advise to those reading: If you don't know, just say so. "I'm really not sure." or "I knew at one point, but I'd have to go look it up again." Perfectly acceptable. No one's a walking encyclopedia, and to say you don't know show's humility. I'm much more comfortable with someone who says they don't know and will go look for the correct answer than someone who might stand in front of the customer and try to poker face.
To those reading this and taking notes for an interview, I'd say instances like these are a good opportunity to discuss. If you don't know, ask what the correct answer was. Ask why. See if you can build off the answer, sometimes you might get asked a question you couldn't recall the answer for, but once given, you can expand upon and demonstrate your knowledge in other ways.
I'll +1 this, but with a slight caveat. Some interviewers don't get it, and will ding you for this. Those are the companies to avoid.
OP sounds like someone who will rage quit and have tantrums. Those aren't employable qualities.
But is that an accurate impression in context? He obviously has a practical background, likes to code, and can solve problems.
How do you tell if he'll be a net benefit or a net loss to a team?
I don't think asking anyone to improvise a BFS tells you much about that.
When I interview candidates, I state up-front that I care less about the solutions than the steps taken to reach one. It's okay to ask for help or hints when confronted with a previously unfamiliar problem. But if I need to provide too much help, teach the use of basic tools (whether they are logical patterns or universal utilities), and even then getting to A solution requires excessive hand-holding, I will hold that against you.
Also, I will happily invert a question if needed. Showing one way to solve a given problem, I would expect a qualified candidate to be able to point out where it could be done differently.
When I interviewed at Google after working for a small company for 13 years, it was my first "newfangled" tech interview. I didn't know anybody in the room. And it was more than a formality. I'm a fairly terrible interviewee, and although I got hired (finally, after a very long process), I was hired at least a level below where I should have been. I blame my fuzzy memories of algorithms I haven't had to implement in 20+ years. I finally got promoted to the correct level nearly 2 years later.
Contrast this with Netflix, where I found the opening via my network. I knew more than half the people who interviewed me, and the interview itself felt like it was basically a formality. Days later they made an offer that I accepted.
I'm totally serious: I really wonder how many of these baffling interview experiences where seemingly highly-qualified candidates get turned down is really about non-technical and non-work-related factors, but no one wants to actually admit it. How much of it is due to personal biases by the interviewers, who may discriminate against people for various reasons? A lot of people want to surround themselves with people just like themselves, so if you have a company full of hipsters wearing fedoras and someone comes in for an interview and they don't look like that, they could easily be passed over because they're "not a fit for our company culture".
I don't think I'm half as competent as the guy who wrote this article, but I've had a much easier time getting jobs in general. My background isn't even CS, it's EE, so I totally suck at all the algorithm questions. But OTOH I generally apply for embedded programming positions where knowledge of algorithms isn't that important anyway. I even interviewed at Google (one of their recruiters contacted me) and had pretty much the same experience as him; I won't waste my time with that company again. A bunch of recruiters have tried to get me to interview at Bloomberg LP, but I would never work in that crappy open-plan environment that they're infamous for. But I frequently wonder how much of my success is just from being tall and in-shape, not having any obvious personality quirks, and "fitting in" with the look and the company culture (I interview with more stodgy places, not places with hipsters with arm-sleeve tattoos), rather than due to my technical proficiency.
There is some merit to trying to maintain culture if they have some formula for what works there and they want to maintain it but an engineer could pretty easily think something along the lines of "he's not hipster enough" and then make a case that they don't fit the culture but really not care about netflix's corporate ideas about culture.
If a candidate isn't willing to put in the work to prepare, it's not much of a cognitive leap for me to envision them telling me that implementing this or that feature is dumb, impractical and not needed. Many developers have this "start with no" defeatist attitude as their default position on most problems of moderate complexity, and it's a real problem. Given a chance to select for candidates that instead figure out a way to make it happen I'd rather take the winners.
That being said, though Google has contacted me a few times for an interview, I've never gone through with it mostly because I'm not that interested. I hear from a good friend who worked there that Google is full of "algorithms walking around looking for a problem" and as much as I like programming and problem solving I hate it when its lost sight of serving a human need and I skew strongly toward the experimentalist side (https://www.cs.purdue.edu/homes/dec/essay.criticize.html) of this whole thing we do.
I would however disagree with your handwaving statement that 'they only need people in the 4 to 6 range'. Sometimes companies need some highly skilled types to try and rein in the chaos being creating by the 4s and 6s.
And as they're all similar style questions, they should just read up on these. Hold off on interviews until you're confident, or just schedule the less-desirable firms first, so that you have enough time to read up.
Interviewees know that these questions are coming, they can control the schedule, and they're the only ones who know their own energy and state. Nobody tells them that it's up to them to do flow control. But it's a hot market and people want good programmers. Even if you don't do tree searches or inversions in your normal work day, you can show that you're good because you can understand this stuff. Most candidates can't. So please, take your time, skim the textbooks, take a few notes, maybe do a few flash cards.
It probably isn't the "right" way for programming interviews, but once you identify the rules of the game, it behooves you to play the game accordingly, no?
Fundamentally, I agree that it is silly to ask questions that don't have a high degree of relevance to the job in question. But I am conflicted.
Why haven't we (as an industry) done better with this? Clearly there must be a reason or friction in asking relevant questions in lieu of the current batch of algorithmic type interviews. What is that reason?
Perhaps OP should try avoiding recruiters and big sexy firms.
They report having a positive interview experience but were disappointed for being passed over.
"How is this possible — I have received emails from people all over the world, who praise and give me thanks for the work I’ve done on my open-source projects and tutorials (#humblebrag)"
Perhaps there was simply another qualified candidate? OP could use a little actual humility.
I do understand OPs point that the interview process can feel disconnected from the actual work. However writing software is only part of being a software engineer. Communication / working with others is also important. This is where attitude fits in. Being a professional isn't just about wearing the right clothes/etc.
Don't mean to beat up on the OP. Perhaps they would be a great employee and are feeling a little discouraged. Still, seems like all the praise for developers (e.g. being solicited by recruiters) has gone to their head.
Did he say that this should immediately qualify him for any job? No, his point was that although he has real-world projects used by hundreds of devs, this gives him barely any credence at all in interviews. Is it so "entitled" for him to expect that his work should speak on some of his behalf?
That seems like a reasonable interpretation, emphasized by when he got through all the programming questions without a problem, and still didn't get the job.
One thing I've found when I'm interviewing, I try to be enthusiastic and act like I really want to work at the company, even when it's a boring company. Attitude makes a huge difference.
Surely your prior work is under some sort of NDA? It's all proprietary (unless it is open source).
I got an offer and accepted it.
i wouldn't want to break that anonymity. also, i already had the displeasure of having a candidate turn his laptop to me and show his great coding a skills with a competitor online app store (yes, a major brand app store source), and i had to get involved in all sorts of annoyance from HR and legal. maybe I'm just dumb for taking those things seriously... but i think that's for the better
> I do not consider myself to be an excellent programmer, maybe an average at best (who can’t even pass a single tech interview), and a GitHub commit streak has absolutely nothing to do with one’s competence, skill or ability to code...my job at Yahoo was my first and will likely be my last one. From this moment on, I would rather be unemployed and homeless rather than do another tech interview. Enough is enough. I’ve hit my limit with this broken hiring bullshit in tech. No. More. Interviews. Done.
This comes off more as a "Oooh, I have a great post idea that will pick up traction on Medium!" move than anything else, unfortunately.
vs:
> At some point during our conversation I casually mentioned Webpack 2 and tree-shaking, which was followed by a question on how would I implement a tree-shaking algorithm. How the hell would I know?
Attitude cuts both ways.
I sort-of agree that these specific tasks shouldn't be used as an indicator of programming skills, but a breadth-first-search is really quite simple. It's mode of operation is in the name, and even if you haven't implemented one in a while, you should be able to derive some valid pseudo-code after a while. Especially if you do as much coding as this person claims, and thus are confronted with problems to solve on a regular basis.
This is a normal mode of self-conscious thought for a huge number of people who are otherwise excellent at their jobs and perfectly functional (e.g. introverts).
Plus, after you've worked a job for a while and know your team, know what's expected of you, and can get in the zone with some privacy, then these thoughts no longer really affect you. So they only play a significant role during an interview specifically because the interview is not at all a realistic representation of what working will be like.
I find it incredibly disturbing that you see fit to infer anything from the author's so-called "inability" to program "under stress." When someone makes that kind of inference, I think it says a lot more about their dysfunction as a colleague than it says about the other person's programming skill. Even if this problem had been Fizz Buzz or swapping two numbers, it's so, so far from simulating what a real work social situation would be like that it renders it useless for assessing the candidate, no matter if they answer it perfectly or fail completely. It's just a useless scenario.
I spend maybe four hours per coding in a moderately complex domain where I have zero need to know how to write a bfs. To ask someone to do it, then to ding them on it is just self-masturbatory behavior.
Something like that, right?
He proved that he's a decent programmer by releasing a bunch of semi-successful open source projects. He worked at Yahoo. He has 900+ days GitHub streak. That makes him passionate about building things more than a huge chunk of programmers.
Not being able to implement a random algorithm on a whiteboard while applying for a front-end position has absolutely nothing to do with the lack of passion. Of course he gave up, and so would I if I was in his shoes.
LOL yeah, that's what happened to me for my last job. A recruiting process that lasted 4 bloody months for an electronic designer position, and when I was finally hired they put me on software testing; not only I had never done this, but I had never heard it was a thing. Anyway, after less than 2 months I was better as this than the CS graduates who had been doing it for several years and they were asking me for help in their work.
But now I have been unemployed for 2.5 years, I made it to the interview stage only once during that time, and I have given up on even just applying to any job offer for the last 5 months because it is absolutely pointless and humiliating to be repeatedly discarded by people who are clueless, who don't give a flying fuck about the persons they "harvest" and lack the basic respect in social interactions (like spending 2 minutes of their precious time answering a question, not blatantly lying, doing what they said they'd do, or even just showing up at the very appointment themselves fixed!).
So yes, in a way, I've quitted and I am getting ready to become a street beggar when all savings are gone. In the blogger case, his situation is too fresh, I don't think his mood of the day will last long for this time (and after all, he got plenty of interviews, at least), but I am really really tired of these completely nonsensical recruiting processes and their humiliating consequences.
If you want someone to talk to (someone who is doing this), my contact info is in my profile.
As for "eventually end up doing something else" isn't that career development? We can't bemoan having non-technical senior managers if some developers don't go on to do that.
I think what you mean is that they have a mortgage they'll be repaying for a long time. Houses are still too expensive to buy in the UK with a junior- to mid-tier developer's salary in the UK, even if you went to a place like Cambridge and worked for Google.
The average salary for a "software developer" job posting in my city (Charlotte, NC) is $101k. The average income in Charlotte is $53k. The median home value is $167k. 60% of the value of a home in a year is pretty good.
I've also lived in Sydney, Mannheim, San Francisco, and Seattle, and I noticed similar economics in each of these places (where the salary of software developers tended to be quite high relative to the average income). Do you perhaps live somewhere with a very different trend?
Sources:
- http://www.indeed.com/salary?q1=software+developer&l1=charlo...
- http://www.bestplaces.net/economy/city/north_carolina/charlo...
http://www.theguardian.com/business/2016/mar/10/australias-m...
http://www.seattletimes.com/business/real-estate/king-county...
But seriously, I do the same thing. Have them look over some broken code for 10 minutes to collect their thoughts then have a discussion about the issues they found and various tangent topics relating to it. I'm amazed how uncommon this is.
But do you think this is easier to do if you get less candidates (looking at your location, I am assuming you only get a small fraction of candidates than if you were located in, say, London) ?
This is one of my pet peeves. The number of applications you get has absolutely nothing to do with the number of candidates you should consider, because it has absolutely nothing to do with the number of candidates that you can competently consider. You don't have to get through every resume, and trying to do so will just lead to biased "how can I say no" ad hoc filtering games.
The solution is to use an unbiased* pre-filter to restrict the number of applicants that you let into a thorough consideration process. Random selection is the pre filter that I would use, but there may be other valid choices (though outside of random selection, it's easy to let bias slip in).
Bonus points if you are transparent with candidates that get filtered out this way about why and how that happened. If you're messaging is constructed well, then they should understand that there were too many candidates to give all of them fair consideration, and that being filtered out reflects in no way on their worth as a candidate. So, they will be more likely to apply for future openings.
Sorry if it feels like I'm criticizing you. I don't mean to at all. It's just that this idea of being overwhelmed by candidates is absolutely pervasive in discussions of hiring, and it's a completely fake problem that leads to absolutely real difficulty on both sides of the hiring process.
* A lot of organizations resort to biased pre-filters to cull resumes, like unnecessary requirements. I'm of the opinion that this leads to suboptimal results, particularly if they align significantly with the biased filters that the rest of the industry your company is competing in uses. It means that there are qualified candidates that end up systematically under-recruited. Those are the Moneyball candidates. You should want those candidates because they are the most productive relative to the salaries they can demand. And even if you don't give them a lower salary than you would give a candidate that passes all the typical filters, then you will still have a significant retention advantage, which all told may be worth more than shaving salary in many (most?) situations.
I don't object to an employer wanting to see a background in data structures and algorithms, sql, binary, and a few branches of math. This is why I agree that hiring is broken but also understand that it isn't easy to fix.
Some of it stems from something very wonderful about our profession - we are flexible about how people can acquire this background. In law, you must do a 3 year JD[1], and you must typically pay way over 100k for it. Alternate paths toward learning this material are pretty much illegal (as in, we'll put you in jail if you try to practice law if you haven't done the 3-year degree, regardless of your master of the material).
For instance, I was a math major, and I only took a bit of formal CS. However, when I did self-study to try to plug some of these gaps (partially for interviews, partially for my own education), I was surprised with how much I actually had covered from a different angle. Many of my math (and later, in grad school, Industrial Engineering) professors ran "labs", some for a bit of extra credit, others as an optional set of assignments. I took graph theory through a math department and stuck around in the lab and so forth to implement some of the algorithms, to learn about how some types of proofs actually contain an algorithm. BFS, DFS, minimum spanning set. That all involved building trees, lists, using pointers. In numerical analysis, I did a lot of matrix algebra manipulations. And so on. If CS were run like law, it would be illegal for someone like me to work as a programmer, because my degree isn't an ABET accredited CS degree.
The downside to all of this, though, is that there is no recognized credential. I don't object to being taken through my paces, I object to how random, capricious, and redundant the process has become. I read a blog article about a programmer who took the bar and studied for 100 hours and passed. Think on that for a second and compare it to the amount of time people spend preparing for and taking what are essentially white board exams in technical interviews. The bar, an exam that is considered one of the most brutal rites of passage for a learned profession? In some ways, we go through that every time we do a new round of interviews when we change jobs!
Actuaries have to show understanding of relatively advanced math, but senior actuaries don't (to my knowledge) get grilled on integration by parts or some specialized set of partial differential equations when they interview. Why? Because there is a proper exam for their field (and unlike law, actuaries are free to obtain this background through multiple educational paths, they often major in math, but hardly always).
Another problem is the capriciousness of the tech exam/interviews. I believe that a "bill of rights" so to speak slowly evolved between examinee and governing board over time in true professions. The nursing and medical boards, the actuarial exams, the bar - these fields have a tough exam (or series of exams), but they are consistent, there is a clear study path, there is a commitment to grade them fairly, there is a clear study path, if you fail, you get feedback or at least a score (the bar doesn't write you back and say they "decided not to pursue your candidacy further at this time"), there is often a second (or additional) change at the exam, and, most importantly, when you pass you get a lasting, public credential respected by your peers in the field.
People often describe these exams as the most brutal, anxiety ridden, stressful events of their professional lives. This is why, I believe, they slowly evolved that "bill or rights" that protects the examinee.
Unfortunately, in tech, I believe we experience these exams over and over, but without any of those benefits.
I am a-ok with requiring people to show competence, but the way we go about it is, I think, badly broken. I believe that this process accounts for a great deal of attrition in the field, as well as people deciding not to enter the field in the first place.
[1] yes, a bit of handwaving, it's not quite that simple in some states.
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...
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.
2. It likely gives you valuable experience to answer white board questions.
I don't think it's a perfect process but it weeds out fakers/resume padders. Also a lot of companies arent looking for specialists but want broad skills to handle a variety of problems cause the problems 5 years from now could be very different for the company.
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."
Because I can't be expected to know their work as well as they do I describe their peers' opinions (well-respected in the NOC) and the soft-skills they have like mentoring, etc.
"Even though I was only an SDET, Dave took the time to help me fully understand the math involved in the problem domain and how to efficiently model it. This allowed for a 60% increase in my deliverables and put the entire team a week ahead of schedule."
Board certification is not a legal requirement in any jurisdiction I am aware of. The licensure tests and board certifications are separate, and the former is generally taken very close to when the doctor, lawyer, or nurse graduates from their program and completes their internship period.
> The second is that licensing, certification, and recertification are functions of state government, not voluntary industry guidelines.
Yes and no. State governments decide what they will recognize, but industry provides the training. Some of the shit that counts as "continuing education" for the medical profession is little better than what you get at DeVry for programmers.
That said, at least these professions have strong professional associations that birddog state licensing boards to keep the bullshit out. My original comment, in fact, was motivated by IEEE and ACM's attempts to do the same for software engineers and the way the industry seems to be laughing at their efforts.
If you have the "mental dexterity" to coming up with your own solution which is identical to Dijkstra's pathfinding algorithms in terms of complexity within an hour interview, you are a god among mortals.
And that's what they expect - a solution to a problem that is equal to the best minds of our field. I say this from experience: I was expected to do exactly that, and criticized when I came up with a O(n^3) instead of O(n^2).
If everyone is an 10x, then everyone is an 1x .. Isn't?
I thought that was a great question. It got me talking about something I cared about, knew very well, and showed my normal thought process and development process outside of an interview. It also gave the interviewer plenty of things to ask about, to "quiz" me on if they wanted, or to just make sure I could actually code.
If I'm ever in a position to interview someone one-on-one, that's most likely going to be my main question.
I had recently published a (terrible, but also terribly fun to write) JavaScript physics engine, which the interviewer saw on GitHub. He began with, "how does it work?" and then continued with probing questions, getting deeper and deeper into the various problems I solved while developing the library, especially focusing on tradeoffs between various choices.
By opening the discussion on "my turf," he put me at ease in the conversation, but by driving the interview with very technical questions, he also got the answers he needed about my technical ability.
I've asked this question in interviews a number of times, but it's primarily to gauge communication skills rather than technical skills. The biggest problem with using it as a technical screen is that candidates are really bad at choosing a project to tell you about. I've had candidates choose as their problem building out some responsive dynamic front end and their entire solution boils down to, I picked Angular and Bootstrap.
I went on a lot of interviews (maybe close to 100) before starting my own business, and I'd say at least 9/10 of them were very positive.
By positive: I felt we both left the interview a bit happier than we went in. We both had a legitimate good time, and enjoyed it. It wasn't a grind, both people got to know each other.
I'd say I had a 10% offer rate. The most common "why didn't you select me?" follow up answer I got was "we need someone who is an expert in XYZ language." Sometimes it was even that they need someone who is an expert in ABC library (when I was already pretty-much an expert in the language.)
The ones that did lead to job offers I didn't want after the interview.
The other 1/10 was because they had me take an IQ test, or do some really super long project, or meet with literally all 20 people in the company, or they made me sit in the lobby for 2 hours past the meeting time.
I would think this is something that should have been made clear from the get-go in the initial technical phone interview.
Anyone who goes to an in-person interview should expect, at minimum, that the interviewers have done their homework.
For example, if they just want Stanford or MIT grads, fine. But to bring someone into an interview - which may involve more than a day of travel, lost vacation time etc - just to tell them they went to the wrong college afterwards, that's plain infuriating and shows complete lack of courtesy.
There's nothing really wrong with that as long as they advertise such and make it clear before even starting the interview process that you won't be hired unless you're a library ABC or language XYZ expert. The problem comes when they don't advertise that, bring you in anyway, and waste everybody's time.
Someone eventually called me to reschedule, and it took every last ounce of my willpower not to perform a verbal auxiliary anus installation over the phone.
To name names and shame the shameful, it was SAIC (before they split into SAIC and Leidos).
It wasn't that big a deal, but they didn't have a good reason to make it not a deal breaker.
Such trivia is the opposite of useful hard work; preparation for it truly wastes time that could be better spent on other things; a can-do attitude would imply rejecting or ignoring requests to do such things.
As a result, the people who actually do take the time to complete it will not be completing it because of a good attitude or work ethic, yet you will mistakenly believe they are.
I think the concerns people have about the efficacy of this interview style is valid, but extending it to the point where you start to make claims about how people who can pass them aren't as good is ridiculous.
The types of candidates who spend the time necessary to memorize algorithm trivia for the sake of passing these exams are exactly like overfitted learning algorithms. What they happen to know is unlikely to generalize well. Of course you could get lucky and hire someone like that who can generalize, but that's rare. More often, since hiring is political, you pat yourself on the back for how "good" the candidate is (based on some trivia) and make excuses when their on-the-job performance isn't what you'd hoped, and find ways to deflect attention from that so that you, as an inefficient hirer, won't be called out on it.
Willingness to waste time overfitting yourself to algorithm trivia absolutely predicts worse later-on performance than candidates with demonstrated experience and pragmatism (e.g. I'm not wasting my time memorizing how to solve tricky things that rarely matter. I will look them up / derive them / figure them out when/if I need them).
If given the choice between hiring a math/programming olympiad winner vs. a Macgyver/Edison-like tinkerer who may not be able to explain how to convert between Thevenin and Norton circuit forms, but who took their family radio apart and put it back together, Macgyver/Edison wins every time (unless you're hiring for bullshit on-paper prestige, and of course many places are while proclaiming loudly that they aren't).
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.
Somewhere along the line, though, I learned to stop caring about pretending to be excited and just accept that a majority of companies won't hire me for what they perceive to be a lack of apathy. It's a pretty good filter for finding companies that I'd be happy working at, but I understand that it's not for everybody. I just hope for a much more genuine tech/otherwise community so that I don't have to pretend anymore. Pretending just feels like shit.
I'm not saying any of this under any financial comfort. I'm friggin' broke right now. Though, I'm much more content with myself, my quality of work has skyrocketed and I've learned to bulk cook a mean chicken thigh and lentil soup.
I gave up at that one. People told me, "find a job you enjoy" but I think it's a lie. No one pays you to enjoy yourself. I haven't found a job to make me happy. Maybe someone found that kind of job but I didn't.
So now I find a job, work for a couple years, then quit and take months off at a time. I use the money I earned to fund my travels, which I enjoy. And sometimes at work, I look back at something I built, and the feeling of having built something is a really great feeling (even if no one cares about that thing). Then I go back to glaring at my coworkers.
Gee, I am also very tired of people for which stuff went well, and think it is be the same for others. Can't you even imagine there is a variety of situations out there? Can't you imagine it may happen to you one day? Do you think people who encounter this kind of problems never had a shiny position earlier, and their "social skills" were considered perfect before some conceited internet stranger decided they were "socially inept"?
And you dare to talk about "experience", seriously?
I did not call the author "socially inept"; that sentence was a hypothetical example of how an individual's incredible technical skills can be overshadowed by other problems.
I am sorry if I offended you. I thought my posts were critical but logical...
As someone who watched previous coworkers, who are older, go through the interview ringer, I can sympathize with the author on the pigeonhole one can get stuck in due to seemingly trivial reasons: I don't have a classic CS background, people think I'm past my prime, etc.
These aren't imaginary problems, and I struggle to believe that I would be all "go-getter" and "pull yourself up by your bootstraps" after continually being rejected, too.
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.
It was the fact that I'd taken the time & effort to meet with these people and to not even get so much as an email back... it's not right. People shouldn't be treated that way, job candidate or not. It's basic manners.
"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.
No, I don't find it strange that I want them to prepare for something they're not going to use normally, but agree it might be confusing.
For the actual positions I'm hiring for, nobody in the world outside our teams understands the systems. The candidates are going to need to work hard to learn what's going on when they start their new job. Some of it is going to be hard to do and not always a complete pleasure. Essentially I see it as a personality test that selects for the kind of people that figure out how to overcome technical adversity.
Willingness to do the work to be prepared and eagerness to dive into technical arcana despite it being not very easy-- these things are very relevant to the positions I hire for at Microsoft.
<mind blown GIF goes here..>
> Essentially I see it as a personality test that selects for the kind of people that figure in it how to overcome technical adversity.
This seems at odds with the original "ask", as it were: study up on some basic CS algorithms, and now I know you can handle what we're going to throw at you here. Ignoring the obvious "well, we need to make sure they can learn basic things", how is this even a viable test if your environment is so advanced, so high up, that you expect new candidates to encounter actual adversity?
I think this pretty much sums up what is wrong with hiring.
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.
As for their code, I learn a little bit about their programming style -- and it's often unflattering and unhelpful, as these are usually personal projects where people write code below the standard they'd use at the office -- but it tells me little of what parts were hard, what parts involved real insight from the candidate, and what parts were pasted from stack overflow. Given a github URL, how much time do you think it takes to figure out where the interesting parts are? And what's the information payback of that time, given the little information you get about a person's actual capabilities from a bunch of text saved on a server?
I know that everyone's their own special snow flake, but I don't have more than the 45 minutes to give them a fair shake. And it has to be fair - a question that they should probably have enough context to know, and who's answer can't be bull-shitted. I've got 45 minutes to give as objective an interview I can, balancing the Type 1/2 errors of missing someone good, and hiring someone bad.
1 a week was an example of what I was doing when I went interviewing. I mentioned that as slow enough to read up as much as you need. Did you want more? Less?
[Edit: not speaking for my employer, whose name I don't want to mention. ]
I kind of get the impression you're bitter or projecting something, but I can't quite put my finger on it. Not trying to be snarky, just saying.
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?
Lets say your software as a service website has a real time analytics graph, so that customers can look at statistics of how much they are using the service in real time.
One potential question a customer might want to know is "How many API calls have I made over the last hour". This is a moving window average question, and it needs to be displayed/done on the front end.
My company that I work at has such a feature.
Algorithms questions come up all the time in javascript development.
If I were applying for your company, I would expect to have to implement an algorithm like this on the job, but I don't see why I should have to know it to get the job. As long as I was capable of implementing algorithms as described, wouldn't that be the most important factor?
What algorithms have you seen in practice in web frontends? I have seen nothing even minor, not even binary search or bublle sort.
I can cite examples from the front-end I'm working on right now, but that wouldn't sound like a fair example (it's an AVR debugger). But all sophisticated applications are complicated in their own ways, and most of them require developers who can actually, you know, program.
Even if all you're doing is CRUD, how much computer science is embedded in even a straightforward framework like React? "Lots", is I think the answer.
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.
But I grant this is reasoning just from the anecdata that I have. I can believe that winners perhaps represent a higher degree of skill, but then we're talking about an extremely small number of people.
Generally you're facing a tradeoff where you have to choose between a sort of rustic self-reliance skill set versus a bookworm skill set. People from either group can learn the other over time, but you can't predict how well by testing them solely on trivia that constitutes their current main group. My preference is to hire for self-reliance and learn bookworm stuff later. I used to believe the opposite (e.g. hire someone good at math because they can always learn to be an effective programmer later) but my job experience made me believe the opposite (e.g. actually it's pretty easy to teach people stochastic processes, machine learning, or cryptography, but it's incredibly hard to teach people how to be good at creative software design).
Source? or just trying to justify your own shortcomings?
[0] < https://en.wikipedia.org/wiki/Overfitting >
> Overfitting generally occurs when a model is excessively complex, such as having too many parameters relative to the number of observations. A model that has been overfit will generally have poor predictive performance, as it can exaggerate minor fluctuations in the data.
[1] < https://en.wikipedia.org/wiki/Generalization_error#Relation_... >
> The concepts of generalization error and overfitting are closely related. Overfitting occurs when the learned function f_S becomes sensitive to the noise in the sample. As a result, the function will perform well on the training set but not perform well on other data from the joint probability distribution of x and y. Thus, the more overfitting occurs, the larger the generalization error.
Shall I fetch a ruler?
> The types of candidates who spend the time necessary to memorize algorithm trivia for the sake of passing these exams are exactly like overfitted learning algorithms.
I should have asked for a source for that portion. It's the part that is ridiculous.
Again, my bad.
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.
IME, that's much more a consequence of the limited diversity of candidates, not a limited diversity of hires. In most places I've worked at, even if they hired all women and blacks (or other non-Asian minorities), there would still be at most approximately 5% women and 0% blacks (the latter would probably be higher in the US).
I have personally been rejected after a phone interview, not because my technical skills were lacking, but because the interviewer didn't like something he heard in our conversation. I could quite literally hear him checking out of the conversation and going back to surfing the internet.
You can find full exams with answers of CCNA and every Microsoft cert imaginable, I've worked for companies that incentivise certifications, and i watched coworkers use these 'tools' en masse to gain easy pay bumps and pad their resumes.
I've had two interviewers ever to ask me technical questions that actually tested my knowledge or capabilities. I look good enough on paper so usually interviews are with a couple managers and if there's a culture fit I'm in. Doesn't matter if i dont know a damn thing, if my resume says MCSE on it.
Microsoft and others further incentivise these certs by giving bonuses and breaks to companies employing certified individuals.
If you think people being hired because they passed a test they cheated on is 'more objective than other fields' then maybe i just have a warped view of how objective other fields are
I agree with you that certifications are crap but I haven't encountered a single good company that cares about them.
When my team would look at candidates, past accomplishments and projects counted for tons more than a cert. Still, a cert told us what someone was interested in and what they wanted to bone up on. They could expect questions relating to that cert field during the call. If they had trouble talking on the subject, then we knew that the cert was likely there to be a pad or just something to fulfill some billet requirement. In good cases we'd find that the cert was an indicator of something they were passionate about.
So I consider it a pointer of sorts. Never worthy of hiring someone on it's own, but I'd recommend them to people who are /ready/ to demonstrate knowledge and may not necessarily have the project experience otherwise. I'd just recommend to them that they be ready to talk to it in an interview.
Vastly fewer responses and recruiters on major sites, but i've got about another 6 months to go on a really interesting couple of projects at my current job, so I'm not too upset about it.
Sometimes it is almost required (see MS certs) to be competitive.
So, they only care because it's a business thing (not a qualification thing) but they do care.
The certificate shouldn't matter in the interview itself - it is just a way to pair down the choices of who you interview when you have many candidates. If you have knowledgeable people in the interview process (i.e. at least have a dev present for a dev interview, not just managers or HR people) then you should be able to catch those that don't really have the skills.
Heck, even people who genuinely have a certificate might be rubbish overall but revised well for the exam days - you'll hopefully weed those out in a good interview process too.
Have you had many IT interviews? I have, they are vastly non-technical interviews.
Unless you count "have you ever used #CommonSoftware? how about #SlightlylessCommonSoftware?" as a technical interview.
I'm an IT administrator, not a programmer, so i'm speaking to my experience in that field, I am not trying to make any claims about how programming interviews work.
I've never had a whiteboard in an interview, I have in two interviews ever been asked to walk through a diagnostic process for problems, or asked any infrastructure or network design/architecture questions.
Its worth noting I work and live in Detroit Michigan, so I'm not exactly interviewing with major technology companies regularly. But I have worked for MSPs which glossed over technical interviews in favor of culture fit as well. (MSPs are especially incentivised to have employees with certs, they get discounts and kickbacks)
I guess maybe i insulted some CCNA or MCSE-ers
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.
Also, the question is, is the ability to write a BFS on a whiteboard a useful way to screen programming candidates for most positions. No it is not.
Next to arrays and lists, trees are such fundamental part of computer programming that I can't find an excuse for not being aware of some basic operations. I am not suggesting here that the RB or AVL trees and all the tricky stuff about them should be your bed time reading, but a certain baseline should be established.
Could I have dug up a library to do what I needed, sure I guess. Easier to take 20 minutes and just write the tool.
What? That would be a huge red flag in my book. Where are your unit tests? I'm not trusting your 20 minute off the cuff reproduction of classic algorithms in any business critical piece of the code, not ever.
This would get you booted from a lot of places, or at least given a stern talking to for doing something that seems slick, cool, and time-saving in the short term (yay, let's roll our own!) when really it's immature and time-wasting in the long run.
Never (!) homebrew that shit unless you have to (like, you're in an embedded environment or your use case requires some bleeding edge research algorithm).
It's like seeing someone write their own argument-parsing code. Holy shit, what a bad idea. Never (!) do that.
https://en.wikipedia.org/wiki/Breadth-first_search
Correct arg parsing is actually significantly more complicated in comparison because of all the possibilities and edge cases.
> Never (!) homebrew that shit unless you have to (like, you're in an embedded environment or your use case requires some bleeding edge research algorithm).
I can't help but think this mentality is what lead to the recent left-pad debacle
So we did that. works well. I dunno, maybe this company is just full of incompetents. I mean, I doubt it, but it is possible.
I appreciate judgement without context as well. Really, it's awesome.
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
Instead, the PM might say "We need a system which can count how many unique events of each type has occurred in the last 100k requests, with small impact to time, high accuracy, and up to 100mb of space"
But even that would be unusually specific. It would usually be: "the service breaks sometimes, can you figure it out?" And then the engineers figure out that it's because of unusual event distributions, and they figure out what needs to be done, how much space / time they can afford to do it, etc. For instance, do you trade off accuracy by having a periodic job flush old events out of the map? Do you quantize by time to save space at the cost of resolution?
That's what I do at my job, and that's the kind of question I see in interviews. If a candidate is expecting to have the algorithms dictated to them, then I would not consider them to be a software engineer.. coding up a program from a specification would have been a technician's job 30 years ago (now largely automated by compilers, synthesizers (for HDLs), and other tools). The software engineer should be coming up with solutions, which often involve using algorithms and data structures.
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 I were ever to want to traverse something in a breadth first search manner, then I would just write it. It would take longer to search for another library and read how it's somehow implemented this search than it would to write it, test it, get it reviewed, and we've still avoided adding another potentially crappy dependency to our project.
It's not category error to compare this to leftpad. leftpad actually makes more sense imo, as it's a common microfunction that may be used more than once. BFS is typically far more coupled with the underlying data and is more naturally written inline.
No, you've just added the crappy dependency == your off the cuff implementation (which is even more work since you have to handle issues and unit testing for it too).
> What the hell sort of library would you crack out to do a breadth first search traversal?
In Python I would use networkx probably, unless there was a good reason I couldn't (such as working in an embedded environment where I couldn't install large libraries). It ought to require an exceptional circumstance to stoop to implementing it myself.
Tell me, if we switched from talking about breadth first search to, say, inverting a matrix with Gaussian elimination and pivoting, do you feel the same? Are you going to trust your implementation over something you can get from netlib?
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.
Don't you have release deadlines, even if they're measured in weeks?
Depending on the complexity of the problem, I've been expected to produce code. That tends to be tricky and I don't always get it 100%, but I've not finished my code and gotten just the general direction, and still passed (received the offer).
> you'll be rejecting many fine candidates using that method.
I could see that being true. Without knowing what kind of company you work at I wouldn't know. Since I work in a big tech company who interviews in this fashion, all my coworkers who I'd consider fine candidates have passed this (partly arbitrary) bar.
It's not something I was good at, but I decided that I wanted to work at a big tech company, so I decided to play the interview game.
In this case, someone who didn't have the time to visualise exactly how the bfs is operating shouldn't be writing the algorithm. Pretending like you don't need to know the details of how it traverses the tree when you needed to choose the specific implementation for this algorithm to be performant is a lie. It's not like Guassian elimination, where the concept is far more abstract, this is a concrete idea of how you're moving through the graph and shouldn't be some black magic.
On top of this, who writes this code and doesn't test that it does what you expected it to do on sample data. If you bfs implementation was bust, then you'd miss nodes or revisit them, which becomes immediately apparent from testing the algorithm you're writing.
> It ought to require an exceptional circumstance to stoop to implementing it myself.
Maybe the problem here is that I see a bfs as a fundamentally simple algorithm. Saying writing it yourself must be an exceptional circumstance sounds about as crazy to me as saying no-one should ever use for loops, they expose you to making mistakes with an index you may forget is zero-based, please use anonymous iterators instead. When something takes 5m to write, is heavily tested by default (as it will be a feature under test anyway and possible flaws will be highly obvious) and is at the same level of abstraction as the code you'll be writing around it, then just write the damn thing.
EDIT - Try writing a BFS that operates on an acyclic graph that outputs the value of each node, that compiles and runs and prints at least two node values that has a bug. Try writing bugs into this, it's actually difficult to screw up.
Yes, this kind of hubris is often the root of the problem when so-called 'simple' algorithms get homebrewed, then later on unexpected corner cases pop up, testing isn't adequate, you didn't implement it in an extensible way, your implementation is unacceptably inefficient, etc. etc.
> On top of this, who writes this code and doesn't test that it does what you expected it to do on sample data. If you bfs implementation was bust, then you'd miss nodes or revisit them, which becomes immediately apparent from testing the algorithm you're writing.
Yes, but the point is that testing isn't free. If you commit to writing your own implementation of something to interface with whatever larger business / domain-specific project created the need for it in the first place, then you have to dedicate not just the time to write it, but also the time to test it, and to test how it integrates, and to maintain the API for it and maintain its integration (possibly backward compatibility, etc. etc.)
If you adopt a standard to use a certain library, then up to the degree to which you trust the library, those problems are mostly offloaded to others. For things like classical algorithms, the libraries are extremely trustworthy, so many of the pitfalls of adding a dependency don't apply.
> In this case, someone who didn't have the time to visualise exactly how the bfs is operating shouldn't be writing the algorithm.
It's not about being too pressed for time. Even if you had all day, it's a poor use of time to create more future work for yourself by yoking yourself to all the extra responsibilities that come along with rolling your own. Yoking yourself to those responsibilities should require an exception reason for doing so.
> Saying writing it yourself must be an exceptional circumstance sounds about as crazy to me as saying no-one should ever use for loops, they expose you to making mistakes with an index you may forget is zero-based, please use anonymous iterators instead.
This is an extremely fallacious comparison. Basic control structure are built in features of the language. You don't have to test or maintain the runtime execution of a for loop, that's the job of language designers. Making mistakes in the usage of something (like an off-by-one index) is completely non sequitur to this entire discussion. I don't see how you would think that type of bug is related to anything I'm saying.
In general, you also assume a much higher fidelity of testing than what happens in the real world. In 99% of software jobs, you'll be extremely lucky if someone even documents their homemade BFS algorithm, let alone writing even the most superficial of tests. Expecting them to give you an adequate bank of automated tests is like believing in the Easter Bunny.
> Try writing bugs into this, it's actually difficult to screw up.
Ugh.