Destroy all hiring processes
b-list.org
b-list.org
When I'm giving interviews I really like it when a candidate posed with a fairly complicated problem or design question pauses and actually thinks, then says something like "..well, I don't really know, I'd probably want to think about it more, but here's an idea" before putting forward their likely non-optimal but totally plausible and on-the-right-track design or solution that they thought of on the spot.
Under-confidence in an answer (straight up asking for validation i.e. is this right?) or over-confidence (expecting to shoot straight from the hip with the perfect, 'right' solution, or just a plain old bullshitter implicitly insisting that anything they say is correct) are usually red flags for an extreme personality type - always exceptions to this but as a general rule, I've found it to be true - and the happy middle ground, coupled with answers that obviously point towards a depth of knowledge and skill, is what you're looking for.
Trying to follow my own advice, I've done this myself as well when I'm the interviewee. Side benefit - if the interviewer actually is looking for a 'right answer' to complex questions out of the blue and on the spot - good for them if that's what they want but I'd want to self-select myself out of that type of expectation and working relationship. So everybody wins.
This hypersensitivity goes in both directions. One company may be worse than another at hiring, despite having an equal or better engineering department. Sometimes, you might just get bad luck. Your interviewer might not have had their coffee that day. Or their dog may have just died. Or you may get a guy who just proposed to his now-wife and is having the best day of his life. Giving a reasonable benefit-of-doubt mixed with a bit of critical thinking is probably the way to go, rather than resorting to hard and fast rules that will end up just making you conclude no company is good enough for you.
I don't understand this. As far as I can see, the entire goal of hiring is to have good workers, so the company with a better engineering department is better, by definition, at hiring engineers.
It might be that their hiring prowess comes in part (or in whole) from factors largely outside the hiring process specifically, something like "you get to work for Elon Musk", but their hiring is still better.
The only way to determine your false negative rate is to hire a bunch of "shouldn't hire"s and see how they work out.
Easy hire, easy fire is inhumane to people who believe that once you get one job somewhere your problems are over. Never-hire-because-we-never-want-to-fire is inhumane to people who interview poorly and do good work -- they're humans too. You can't win them all.
So, again. "It depends".
My project was a regex matcher. I ended up getting the following feedback:
> We thought you wrote a great, very full featured regular expression matcher. It was especially impressive how much you dug into the academics behind regular languages.
> However we made the decision because we felt that while going through the project together during the interview, we didn't see the fluency of programming when adding to it that we had hoped for. While we specifically designed the take home project track to help overcome the difficulties of coding under time pressure with someone watching, we do still need to see a certain level of programming during the interview. This didn't seem to be the case here.
It's hard to know what to do with that. :/
That seems quite a bit more representative of regular work than a pop quiz. Yes, you still need to be able to talk live about code with other developers. That's unchanged and shouldn't change, IMO.
I get that they and every other business wants to find a team of wunderkinds that can plug right into their repo and get to work. That's the ideal.
My advice - don't sweat it.
That's exactly why it pays to prepare for coding interviews. If companies are not going to be thoughtful about interviewing, candidates can either reject those companies, or prepare for those interviews. My belief is that if more candidates are professionally prepared with those closed-ended questions, this will eventually force companies to be more thoughtful.
I get this a lot, but it is amazingly self-inflicted. Almost all of the random job offers i seem to be getting from people i don't know are from clients who:
- underpay
- demand on-site only
- don't even look at the copious provided code samples, only at the CV
The reason for that is simple: A lot of companies view developers as identical to factory workers. There is nothing more to it.
--
Sadly i think this is not something that writing blog posts about can possibly help. The people making these mistakes when looking for developers make them because they are ignorant and do not care enough to gather the required knowledge. Until they realize their "illiteracy" and wish to fix it themselves, the scale of this education problem makes it unassailable.
I've also gotten a few speculative recruiters who are just obviously going off a list of auto-slurped email addresses from GitHub and not taking the time to match up positions to skills (including one person who very persistently wanted me to look into a job writing C++ all day).
And on the flip side I've applied speculatively to a few smaller shops that looked like they were doing interesting stuff, only to get the "we think you're overqualified and can't afford you" reply.
The companies making the most demands usually offer the least. My favorite new flavor is recruiters saying "well for remote the pay rate is lower" to which I answer, "will I be doing less work in that case?".
When you couple that with the higher productivity of remote work, the smart employer will let me work remotely (at least most of the time.)
Yet I get the same algo/ds puzzle questions that you should've solved before in order to solve it in an interview setup. Google reached to me and said based on my profile I can skip the phone interview but I'm so afraid of the interview that I postponed it multiple times.
I'm fine with algorithm questions only if I'm solving it in the same setup as my actual work where I have access to internet and can write some quick programs to test my ideas. I was good at solving pretty much any problem I had in my actual work. Even if I had to read a paper on the topic or learn about a new concept from ground up.
Google asks questions like pots of gold[1] where it's really impossible to solve it on a whiteboard if it's your first time seeing the problem.
I'm on hiring side of equation also. I get it, it's really hard to judge people. Even when the candidate have a GitHub page. I got a candidate from Hack Reactor where he had tons of contributions. But when I looked closely at those contributions they were mostly fake. Some other candidate had exactly same codebase in their GitHub.
I've seen tens if not more people from my unknown middle EU university nail the interviews, ending up with jobs at Google, Facebook, Microsoft etc. and I've cooperated with some of them, knowing that their programming skills and knowledge, teamwork are lacking. But they can solve some simple dynamic programming problems, or maybe a silly breadth-first-search, and they'll get the job.
I, personally, wouldn't like to be hired at a firm that evaluates me that ridiculously. Yes, I'm a fresh graduate but thinking that knowing Dijkstra's algorithm evaluates my abilities makes me believe the whole culture is entirely deformed and I do not want to be fascinated by these ridiculous puzzles when I'm working with others.
Give them a week to implement something of larger complexity and they are drowned by so many concepts they decided to skip to earn an internship/full-time position at their beloved giants.
But I guess giants can afford having engineers that aren't that productive, or aren't doing projects that matter. I wouldn't like to be one of these engineers.
So, the real question is do you want that, or is the cash blinding you? :D
Books like these below can increase your chances significantly:
http://www.amazon.com/Elements-Programming-Interviews-Inside...
http://www.amazon.com/Competitive-Programming-3rd-Steven-Hal...
http://www.amazon.com/Cracking-Coding-Interview-6th-Edition/...
Ok, so here is an anecdotal sample. I have not seen this problem before.
After reading the problem description I tried one round of the game on the paper (actually in the text editor) to get the feeling of the game play and then it took me about few minutes to come up with one possible solution and then after a little bit of thinking with a more optimal one.
So not impossible (but I was in comfort of my home).
I actually think that this is a rather classical CS problem that does not require some thinking about more abstract mathematical corner cases.
I give an example of the later one.
You have an array or numbers [1 - n], that is not sorted. One of the numbers got changed to 0. Given an array after the change return the changed number in linear time.
Assume the some array but two of the numbers got changed to 0. Given an array after the change return the changed numbers in linear time.
But there is a catch that is very likely not obvious here. All the numbers in the array are (were) unique (and the zero was not present).
Some information is actually missing/not obvious and interviewers may actually evaluate your reaction to this situation because this would also model (to some degree) a real life situation.
So I added the missing bits (and fixed typos).
You have an array size of n of integers from 1 to n, that is not sorted. There are no duplicate numbers in this array.
One of the numbers got changed to 0. Given the array after the change return the changed number in linear time and constant space.
Assume the same array but two of the numbers got changed to 0. Given an array after the change return the changed numbers in linear time and constant space.
The first part of this problem should be simple. The second part is more tricky.
What does this even mean? When someone lacks a certain skill, they aren't "bad" in some objective sense, they are misqualified for the job. If someone can't code their way out of a paper bag, should we be hiring them anyway for a programming position because they're not "bad"? What's the point of the interview in the first place? I don't understand the argument.
To the other points, I completely agree there are many ways to screw up interviews and few ways to get them right. I'm still a believer that an interviewer who administers a coding question, one that is reasonably realistic, in both form and the environment the candidate has (ie they have their own laptop) can be a good way to assess someone's skills if you are doing it right. You let them work, let it be a humane environment, and don't get too hung up on the details. Usually if someone can hack it bleeds through pretty clearly, even if they don't get to the exact solution you wanted. (And of course, this is just one data point, that should be distilled into a larger picture of the person's history, accomplishments, etc.)
It just doesn't jive...
>I have a philosophy degree, by the way. Not to be smug about it, but several very good people I know and respect in the software field came to it from that background.
Ahh... now it makes sense...
(and I say this, ironically, as a lifelong opponent of theory-heavy CS programs which churn out people who can derive an answer to your question straight from the Church-Turing thesis but couldn't code it up to save their lives)
I don't think they're equivalent at all.
The truck driver simply never had the opportunity or exposure to programming. He didn't know what it was like and hence couldn't do it.
The theory student did have exposure but was either incapable or uninterested in pursuing it. Even in the most theory-heavy of programs, you program a little. The kids who actually understand and like the programming aspect latch onto it and continue to learn and grow, ending up employable. The kids who, having been exposed to programming and realized that it's not for them, never learn any more and continue to flail around in masters programs teaching mathematics in the guise of CS.
I studied (and helped with labs a few times) two of these. Mathematics and theory was fine, but the rest not. Weird, I wouldn't have believed it was possible after years of university, if I hadn't seen it.
One became a teacher, I don't know about the other. He might have become a quite good entrepreneur. Seriously.
The point is, it is possible one of these are the next person with a theory heavy background you interview... (But ok, we all know that too well even with little experience of hiring. :-( )
At my current company, we don't do any phone-coding or whiteboard-coding, for which I am very thankful (for the reasons the article laid out).
We do do a take-home dev test (4-6 hours). This has the benefits of being low-pressure, repeatable, and similar to the real work we do. It has the tradeoff that we might miss out of great devs who don't have the time to do it. We're working on shortening it to offset that.
We also do a bit of paired programming on-site (using the candidates computer and dev environment of choice). This has a distinct tradeoff, since it can be a bit high-pressure. We try to do everything we can to ease candidates, but I haven't found anything else that works well for getting a feel for what it's like to work with someone in a technical capacity.
Every interviewing technique has issues, and I think phone and whiteboard coding are among the worst still actively used (now that brainteasers are mostly dead). I think what we have is the least-bad, but we're still iterating on it (and hopefully always will be).
I get the overall rant. I understand the frustrations - but this is wrong-headed. If you can't see the value of understanding algorithms - learning both how to write them and how to evaluate them (including proving their correctness), then you've misunderstood computer science education altogether. Nevermind all the rest of CS, which encompasses far more than just "names of algorithms".
Though to be honest, for a lot of what I do my working set in memory (metaphorically) involves very very little algorithms/data-structures stuff and a lot more quirks of libraries/frameworks/protocols stuff. When I need the algorithms and data structures, I pick up the reference I keep on my desk and look up the thing I'm thinking about to double-check that I'm using the right approach.
A big part of the problem is over-generalization. Here's a reddit comment I posted in a similar discussion not too long ago, touching on that:
https://www.reddit.com/r/Python/comments/3nfbkr/patreon_is_a...
The person I was replying to there had made the mistake of assuming that because in these fields of programming, knowledge of data structures, algorithms and big-O characteristics is one of the most important things for performance, that must be true of all fields. When, in fact, it's not true of all fields, and I provided an example of one where it isn't true and where quizzing someone on their big-O cheat sheet wouldn't actually reveal whether the candidate has the most relevant knowledge for what's going on.
One company I talked to was like a caricature of the bad startup interview: we have a billionaire founder, we have wine on tap, a totally disorganized 4-hour series of discussions where the first person just sat down and started quizzing me with hardly an introduction, and I had to ask the second interviewer how many people I'd be talking to, technical questions ranging from the simple to somewhat difficult (using paper and pencil), with less and less time for each because they couldn't follow their own schedule, followed by an interview with an arrogant, hypercaffeinated CTO, consisting of two brain teaser questions and a series of elevator pitches, all in a tiny glass room near the back storage area, devoid of oxygen. And the following week I found out, sorry, they'd cut funding for the position the day before I came in.
Do you give them a week off in lieu if they get the job?
Weebly has an unlimited vacation policy, so, it worked out pretty well.
Also, from the Weebly end of things, what if you know a couple days in that the candidate isn't going to work out? Cut them off right then or finish out the week?
So, how does a trial week work for candidates committed to another job? If anything, it seems to self-select for part-time or remote workers that are already in a position with time on their hands. The best I know don't fit into that category: you'd miss them.
So, the question is: "Should employers put this kind of burden on every candidate or try a method which demonstrates skill with less time?" I push for the latter.
Contract-to-hire at least gives you a couple months of fairly sure income.
A full week is pretty close to insane. It means that application is effectively limited to the currently unemployed (or those who are willing to burn what might be all the vacation they can take for months).
That said, it does make pretty clear that Weebly doesn't give a single shit about employee's lives; so it's kind of Weebly to make clear, right out of the gate that they expect to be the only thing that matters in your life.
Likely, the decision was already made by you being willing to risk the week of vacation and put in the effort to get hired, while they showed a similar regard.
You might be able to get away with 1 or 2 of these things a year... but it's a REALLY good way to burn bridges.
As I see it, there are 2 huge barriers to me ever doing a trial week while currently employed:
1. If it doesn't work out, I've just burned 1/4 of my vacation time for the year. That's a pretty massive ask for a company to make. I could do a bunch of math with expected values, but I'm sure it would work out to Weebly having to have insanely great compensation (>$300k) for me to do it.
2. Even if it does work out with Weebly, it makes it impossible for me to concurrently solicit and evaluate multiple offers, which I absolutely do when looking for a new position.
How do you overcome those problems which make it very unlikely that 99% of employed developers will do your process?
Of course, it could also be that this is a brilliantly designed strategy for weeding out expensive employees by focusing on the unemployed and unsavvy.
This is the result, intended or not.
The problem is, the good people usually don't need a job. So the more of a gauntlet you make your hiring process, the less likely it is you'll get one of those already-employed, perfectly happen and great employees. You're selecting the people who couldn't get jobs at your competitors (modulo the false-negative rejects).
Didn't end up working out so I was glad it was only part time and I didn't make the jump. If I made the jump directly, I likely wouod have been laid off and unemployed.
Do you measure the performance of people hired through that method, and have you done so for a long period with a significant sample size? Do you manage to measure your false-negative rate (by somehow following up on candidates you passed on)?
Also reminds me of a comment by Robert Townsend. Which is a warning about following the practices of the biggest most illustrious firms. In his day that was General Motors etc. Today it's Apply and Google. I think those guys can spend a buttload of time and money looking for the perfect fit out of the line out the door of candidates because, it matters. Bad/Good hire could cost or make the company millions of dollars. It's also hard fire when your company is large.
Your dinky company? A misperfect fit is going to cost you thousands to tens of dollars.
How does nationality, gender, race, age, and income level have _anything_ to do with this at all?
In other words, even on the easiest default approach (recruiting from people similar to ourselves), we suck. God help us as we try to recruit from people dissimilar to ourselves.
I saw a summary of a study recently in which people were asked to rate top character indicators of success for male and female candidates for a job, things like "aggressive," "nurturing," "outspoken," "mediator." Not surprisingly, the adjective sets for male and female candidates were substantially different.
A good Software engineer can design a program or system and not even have to know the programming language, they understand software and how it should work. I have on many occasions told our SQL coders/programmers where problems are and how to fix them without ever having programmed in SQL.
The key is the Software Engineer understands the fundamentals of the system as an engineer and understand how everything goes together and should work. For example, if you are designing a business system, you engineers understand how the business works and how the program can help it. The coders know how to implement the design but not the why's.
If you are hiring outside vendors then it is even worse. They are coders that know nothing about your business or your project or what you are trying to do but they do know how to code something, let you try it, have you change it and try it again and change it again and try it again an...you get the picture. If you hire a software engineer that understands software and learns your business, they can develop design documents that can then direct your vendor. This creates a better product the first time and at a lower cost.
The schools today are creating more and more programmers and fewer Software Engineers.
Any yay-or-nay judgements based on hastily-written program output should be taken with a grain of salt by both parties.
You have 5 interviewers going through the same candidate? Fine, they need to be one-fifth omnipotent.
Good luck with that.
I've also found it strange that it didn't matter what my degree was in, just having one wold have secured me interviews. A theoretical degree in Turfgrass Science would have benefited equally as a proper degree in CompSci.
Meanwhile, I do go into some detail about the issues with coding interviews in general, and the way they can affect and accidentally weed out candidates a company probably didn't want to weed out that way.
Also, the "nobody can really code, you have to do this to filter them" thing is approaching cargo-cult status at this point. Further up in the section on education I touched on some reasons why I think those situations happen.
Having said that, I actually agree with him because I've learned that it's not always simple as who can't write code. I would much rather assess a candidates' ability to learn (sharpness) than the current skill-set.