https://news.ycombinator.com/item?id=5730843
I want a company that treats me with dignity and respect, even before and during the interviewing pipeline. How a company treats people during interviews is a huge indicator of how they treat people in general. I would never subject my friends or family to the hiring practices that programmers are exposed to regularly. Be proud about how you hire. Otherwise this weighs heavily when I reject your offer.
I want a "1-hour guarantee" that I'll receive your considered offer after one hour of interviewing, and not multiple hours of hazing. Otherwise, I'll stick with consulting, thanks. Maybe there should be a site that compares the interviewing pipelines of different companies, and then you can focus on the ones that aren't entirely offensive.
Also, it would be awesome if one of you would actually look at my git repositories before the interview and, you know, actually read my code. No, looking at a "repository summary" doesn't count.
Standing in a room for a few hours writing on a wall is not exactly hazing; to say it is reeks of entitlement, especially when many software engineering jobs have a public trust: safety, privacy, reliability, and correctness standards that demand a certain level of rigor. Software engineering is a very hot field right now, and developers are in demand--but that doesn't mean you should turn up your nose at companies that maintain their own stringent standards of hiring.
For example, the company for which I work bills me out at $250 / hr. I get something like 15-30 job requests from other companies a week. It would not make any economic sense for me to pursue any of these other companies unless the interview process was dead simple, transparent, and easy (and the total compensation was _at least_ 15% higher than my current compensation). But, 99% of them will only offer modest pay adjustment (%2-3?), and then they expect me to sit through several hours of interviews. And, if I pass that nontransparent process, they ask me to sign a ridiculous employment agreement that signs away all my personal IP. Seriously?
The problem with recruiting today is that most companies who have good talent understand how valuable their best talent is. They treat them very well. And, the companies that want to obtain that talent completely under-offer their side of the deal.
Another problem is that most developers suck at negotiation. I see lots of anger on HN about not getting the 6-figure salary. Well, that's their fault for not asking for it. If they're a relatively good developer (top 25%), they should be making at least 6-figure, easy. And, if they're not, that's their fault, not the fault of others that know their value and how to demand a cut of it.
Not that I would suggest replicating it mind you. The interviews are simple because they're literally just screening for people who can't have a converstaion about the weather. 95% of the substantive decision is just looking at the rank of your school and then your GPA. 90% of the candidate pool is excluded by arbitrary cutoffs from the get go. Which is an awful way to hire.
While I agree that the premed curriculum and med school are rigorous, attrition rates in engineering are very high. It's tough to get into med school, but it's tough to major in CS or engineering, and getting into a top grad school in engineering is very selective. Attrition rates at top med schools are typically below 1%. In engineering PhD programs, attrition rates are above 35%.
...I wouldn't have hired many of my fellow engineers after an hour. I would at least want two interviews, one with me (the line manager), and one with my team.
To flip it the other way round, I don't think I could get a good enough feel for an employer from a single hour. I'm not sure this works for everyone.
I would, however, hire a consultant after an hour's interview. The difference is, at least in the country I live in, is that I can fire the consultant with almost no notice, whereas a FTE is more of an investment.
Aaaand tokenadult is submitting his "best hiring strategies" mega-comment supported by Schmidt & Hunter reference in 3...2...1
/I've been here too long perhaps
;-)
* It lasted 3 hours, not all day. They suggested business casual dress.
* No trick questions or trivia puzzles. Just coding on whiteboard.
* The interviewers had clearly looked at the work I'd been doing (no one asked "what do you do currently," etc.
* I had an offer, with numbers, about 50 minutes after the interview.
* I countered, they took less than 24 hours to respond and accept.
It was really enjoyable.
actually, this I find is the biggest annoyance of all. Every company I've interviewed with over the last few years has said "show us your github".....so far, not one has actually looked at it. It's kind of like walking into an interview with a company that has a web-presence and saying "so, what line of business are you in?".
I fully agree. I think a possible fix is to publicly share the experiences people have when interacting with HR. If this is done centrally, perhaps the industry will take notice and improve.
Most companies ask programmers to come in, solve some problems on the board, and then pay them a generous salary if they succeed at it. How is this in any way "broken"?
A casting couch is an example of "broken" and corrupt hiring, we have nothing of the sort.
For starters, because those "problems" are usually unrelated to what we actually do.
And here's the kicker: none of this truly indicates if you have an exceptional software developer on your hands or not. I've seen (read: personally interviewed) people who've aced the current, en vogue style of questioning who turned out to be awful developers and co-workers. Meanwhile, I know several excellent engineers who were rejected. Everyone knows the process only kind of works.
SV loves to complain about a talent shortage. And maybe there are pipeline problems that need to be addressed. However, why not invest more time in finding a process that's more effective with the talent that's already out there? It always seemed like an obvious place to start, IMO.
Nailed it.
Another interesting thing I noticed about myself in technical interviews is that I have a lot of trouble doing things that I would have no trouble with if I'm tutoring someone. Perhaps it's the anxiety, and practice will surely help, but see above, I'd rather spend my time tinkering with stuff than preparing for interviews.
If we're talking about raw programming skill, I would say that actually learning these fancy algorithms will pay off more than (random) tinkering. It's the difference between directed and undirected practice. Undirected practice only takes you so far. To truly get good at something one must do deliberate, directed practice consistently.
1. Master algorithms.
2. Get a job at <insert a big famous web company>.
3. ???
4. Get rich.
Really if you are joining a big company. Whatever that company is. Way to financial safety is not mastering algorithms and data structures. Its more like knowing how to do politics, being your manager yes men etc.
And very rarely are you ever going to get some work where its going to demand some algorithms mastery.
I mean for me that's no problem, but I don't live in the US and therefore have pretty liberal employee leave arrangements. I know that many companies in the US are a lot harder on giving out leave. That said, it wouldn't surprise me if this issue is minimised in the tech sector with their progressive business approaches.
Is your stack that simple that someone can get up to speed on it in a few minutes so that they can actually build out a feature in two days? Most places I've worked, requires significant onboarding to setup dev machines with all the environments and then understanding how the code flows.
Ethically, I would never be able to interview for your company. Don't most companies like tech companies operate in a similar manner? If so, aren't you limiting your hiring pool to either programmers without those types of agreements or thise whom are ethically challenged.
Obvious note: Many jobs _don't_ require those skills, they're simply cargo-culting their interview questions.
In both cases, you've learned something valuable about the potential employer.
I'd say that you get to be an engineer if the "Engineer" is printed somewhere on your diploma.
Unless you drive trains.
"disrupt!"
"only the beginning"
"ninja"
"agile"
"seamless"
"social media"
Who cares if you don't know the intricacies of all the hot algorithms of the day. Spend your time creating actual value for the world, instead of practicing just for the sake of impressing someone.
Probably not going to be your first choice if what you want is a small, dynamic, startup atmosphere, but as an employer I wouldn't fault them.
(yes, ex-employee)
Their corporate culture has changed a bit in the past few decades.
I do agree that one should not participate in the idiotic way programmers are currently being recruited by some companies. But that doesn't mean there aren't good, BS free jobs out there. Jobs that are full-fulling and economically adequate. Not everyone aims to be on the cover of Forbes. Some people just want to program, and go home with the family. Oh, and fish on the weekends. That's a perfectly good life to aim for. Better than what the rest of the world may have.
I hate to see talented people wasting their time preparing for these interviews. The opportunity cost is too high. These current hiring practices are robbing the world of great software–code that will never exist because the time was instead spent on superfluous interview tasks.
And ofcourse sales, marketing etc and all that comes a part of doing a start up.
If nothing else, following the advice here will help you hire better engineers for your own startup.
Most true startups are in need of developers who can actually ship something of value in an efficient manner. The last thing they need is an "engineer" obsessed with algorithms and data structures who turns a practical development task into a computer science challenge.
I'm really curious as to how you landed an interview at Google (let alone a job) without a college degree. My understanding is they are very strict about that and it's hard to even get a foot in the door without a degree.
[disclosure: I'm on a 10 year "hiatus" from my senior year in college]
Steve Yegge wrote that you should apply to Google, no matter whether you think they'll take you or not, because it's a desirable position and the cost of failing is low. I spent $200 on a hotel room (not reimbursable), $150 on transportation from and to the airport (not reimbursable), $50 on baggage fees (reimbursable), and two days of my salary (since I wasn't at work when interviewing) (not reimbursable) in order to apply. This could be described as "significant".
I also washed out, but it was pretty enjoyable. I certainly wouldn't describe it as a hazing.
Nowadays, showing a body of work speaks volumes. Show, don't tell!
Regarding the C++ self-assessment, it depends to whom your talking to. If it is a 10+ years of exp. hard core C++ programmer, then your point is right. But if it is some recruiter clerk - who just writes down your answers to compare with other candidates' answers later, then it is 10/10 :)
Another answer could be: "for your company, it is 10/10" depends on the company, of course.
But all in all, I find this score based questions quite stupid. Instead, you should ask for past projects using that particular language.
*
Now regarding your algorithmic part. Tell you honestly, the fact that the candidate implements the Dijkstra's algorithm quickly, because she implemented it twice, 2 weeks before the interview tells me just that - that she implemented it 2 weeks ago, twice....
I'd more value a candidate who have never implemented it, or implemented it 10+ years ago but doesn't remember details - when given the details/specs and a sufficient amount of time, and can implement it.
Overall, I prefer when the candidate can come up with the higher level solutions - knowing when to use e.g. Red-black (or any other balanced) tree, shortest path algorithms, suitable containers - data structures, etc... for some particular problems. The actual (hence 2 weeks ago) knowledge of every specific details of how to implement these is not that important.
(Source: don't have a degree, interviewed at Google)
Having said that, I get paid very little and am generally bored with the work I'm doing now so I'm looking for a new opportunity. I do very well on phone interviews but I'm absolutely terrible at onsite interviews that involve any white board algorithm problems, algorithm optimization questions, etc. This is a combination of low self esteem/intimidation I feel during these interviews. I've done maybe 3 or 4 of these and they've all gone terribly. It's come to the point where I have stopped applying for positions that interest me and that I feel that I would be a great fit for because I know the style of interview that I'll be facing. I've determined that I either need to come up with an idea of my own that I can turn into a steady income or that I need to leave this field and find something else to do.
What do you guys think? Am I just a terrible developer or is it just a matter of practice? Like someone else mentioned above, I try to sit down and practice but get distracted by the fact that I could be building something interesting.
On the other hand, maybe your resistance to the hoops is a warning sign that you should pay attention to if you don't want to end up bored again. Hiring processes like these will tend to select the people who prefer homework problems and tests to actually building things, which might be unlikely to create the kind of environment you'll be happy in.
Have you tried going to meetups and doing some networking? Getting to know people outside of the official channels seems to be a way to short circuit some of this nonsense.
What about consultant / project / contract work? Generally "the hiring process" treats candidates for full time employment relatively poorly and unprofessionally, but treats consultant / contractor types more professionally.
Think about other professions. If you're hiring a plumber's apprentice, its funny to ask them if they know which end of a plunger to hold, and watch then squirm under the pressure. But if you talk to a real genuine licensed and bonded independent master plumber and ask him to demonstrate unclogging a drain before you'll offer a remodeling contract, he'll probably tell you to F off and walk away to a more professional job. You can treat employees like dirt, but not contractors.
Also as others mention, confidence in the interview is something you can develop. Practice. Practice speaking, practice the white-boarding (somehow... maybe record yourself at home with video and watch it), or use the public forums (the meetups). I've taken to recording myself reading the Harvard Sentences, to hear how I sound. Whatever works for you.
Finally, it's just a numbers game, the long game.... It. Takes. Time. The whole process always takes longer than I expect. Keep searching, try to not get emotionally attached to it, because it's such a roller-coaster ride ('I had five rounds of interviews, we had good rapport! .... [two weeks later, after silence: no-go decision]), and lay low in your current job because a paycheck is nice to have in the meanwhile.
At this point I don't bother to apply to corporate jobs, or even to jobs at startups that are larger than a few people, because I know I'll get the same kind of idiotic hazing each and every time. I'll found my own company (there have never been more opportunities than now) or do freelancing for companies that will treat me with respect. In your case, since you sound like you're sharp, I think that freelancing might be a good choice in the short term. You can bring in some bacon while you work on product ideas, do some networking, and find partners.
You sound like a good developer and the problems that you have with these interviews (which I share) are no reflection on that fact. This may sound a bit odd -- but do keep an open mind about leaving the field. There's a lot of interesting work out there in the world, some of it creative even. Software geeks tend to live in this very narrow, ant-farm-like world, have a hard time seeing outside of its walls, and assume that beyond the glass is a land that can only offer just drudgery and pain, which is simply not true. Best of luck.
If white board algorithm problems terrify you, the only thing that will help is practice. Take the opportunity to try to discuss different solutions with colleagues at work. Or, if you can't do it at work, try to get a couple of friends together and just take turns presenting and asking questions. Yeah, you won't get the adversarial atmosphere that way, but you will get used to the setting.
They all look imperative to me, what happened to multi-paradigm?
Can you name me an OO language which doesn't support imperative programming?
If I had an 80% success rate, but was 18 for 20 I'd score 117. To get that, I'd need to be changing jobs every single year.
The score is not only totally made up but pointless and adds nothing to the rest of the article. It's just there to suck you into the article.
Anyway, I think the author is assuming that each time you apply, you're applying for multiple jobs, getting multiple offers, and turning down all but the best one. I was a little surprised that my score was so low, too, given that (as a junior) I've only had 2 on-site interviews but have received 4 offers, which gives me a score of 60. Meanwhile, interviewing for 100 jobs and getting 60 offers gets you a score of 120.
And for x > 1, which base you use matters. E.g. if x == y == 2,
>>> from math import log,e
>>> 100 * log(2,2)
100.0
>>> 100 * log(2,e)
69.31471805599453
>>> 100 * log(2,10)
30.102999566398115
The expectation is that if you're smart enough you can reason to a more optimal solution even if you haven't seen a trie in 15 years.
But I will say, as never having used a graph search like Dijkstra's in any of my work, the idea of studying this to take a hiring test still goes with my theory of learning something by rote. If someday I need to implement the concept, or use it, I'm sure I'll go figure it out. I had to do this awhile ago with a Levenshtein distance for computing similar string matching. Had someone asked me in an interview, I'd have completely failed at it.
I've never memorized any of these algorithms, but I can code them up pretty easily given the specification. If you can do this it doesn't matter how many years you've been out of college.
Re-invent the wheel.
You should implement the most common data structures
in your language of choice. [...]
Performance does mean the most many times in this field for the AAA games out there, but not for most games. In web or app development if you are using custom data structures instead of native, in most cases that is wrong. How about consistent data structures that have been built and tested outside the company? The thing is though when the programmer that makes your 5th string class and data structures moves on it will be rehashed by the next, as other developers won't be as effective with them and recreate.
It is much more important to understand what data structures to use when and what impact they have on performance. Most of all can the developer ship and understand what is best for the product (not the ego or what will make them look like the hardest programmer of all time -- i.e. Rewriting the string class again and it is 10% faster, even though that is not a problem at all). I have seen some horrible, leaky, buggy data structures in situations like this, because they thought that was the job as led on by the interviewing. I have only really seen this while working in the game industry which I love but it is a problem with shipping product when this bike shedding happens over improvements to the game, engine or real custom needs i.e. the UI libs, event/messaging systems, naming/conventions are typically horrible in situations like this.
I also blame consoles for many of these problems as the libs are so jacked, incomplete and old that performance becomes a huge issue and you have to have custom structures just to use the hardware right especially in graphics, physics + networking libs. Yet mobile I have seen less of this problem even though there is less hardware to work with. The next time you play a game and the networking totally sucks, or a game takes forever or simply doesn't ship, understand the culture of the company and the industry might have something to do with it.
That's fine if you only want the unemployed and new graduates - how well do you suppose it works out for people with full time jobs?
Which is kind of what many people in this thread are saying when they say they don't want to work for a company stupid enough to use algorithms and data structures questions as their main interview method.
The arguments against coding interviews seem weak, to me. They appear to be rationalizations for not getting the job--an insult to the ego that must be rectified by bending reality. They essentially boil down to, "I shouldn't have to sweat these details; they're beneath me." But all of the greats sweat the small stuff, almost obsessively, and pay their dues.
For the vast majority of mindless coding jobs out there, you don't need to hit the high notes. But when you're moving the state of the art forward--indeed, civilization forward, inventing what has not been invented before--you need complete mastery. If you just want to build stuff, on the other hand, these skills are unnecessary. But that's not engineering. That's construction work, for construction workers.
Step 1) Send the candidate a small unattended coding test they can do in a couple of hours. If they pass great if they dont offer them feedback.
Step 2) Invite them in for a pair programming test this should take max one hour, they can spend 15-30 minutes with one or two people on the team solving a problem.
You wouldn't believe the amount of people who have amazing looking CV's but when it comes to actually coding they just are not up to scratch.
There is also obviously personality fit and other subtleties but thats the basics.
I've only personally encountered it once, but if you ask someone to spend a few hours of their free time on your coding challenge you absolutely owe it them to give them feedback, even if you don't like what they've produced.
According to the formula at the top, my value is 0.
I understand that, when you're learning algorithms and such, that there's no substitute for implementing them, to learn them. But when someone with several years of development experience comes in, with a portfolio to show, why waste their time?
I think there's an alternative, and it fits into your ABC. Build useful software. If you've got an idea, implement it, and if possible, open-source it. In the process, you'll likely rely on a bunch of open source software, and maybe you'll run into some limitations. Every limitation is an invitation for <i>you</i> to contribute. And if you can build a bit of a track record, instead of proving yourself with textbook algorithms, you can do by showing your portfolio of actually code.
I assume it's because they're busy "filtering" through hundreds of candidates and don't have the time to read the thousands of lines of code I've written.
"Spend at least 40 hours coding solutions to different types of problems. One of the best resources is TopCoder. Read this. Then try solving problems."
Did you mean to link to the top coder algorithm tutorials?
Now that I'm older and have a job I like I usually pop out a really high salary number as early in the process as possible to scare away any companies that would take a lot of work to interview with and then not be able to afford me.
So you could have a very low ratio of offers for reasons other than your interview performance. :)
But your'e right, the ratio doesn't mean anything. ;)
You are not also guaranteeing a position where you'll actually code something or help develop something if you happened to get the job.
If you want to code, do agency consulting. Agency brings the work, manages the clients, do the accounting, marketing and the stuff. You code.
Is there a citation for this, or a citation for something similar, or is this just a guess?
If it's actually true, then score++ for people who complain that C++ is too complex.
I'll bet things are different in the startup world, but I've encountered several instances where having a very crude understanding of time complexity served me well. Hashing has been an especially powerful tool in my work, where the size of the data I work with really highlights the difference between an O(n) operation and an O(1) operation.
I would consider the interviewer asking questions about algorithms to be a sort of Fizz Buzz for the more technical positions. Perhaps it is misapplied to be asking technicalities of algorithm questions to people that will be doing more design-oriented work, just as it may be inappropriate to ask your sales force applicants to write programs during their interviews.
That said, most of the interviews I've conducted would not have been able to discriminate well the qualities that I believe make a great programmer. A focus on code longevity, discipline in conducting code review, dedication in writing unit tests, and how they search for information they don't know the answer to are important qualities that a technical interview will largely be unable to see.
I find that always coding mantra is just one version of a method that applies to many other disciplines.