I understand that folks have to do what they need to do to stay employed, so opting out isn't possible for everyone, but this is pure insanity.
For those of you who are early in your career, be sure to keep trying new things out every so often. It's really easy to get trapped because it sneaks up on you; you shouldn't be trying something new every week, because you need some depth, but if you've gone a year with nothing new tried, you may be in some trouble.
And be sure your "something new" is a new type of thing, not just a new thing. Learning Python, then PHP, then Ruby, then Perl, is really just learning one thing, maybe 1.5 things. You ought to be learning a dynamic language, then a static one, then maybe SQL, then learning about reliable cloud programming, then perhaps a full functional language, then perhaps go write a GUI with a conventional GUI toolkit, then learn some dynamic front-end Web programming, write a compiler, write a network app starting from sockets, use SSL for something serious, etc. etc. IMHO, the truth is that the programming world doesn't move that fast, but part of the illusion that it does is that it is quite a big bigger than meets the eye at first. It looks like it is moving quickly because there are things that look new to you all the darned time. But under the hood, progress is actually pretty slow.
Do you have any advice for how I can deal with that better?
You should also be aware that hiring requirements are more the wish list of the hiring organization than hard requirements; that is to say, don't "feel bad" about not quite meeting the requirements. If you're close, go ahead and apply. Come in and shine in the interview and only hiring organizations with poor business skills will ignore that you've only got 2 years instead of 3 in Python. (Such exist, though, sadly.)
However, I don't know myself how to deal with people who get too particular. When I'm writing my requirements, generally all my requirements come out as "Blah years of experience in $TECH_WE_USE or similar", and even then I'm really only saying "years of experience" because it's the standard; what I really mean is "a level of skill commensurate with what you'd usually expect after Blah years", but I can only deviate from the standard so far, you know? I don't know what to do about interviewers/organizations who think that 5 years in Perl translates out to 0 years of experience in Python. (All you can really do is comfort yourself in knowing that they're really hurting themselves with such specificity, though.)
If you are not capable of identifying these people without spending hours of staff time and engaging in whiteboarding exercises, something is very wrong in my opinion. The person you're describing will not be able to pass a thoughtful 15 minute phone screen, and that's if a phone screen even happens because this type of candidate probably doesn't make it past a resume review if the person reviewing the resume is qualified.
In the case of a phone screen, I honestly find it hard to believe that folks have so much difficulty believing that it's possible to get a good sense of a candidate's skill and knowledge without sitting over his or her shoulder and watching him or her code. A phone screen is a conversation. In most cases, a candidate who is faking it will have a very hard time describing in technical detail his or her work, and answering technical questions about his or her work.
Start with candidates who have good resumes. Ideally get code samples and/or a portfolio. Prepare for your phone screen so you can ask good questions. It really is that simple.
If you take the time to review a resume thoroughly and ask thoughtful technical questions about a candidate's past work in the phone screen, the phone screen is almost always going to be a painful and embarrassing experience for a lying candidate. And such a candidate will virtually never make it past a reference check.
The problem is that most companies are lazy. Hiring managers don't read resumes closely and wing it (i.e. jump on phone screens without preparing). Reference checks? What are those?
People can memorize the key features of OOP, but still not be able to use it. So do you not hire new grads? Do you never hire someone with an extensive background in C, because you dare not quiz anyone and you don't want to risk hiring someone who can't really ever get a handle on OOP? Are you going to pay the total cost of all these people, who probably won't last 3 months?
What's even sillier is that I bet most people, given the option, would prefer to try solving some small problems for a short period of time if they knew it could help their chances of getting the job. Why wouldn't you if you knew you were competent?
You're right, phone screens usually get them, but not always. A fair number can still make it through.
(1)I hate that coinage as it's no longer a dialog, but a combination of hazing and interrogation.
(2)There's also the meta-issue that if my work life is dedicated to arguments about git and inheritance philosophy, then I needed a new career.
It took me a long time to understand why this happens. I remember going through the interview paces at a small company where I had a specialization I knew was very valuable to them. Instead, it was all technical quizzes, tree traversal, outer joins, swap two integers without creating a third integer, find the long term state probabilities in a markov chain. I remember thinking, wow, yesterday I was doing a demo of a large, mathematically involved supply chain system to clients at a huge manufacturing company, and here I am, getting paraded from room to room, where recent graduates are asking me how to find the least common ancestor of two nodes in a binary tree.
There are a couple of factors going on here. First, a lot of big companies are in a state of constant recruitment, and they aren't really sure they know what they need you for. All they know is that if you can find the least common ancestor for two nodes in a binary tree, adapt merge sort to manage a search where there isn't enough memory to hold all the data at once, and prove that the dual of the primal is the primal of the dual, and you seem normal enough, then they'll have something for you.
The other problem is IP - perhaps they view it as inappropriate to ask too much about what you're working on.
Part of this problem flows from something very wonderful about our industry - we don't stand (too much) on formal credentials. People don't care all that much about how you learned nonlinear optimization or data structures and algorithms. As a result, the barrier to entry is… well, not low, because any entrance exam that requires proving things about convex sets and doing elaborate algorithms at a whiteboard is not a low barrier to entry, but low in the sense that institutions like law schools can't force everyone to go through three years at $45k+ tuition as a legally enforced barrier to entry (like, you'll be put in prison if you try to practice without the three year, $120K+ tuition degree that many people believe is excessive).
The downside is that because software developers don't have a formal system for demonstrating competence in a way that is widely respected by our peers, we essentially have to take our entrance exams over, and over, and over. Actuaries (last I checked, the exams may have changed) have to take a test showing competence in differential equations, vector calculus, and linear algebra, but I don't think that actuaries with 15 years experience are suddenly asked to find the igon values (sorry, couldn't resist) of a matrix or saddle points in a nonlinear optimization problem with non-linear constraints on the spot during an interview. Physicians have to pass boards and exams, yes, but I don't think they're asked questions from their undergraduate organic chemistry midterm every time they interview for a job.
Slowly, I am starting to think that it would help if software developers could, as a profession, take greater control over how competence is established. I've heard others here on HN say that while they aren't in favor of legally required licensing, they would be happy to study and sit a very formal exam if it meant they could finally be done with the whiteboard interview exams, at least for a period of time. I say this while acknowledging real fear of regulatory capture, but what we have now is really, really bad.
I don't think it's really possible to have a meaningful and useful standardized formal exam. The issue is that programming, as a profession, is so wide and diverse that it's really hard to formalize what you're good at.
Furthermore, even if you're quite specialized, a large part of your day-to-day work will still be "general" skills, e.g. debugging stuff, fixing other's bugs, taking care of backwards compatibility and working around system bugs. This requires a general level of knowledge of OSes, languages, implementations, databases, networking, ... At least in my experience, but I assume it's similar even in more specialized areas, like security.
I've been on a few interviews at different silicon valley companies, including Google and Amazon, as well as smaller ones, and the technical screening is remarkably similar. I've noticed it is far more rigorous at some companies than others, but they all more or less test dynamic programming, recursion, trees, lists, hash tables, sorting, and permuting. Even if we all agree that there is no way to have an exam that captures the wide, diverse nature of programming, it could still be useful to have an exam that covers that part that we test over and over and over.
There's one other wrinkle that may not work here - many companies say they do this because they want to see how you tackle a difficult programming problem, how you communicate your solution, and so forth. As a result, they might not be satisfied with an exceptional performance on a similar exam, even if they have high confidence in the board that created the questions and conducted the exam.
Now, all that said, I do consider this to be a really serious problem. Why? Because people who can study for and pass a difficult whiteboard exam on algorithms and combinatorics can pass the actuarial exams, the bar, the medical boards, and so forth. I think that the software industry loses a lot of talent because people don't like the idea of signing up for an industry where they will have to pass their entrance exams over and over, every time they change jobs, and the people who are capable of this have other options. I think this is costing us a lot of talent, it may cause people to favor other fields, and it may cause people to give up and drop out. There are some risks to a formalized test (cartel building is a serious risk, I recognize this, and it worries me - as a math major rather than a CS major, I might be one of the first excluded).
At this point, I don't want to seem like an advocate for this. I'd say I feel ambivalent about it, but that's a change from where I stood on the issue a few years ago. I'm starting to believe that the damage inflicted by what some people believe is "interview hazing" may go very deep. Here's a hint at the extent of the problem...
http://www.fastcompany.com/3043082/most-creative-people/why-...
"Hall asked a simple question: Why didn't Chipps, a brilliant engineer, ever apply to work at Fog Creek? Chipps said she didn't think she would make it through their rigorous testing process."
One last thing - people certainly can agree that there is a problem without agreeing on a solution, especially one that involves a standardized exam.
Personally, I think it's a good thing. It filters out people who are in it for the money and ensures that people who stay despite the shitty interview process are real enthusiasts.
But then again, I'm a programmer, not a manager running a company, so I understand that our incentives are not exactly aligned.
Other than that, I kind-of agree. One of the best interviews I had began with a "standardized" (for the company) test that set the bar with the basics (linux command line, memory management, threads, ...), and the continued with more specific competencies.
> she didn't think she would make it through their rigorous testing process
I though so as well once. It turned out to be one of the hardest, and therefore most interesting interview processes. I'm very happy at that job now.
I think a lot of this comes from insecurity by the interviewer and the interviewer's need to feel smarter than the interviewee.
You know going in what the process is, are you willing to prepare for it? Are you willing to expend the effort to open the text books, read papers, and arrange your day job to get the practice in?
I've found that the interview prep I had to do was a good indicator of what the job was going to be. So, if you're not willing to do the prep, then perhaps the job isn't for you.
Sitting on the other side of the table, the number of people who aren't able to accomplish a fizzbuzz type question is high. I also get more than just "can they code?" out of it.
I check:
1) for sound engineering practices (test data!)
2) ability to communicate their process.
3) willingness to ask questions when they don't understand.
4) ability to take feedback.
5) ability to work under time pressure.
The technical part is only the first bit. It's a bit hurdle, but it isn't the only one.
I understand that the research shows that the only truly accurate measure is working with someone for a week or two.
No one should be subjected to useless whiteboarding exercise, regardless of age and experience; conversely, to the extent that skills relevant to the job can be usefully assessed via whiteboarding, there is no reason age or experience (either of which may have provided time to produce job-useful skills, but is not valuable on its own) should get you out of them.
So, while I'm always unhappy with irrelevant exercises in hiring, I don't see the age/experience issue you raise as being relevant to that unhappiness.
A much better analogy would be asking an F1 mechanic to look at a car you had up on a lift. Sure, they don't fix Hondas all day log, but if they can't see obvious problems and don't know how to solve those obvious problems, it would be a serious red flag.
Even in your silly example, you'd be smart to question it if the mechanic couldn't label a lot of parts they should be able to label, and it would itself only be a small part of the interview.
Ask them to bring in an interesting example of their own code to the interview. Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs.
Really? You could easily fake that, have a friend who still works somewhere say anything.
> Ask them to bring in an interesting example of their own code to the interview.
That's great if you're willing to weed out people who only code at work.
> Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs.
That's what you can do without their own code, but it fails to prove they really wrote it.
Why are electrical engineers able to evaluate each other through conversation when software engineers apparently are not?
Once you start interviewing people with a lot of experience and see how poorly some do with FizzBuzz or 'merge 2 sorted arrays', it becomes immediately obvious why this is done. If 20 years experience was a good indicator, it would be used instead. For positions where there's no coding, this wouldn't be asked. All at least in my experience.
So coding exams are almost a litmus test for "inexperienced programmer" in my view. Because an experienced developer doesn't start by coding at all.
> So coding exams are almost a litmus test for "inexperienced programmer" in my view.
You certainly could call them that when they weed out people with 20 years of experience who can't merge 2 sorted lists.
Granted, this was at a company with a notoriously difficult technical screen, but it goes far beyond fizzbuzz or merging two sorted arrays. If you can't do that, there's no way you'll pass, but I'd say you need to be prepared to solve difficult questions from "cracking the coding interview" at the whiteboard in 45 minutes or less, without needing a great deal of help. Minor syntax errors are fine, but your code needs to be pretty tight and close to working.
I walk around with the ability to do fizzbuzz or merge two sorted arrays in my head, and I could code up merge sort or find the path from a root node to descendant in a binary tree with a little thought. But really, no joke, in my experience, these interviews take far, far more than that. I can't speak for everyone, but I personally need to study, hard, for a few weeks to a few months to get into this kind of form, depending on how long it's been since I last did it.
I have no doubt that the degree of technical grilling varies considerably between companies, which is why I'm not doubting what you've said here. However, I am certain that it doesn't tell the whole story - and that many of the companies that claim that there is a desperate shortage of software engineers have set the "no hire" standard to the point where they are rejecting people who could easily do what you've described, and much more.
But, Google does it so it must be the best way to interview candidates. God forbid you should actually get a candidate to write some code for you with a computer or something.
I know I tend to freeze up when writing whiteboard code in front of a interviewer, so I do not want to subject somebody to that when I am interviewing. When you are looking over someone's shoulder, you are not getting a true picture of their ability.
The other thing is that writing code on a whiteboard has nothing to do with coding in the real world. You write some code, test by running in a browser, command line or IDE, refactor, test again etc. Expecting someone to write perfect code without running said code is ridiculous.
Whiteboards should be used for sketching out ideas, i.e. architecting different ways to solve a high level problem, like how should I organize these objects in the application? What should the interface look like?
That said I feel like interviewing is important enough that a large company with (presumably) large resources ought to be able to make sure a laptop is always there. But it isn't as simple as "just bring a laptop", you'd have to have an enforced process.
I agree with your sentiment but struggle with the question above.
2. Present one or two real-world challenges related to the work the candidate would be doing for you and talk about how he or she would solve them. If the candidate wants to draw or write code on a piece of paper or white board, fine. But this should be a conversation, not a test.
3. Although they aren't always viable, contract-to-hire relationships are your friend.
You can learn a lot about the depth of someone's understanding of the full engineering process: reqs & specs, design, implementation, test, maintenance. Among the places the candidate has worked, ask them about the strengths or weaknesses of various approaches and techniques. Ask for war stories that were learning experiences. Ask for their thoughts on which of these might be relevant within your company (or given a certain set of synthetic but plausible relevant constraints).
In practice, a really large fraction of software dev practices, especially in the early phases like requirements and design, have long been suboptimal. (I'm being kind, of course.) But few bemoan this because, formally, few agree about how to correct it, largely because business problems vary widely. However if someone smart works in business long enough, and they pay attention to more than just their own code, they usually learn a lot about which approaches serve their business well and which don't. That wisdom is the greatest strength of an experienced developer/engineer.
Explore that in the interview, and not just how they would code a red-black tree template in C++ on a whiteboard.
1) Rather than ask them to code something, give them some code and have them review it. I opened up a browser and went to code review.stackexchange.com and picked one in the interviewee's favorite language.
2) Have them show you code they've written. It doesn't have to be from their current job, which would probably violate their employment agreement, but they've probably written some side projects for fun, or worked on some open source, or something.
3) Discuss problems they've actually solved and how they approached it. What did they try that didn't work? Why did they choose the solution they did? Did they consider anything but not try it? If so why didn't they try it?
That way you're not testing their ability to write unrealistic code (who writes their own linked list?) under ridiculous time pressure (less than 1 hour); you're not bringing on test-trauma that wouldn't affect them in their real job, etc.
For example, I interviewed one guy to become the Tech Lead for a client's SaaS initiatives. He had a lot of experience, but it was all experience with mainframes. And it showed in how he approached technical/architectural scenarios. Especially for senior/tech leads, you don't want to have to retrain them.
Somebody like this almost certainly should have been filtered out at the resume review stage or in a phone screen. There is no reason a company should be investing staff time in an in-person interview before it has a clear understanding about a candidate's experience.
Insanity would be you assuming they are good at problem solving and coding without even checking.