I recently drove 3 hours to a technical interview. I had done plenty of screening, including screenshare while I wrote code to the guy's delight.
He invited me down for the technical interview. I came down a week later. His wife had just delivered a baby, so he was out. The guys in the room were a business level ex-marine who was there for god knows why, and a technical dude who clearly was pissed he had to sink to the level of doing the interview in the first place.
For the first 45 minutes, I aced everything he threw at me, and I noticed that he wouldn't drill in on anything that I clearly knew very well. He kept jumping from topic to topic, and eventually asked to do an extremely tricky SQL query, but write the code to do it in awk on the whiteboard. The job posting said nothing about awk, and I told him I didn't know awk that well. He then sensed i wasn't a command line master (the job posting said nothing about needing to be a fucking sysadmin or know advanced CL stuff) and hammered me on things that I had already said I didn't know.
2 things became clear:
He wanted to show off to his boss and make himself look like a badass while simultaneously making me look incompetent.
There was no fucking way I was going to accept a job working here if it was offered.
I didn't so much as get a phone call or an email to thank me for driving 6 hours round trip. Nothing. Which screams out to me that this company sucked.
I recently flew in for a 4-hour on-site interview halfway across the continent, which included a live test of programmer skill which required knowledge of javascript, bash shell commands, and Google searching, along with exposure to the company's internal tools. Also featured was an abstract problem solving interview, and a short sales pitch for myself in front of the whole team.
After I left, I also did not get so much as a phone call or e-mail. Neither thank you nor followup. When I attempted to re-establish contact, it was like shouting into a black hole.
The feedback I received on site from the interviewers was neutral to positive, with one interviewer claiming that I was the only applicant to come up with the correct response to their abstract brainteaser.
If I take two whole days off from my existing job to come to you and indulge you in your cute little skill tests intended to prove my bona fides, you ought to have the decency to follow up.
So you're not the only person to be on the receiving end of this unacceptable behavior from interviewing companies.
This sums up the general problem with intervie(wer)s: most of them are wrongly focused on "catching the candidate on incompetence" instead of verifying how well will s/he perform on a given job.
During my last job hunt, I attended an interview at a mega corp. A interviewer walked in and then the interview started. Not sure why, As it went along, the guy seemed to get angry and angrier every time I answered a question. It was weird behavior.
But from what I know, running into such people is pretty common in interviews.
I think that last sentence is the key point here - it doesn't sound like somewhere that would be a very friendly environment in general. This kind of thing wouldn't happen where I work, but either way, the technical interview isn't really at fault.
Yeah, that pretty much sucks. I generally try and ask people about what they did and drill into whatever it is they know, but most interviews I've gone on the interviewer wants you to know the stuff the interviewer knows/is good at.
Iambob doesn't account for the fact that interviewing candidates falls into a Simpson's Paradox for this instance.
You have two cohorts which comprise a majority of your applicants:
1. Unemployed, X% qualified. Has time.
2. Employed, 100-X% qualified. Does not have time.
X is small. If both candidates are qualified, tests for X also find how qualified they are so they can be compared.
His methods are objectively better, provided that both candidates have the same amount of free time. If you compare two unemployed engineers, you'll pick the right one. If you compare two employed engineers, you'll pick the right one.
If you compare an unemployed engineer vs an employed one, however, you'll probably pick the unemployed engineer, even if the employed one is better. Because he doesn't have as much time for your homework or to maintain a Github profile.
Thus, if you're comparing 30 engineers, half of whom are employed, you'll pick the most qualified unemployed candidate, rather than the objectively most qualified candidate.
That's why, even if the test is slightly worse, with an interview room only test you'll consistently pick the better candidate: a large, large segment of talented candidates are employed.
I would love a statistical analysis of Simpson's Paradox and technical interview methods if anyone's ever done one.
If you're employed, it's generally a lot easier to find the time to do a coding problem at home than it is to actually physically come in during a weekday and talk to people.
"Look at github contributions and stackoverflow posts"
That's fine for startup-ish hires, but in most of those cases, isn't the candidate being sought out/referred/etc? Almost all of my work is on non-public SCM systems, and frankly, my job doesn't leave a ton of time to post to *overflow sites, and when I go home, I'm home, and spend it with my hobbies and family.
I also consider myself a really great developer. Especially in the more corporate .net world. When I review candidates, I find that a simple (at a PC, with resharper installed) coding test, with a prebuilt solution, needing only an implementation of a method done, is a great filter for competency. And after all, rough competency is the most I hope to get out of a coding test. The far more important part is always the stuff like how well I think they'll fit in a team, how their approach to solving problems in general is, etc.
Syntax memorization is no longer a measure of a good developer. All it shows is basic competence in a language.
OP has the wrong assumptions. The live technical interview is already well-known to be flawed, because qualified people often fail. However, only qualified people can pass.
However, it's true that coding exercises that can be completed in an interview are arbitrary and abstract (by necessity, since you have no context.) In my opinion one should use live coding exercises to test fluency -- can you code at the level you are claiming? Debugging something might be a better test. Then pair that up with a short (short!) take home exam to test problem-solving.
The one thing that really has to go is whiteboard coding. Ask the candidate to bring a laptop or give them a used one.
OP also thinks that high-pressure situations don't occur with programming. But if you work on the web, sooner or later you will be debugging a tricky issue that's costing that company $X per hour while your all your managers up to the CEO hover behind your desk. Being able to communicate with non-technical people and inspire their confidence is also very important. Often more important than coding ability.
The assumption that only qualified people can pass a technical interview is somewhat wrong.
I have had my fair share of false positives. And probably I have been one or two times the false positive. And this is something that everyone can relate I suppose.
Sometimes you just need luck - like the gotcha question being something you have debugged soon in a language you are not that competent at.
If only this were true. There is a whole class of people out there who are stellar face to face and not great for your specific technical/business situation.
Well, I've seem a lot of false positives. The questions asked tend more to the mathematical side, So I've seem smart people but with little programming experience, that didn't knew how to write quality code, pass those interviews.
The problem is that problem solving with fancy algorithm's can even be part of the job, but are normally just a small fraction.
I've never seem dumb people going incredibly well in technical interviews, that's true, but I've seem a lot of bad programmers giving great answers to those abstract problems. And sometimes, they're knowledge wasn't actually a fit.
The one thing that really has to go is whiteboard coding.
A smart candidate will bring a notebook computer, loaded with suitable IDEs etc ready to go, without being asked to. Impresses people when you tell them to continue the interview while you write the requested code (multitasking, competent enough to spare nontrivial brain cycles answering unrelated questions).
I have walked out of technical interviews having spent 40 minutes struggling to write code on a whiteboard, sat down in front of a laptop, and coded a working solution in 5 minutes.
For my current job I was provided with the specifications for a simple app to display images from a flickr rss feed and asked to code however I felt was appropriate. It was interesting and fun, and vastly less stressful than any whiteboard test.
It was also a great indicator of what working at the company was actually going to be like.
> I have walked out of technical interviews having spent 40 minutes struggling to write code on a whiteboard, sat down in front of a laptop, and coded a working solution in 5 minutes.
This is how I bombed a DevOps role interview at Twilio, but was picked up as a VP of Engineering elsewhere. +1.
Companies reading my parent comment should take note - abstruse technical questions on a whiteboard are fairly ineffective.
For people looking for alternatives to whiteboarding or phone screens where the candidate writes code in the blind, check out https://coderpad.io
It lets you write and execute code with your interviewee in real-time, and provides a much more native programming experience easily and over the browser. Some rather large companies have started using us exclusively in the in-person technical interview, even buying Chromebooks especially for the application.
Disclaimer: I am the guy who makes CoderPad and am obviously biased.
I totally failed an interview because I was panicked when writing some simple code on a whiteboard. The interview started with three interviewers in the room but only one was talking to me. The other two remained silent the entire time. The talking interviewer asked me to solve a simple problem on a whiteboard, and I to my own surprise just couldn't do it. I'm already nervous just meeting new people who don't know me as a person, and I'm trying to perform my craft outside of my usual environment while being judged.
I use a whiteboard at work to pseudo code a solution, and the writing looks like chicken scratch but even my co-workers get what I'm expressing to them. Then I open up a console and start typing out my idea to see if I was right. That's how I normally solve some throw away piece of code. I don't go into a manager's office and call some other random people and in detail explain to them my idea to a solution.
I also got the feeling they never saw my resume because I was asked if I had a github profile, and it's on my resume.
You bring up an important point. If you liked the job & atmosphere, don't give up! If you feel you bombed on something, research it as soon as you get home and do what you can to impress them.. send an email back with working code (or better answers).
If you ask me to "code" something on the whiteboard, that simple request is more an indication of your competence or cluefulness, or rather lack thereof, than the result would be an indication of my qualities.
The proper reaction to such a request would be: "So, you guys do all your work here on whiteboards? That's seems unusual, I used laptops or workstations at all my previous jobs."
Too many times I've been in a technical interview where they asked me to define design patterns, but never ask me when/how to actually use them. I usually decline their offers.
When I interview candidates, I look for a good foundation for what they will be working with like do they know the difference between class and struct and the implications of using them (day 1 kind of stuff).
Then I ask them about how they would go about solving a problem they were unfamiliar with. Google-foo is a skill that must be learned and honed. I don't care if you can spit off all sorts of acronyms, I want to know if you are capable of using common sense to solve a problem.
Last but not least, how do they stay up-to-date and relevant. Not looking for the 8 to 5 developers and not interested in those cutting-edge guys either.
Must have good understanding of the basics, principals and skills in problem solving. Telling a block of code that you have a masters in CS will NOT make the bug go away.
It is not the technical interview that is a problem; it is the interviewer. I sit quite often on both sides of the table and I have noticed that some interviewers are eager to show off their skills more than trying to learn about the candidate. Or they are auditioning bros to go clubbing or to invite to barbecues . I have not ever cleared a tech interview when I was interviewed by guys in twenties or early thirties. I have a 100% success rate when I am interviewed by people,all races and gender , over 40.
When I am conducting interviews, I place a high degree of importance on the candidates aptitude and approach to problem solving and I usually build up a pretty good team with candidates who the bros wouldn't hire.
Some people suggest looking at candidate's github repo; this would not work for enterprise software developers and most large companies have restrictions on what code a developer can claim as his/her own and publish.
1 Getting the actual real requirements nailed down
2 Designing the system to run in the real world accounting for all those edge cases and falilure modes.
> Getting the actual real requirements nailed down
Wherein the programmer plays the role of social worker. Seriously though, the skill sets are very similar. The client is typically the ultimate source of the requirements, but it's never a simple case of asking the client "what should I build? More often than not, the client doesn't know what s/he wants, wants something that will actually hurt him/her, is actually seven different people who want opposite things, wants the roses simultaneously painted white and red, etc. Which is why I find requirements collection the most challenging part of the job.
That makes me wonder if a business-analyst or product-manager role should involve a technical interview where you spec out a mock product to see how well you gather requirements.
I wouldn't say that coding is the easy bit (if it were I wouldn't have seen so many terrible code bases in my life). I'd say that requirements gathering and systems design are also crucial difficult parts of the process of developing software and any developer acquisition methodology should take them into account as well.
We've recently given a huge amount of thought to this idea (how to technically assess applicants) and sought input from many sources. This is because we are building a curated online community of technical (job) profiles, and we have a very strong incentive program for people to sign up. (It's being announced any minute.) In fact, you could say our incentive program is too strong, and we are afraid of getting "CTO/senior web applications developer" with "20 years of Linux and AWS experience" who can't actually define what "ls" is or what "for" does (in any language).
So, what shall we do? How can we very strongly incentivize every qualified person to upload their profile, in a way that lets us curate people's actual abilities?
The suggestions this article makes, to demand githubs or complete projects done for demonstration purposes, have both been rejected. Sure, it may be a good strong signal. But then so is the signal of someone creating a complete application for your company (complete with branding) to actually A/B test on the front page, and then if it does well, for the canddiate to show up for a 3 month unpaid trial during which he or she must contribute as a full member of the team and can be dismissed at any time for no reason. I guarantee, anyone who passes that test would be a great candidate. The issue is that there are perhaps three people on the planet who would even consider applying to a company on those terms - and they're the original founders' siblings.
The problem is that it is not a reasonable burden on job applicants, and neither is a complete github profile, and neither is a complete programming project. It's just too much.
What is needed is a smaller burden that is a good, strong signal.
We think we've found one, but are not sure. (You can see it on our web site as soon as we announce.)
In the mean time, if anyone here has any breakthrough ideas in this space, we would be very interested.
Here's what I've been doing. I'm running on an egregiously small sample size right now, but so far, so good.
My goal is to answer "Are you honest about what you know, excited and curious about what you don't, willing and able to learn, and driven to excel at the role that we're discussing?" Sometimes answering this requires code, but generally not a whole lot, and mostly I just use it to tease out where someone actually is vs. where they say they are. I don't want to hire a candidate who is best suited to make my problems go away tomorrow. I want, a year or three down the line, to say I built the best team possible.
Maybe I can say this because I don't think the "technical" part of what we're doing is the major challenge, though I think that most engineering teams are actually in the same boat as us. Google has far different problems than we do, so their hiring process is rightfully different than ours. And maybe I'm just getting it all wrong. We'll see what happens.
Just because it's hard to do technical interviews well doesn't mean that doing them well isn't worthwhile.
In my technical interviews, I look to talk through specific technical problems, and they're usually real-world bugs or design issues I've worked through in my job. There's not usually a lot of code involved, and the code isn't that tricky. It doesn't usually even rely on too much specific domain knowledge. It's about being able to take a broad technical question, formalize it a little into something concrete enough to be discussed, identifying constraints on the solution, working towards a solution, reasoning about performance, and discussing tradeoffs of this approach vs. others. In short, it's about technical reasoning. I don't care if we get to the right answer by the end if we've had a fruitful technical discussion.
Code samples are a good idea, but they're as deeply problematic as interviews. Most of the code from most of the best engineers I know is closed-source, not on github. 48-hour programming projects can tell you what someone can cobble together, but they don't say anything about the person's attention to longer-term concerns around design or code quality. Moreover, being able to code up a technical solution to a 48-hour problem is like basic literacy: I expect at least that, but I really want to find people who can make forward progress on the uncertainties associated with a 3-month project, at least.
Before I tech screen anyone, I have a short email or phone chat with them. I ask if they program every day and how much of a typical recent day was spent programming.
If it sounds like they are currently not full-time employed as a programmer (and not programming a lot), I explain that they will probably not do well on technical tests (mine or anyone else's) if they don't practice. I recommend they just find some sample questions online and practice them -- let me know when they think they are ready.
I explain it's just like playing an instrument -- you wouldn't audition without practicing beforehand, right? I also explain that it's very hard to tell the difference between someone who is rusty and someone who is not skilled -- I want them to be at their best.
To everyone, currently programming or not, I explain what the interview will be and everything about it that I can except for the questions. I am hoping they will self-select out if they know they can't program (or talk to me about it).
I also explain that I am not looking for people who know all of the answers, but I am trying to calibrate their resume and see what it's like to collaborate. All tech screens are conducted in the language of the applicant's choice.
The meta-question I am asking them: If I tell you a bunch of requirements and some guidelines for success, will you do the work necessary to succeed.
I hear these complaints all the time, yet not many people complaining actually offer viable solutions for vetting a candidate's ability.
That said, I would say Github contributions and maybe paired with StackOverflow activity may be a good substitute for a technical interview when available.
The author said Github contributions and/or a specific programming project. My development group does a relatively simple tech interview + a programming project.
I think it's just a symtpom of an evolving industry. Studied solutions are better than viable solutions, and we may just be studying it without acknowledging that fact. Someone should put some actual researchers on this problem though.
A technical interview whiteboard code or data structure gotchas or mt. fuji questions is a bad interview. It sucks that most technical interviews are bad, but that means we should fix them not remove them.
Our team "technical interviews" by having a technology discussion with the applicant. One of the first lines of question is figuring out what they are most familiar with so we can discuss that particular thing, area, library, or whatever. If a person can't discuss what they are most familiar with in the high-pressure interview, I'm not sure they can discuss something they just learned about in a team design meeting either. It's also a great way for the candidate to figure out if he wants to work with us - something that is just as important as the reverse.
Quit making technical interviews a quiz show. Quit checking off boxes on your form. Quit with BAD technical interviews. But don't remove them entirely - that's just as dumb.
Github profile: How many repo's do they have? How active are they? Do they contribute to open source projects? And then, of course, the obvious code quality questions.
I thought most people came to the conclusion that this is a horrible metric by which to gauge competence?
Then again...
Now us Python developers, Ruby developers, Java developers, PHP developers, and (God help you) Perl developers, let us put aside our meaningless and largely annoying quibbles to unite under a single banner. For once, let's say who cares whether Django or Rails is the superior framework and just join our voices to call for an end to the modern technical interview.
The final paragraph shows what demographic the OP belongs to, so it's hardly a surprise they think that way.
The biggest problems I've found in tech interviews are:
1) Bad problems - implementing string reverse is a silly question. It has little to do with 'real world' optimization, which is often more about architectural issues: caching, etc.
2) Markerboards - I never, ever write code on a markerboard. Why ask me to write code on a marketboard in an interview? Markerboards are great for high level concept organization, they are terrible for writing code. In the real world I often write a crap implementation of something and make it work, add tests for it, then refactor till it's not crap. Demonstrating that workflow on a markerboard is nearly impossible.
Otherwise, in what possible high-pressure situation will you ever be expected to solve an obscure data structures problem on a whiteboard. With no syntax checking or debugger. In front of three scrutinizing neck-beards. Answer: Never.
THIS. ALL OF THIS.
I recently had a technical interview where I was asked to write some Java code that printed out every 7th number. I could not, for the life of me, figure out how to do it. And I've been a software engineer for 25 years.
I realized later that it was because I was nervous about how I could present myself in this once chance, and that made all the rest of it difficult.
It seems like people have vastly varying ideas about what constitutes a 'technical interview'.
For my money, I'd expect that most interviews in any field are technical to some degree. If you're hiring an HR person at any level of seniority at all, presumably you'll be asking questions that bear on employment/tax law, dispute resolution and so forth - in short, questions that bear on a body of specialised knowledge: technical questions. The problem is execution.
Having never been asked to do code on a whiteboard, I can't comment on whether that's any use. (I think I'd be OK provided it was acceptable to drop into pseudocode: surely we're not testing for encyclopaedic knowledge of every method in X language's standard library.) 'Homework' challenges have the advantage, if they're executed right, that whoever you're hiring won't be going in completely cold to whatever tech you're using - may as well get some of that newbie-googling done in advance. (Just did one for a job using Mongo/Mongoid - what I knew about that beforehand would have fit on the back of a cigarette packet.)
"I think I'd be OK provided it was acceptable to drop into pseudocode"
My experience and impression is its generally the opposite.
Whiteboard is a good place for psuedocode, data flow diagrams, schemas, flowcharts, block diagrams, data structures, and bug related examples. Its a pretty bad spot for source code other than one line notes. I usually have scratch paper with scribbles all over it when I'm coding, so that seems fair. I don't think I've ever written anything in Clojure without a REPL open, it would be a weird experience to write something out entirely on a whiteboard without running all the little parts first. Also the test-driven experience is very weird if you can't actually run tests. Its like testing someones teamwork skills by having them work alone, very strange.
I feel a professional obligation to begin all projects with a bit of google to at least prove I'm not wasting effort on NIH and find some pitfalls, so the suggestions to test a dev without any net access also feels extremely weird to me.
I think the primary fail of tech interviews is its nothing more than a stress test, selecting for candidates who don't really care, or at least are unnaturally calm, and that doesn't seem to correlate very well with ability.
[+] [-] JPKab|12 years ago|reply
He invited me down for the technical interview. I came down a week later. His wife had just delivered a baby, so he was out. The guys in the room were a business level ex-marine who was there for god knows why, and a technical dude who clearly was pissed he had to sink to the level of doing the interview in the first place.
For the first 45 minutes, I aced everything he threw at me, and I noticed that he wouldn't drill in on anything that I clearly knew very well. He kept jumping from topic to topic, and eventually asked to do an extremely tricky SQL query, but write the code to do it in awk on the whiteboard. The job posting said nothing about awk, and I told him I didn't know awk that well. He then sensed i wasn't a command line master (the job posting said nothing about needing to be a fucking sysadmin or know advanced CL stuff) and hammered me on things that I had already said I didn't know.
2 things became clear:
He wanted to show off to his boss and make himself look like a badass while simultaneously making me look incompetent.
There was no fucking way I was going to accept a job working here if it was offered.
I didn't so much as get a phone call or an email to thank me for driving 6 hours round trip. Nothing. Which screams out to me that this company sucked.
[+] [-] logfromblammo|12 years ago|reply
After I left, I also did not get so much as a phone call or e-mail. Neither thank you nor followup. When I attempted to re-establish contact, it was like shouting into a black hole.
The feedback I received on site from the interviewers was neutral to positive, with one interviewer claiming that I was the only applicant to come up with the correct response to their abstract brainteaser.
If I take two whole days off from my existing job to come to you and indulge you in your cute little skill tests intended to prove my bona fides, you ought to have the decency to follow up.
So you're not the only person to be on the receiving end of this unacceptable behavior from interviewing companies.
[+] [-] mrfusion|12 years ago|reply
Companies routinely pay for airfare and lodging, it would seem to only make sense if they also paid for long car trips, no?
[+] [-] ArekDymalski|12 years ago|reply
[+] [-] kamaal|12 years ago|reply
But from what I know, running into such people is pretty common in interviews.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] arbutus|12 years ago|reply
[+] [-] qdog|12 years ago|reply
[+] [-] pekk|12 years ago|reply
[+] [-] josephschmoe|12 years ago|reply
You have two cohorts which comprise a majority of your applicants:
1. Unemployed, X% qualified. Has time.
2. Employed, 100-X% qualified. Does not have time.
X is small. If both candidates are qualified, tests for X also find how qualified they are so they can be compared.
His methods are objectively better, provided that both candidates have the same amount of free time. If you compare two unemployed engineers, you'll pick the right one. If you compare two employed engineers, you'll pick the right one.
If you compare an unemployed engineer vs an employed one, however, you'll probably pick the unemployed engineer, even if the employed one is better. Because he doesn't have as much time for your homework or to maintain a Github profile.
Thus, if you're comparing 30 engineers, half of whom are employed, you'll pick the most qualified unemployed candidate, rather than the objectively most qualified candidate.
That's why, even if the test is slightly worse, with an interview room only test you'll consistently pick the better candidate: a large, large segment of talented candidates are employed.
I would love a statistical analysis of Simpson's Paradox and technical interview methods if anyone's ever done one.
[+] [-] GregorStocks|12 years ago|reply
[+] [-] mempko|12 years ago|reply
[+] [-] bbarn|12 years ago|reply
That's fine for startup-ish hires, but in most of those cases, isn't the candidate being sought out/referred/etc? Almost all of my work is on non-public SCM systems, and frankly, my job doesn't leave a ton of time to post to *overflow sites, and when I go home, I'm home, and spend it with my hobbies and family.
I also consider myself a really great developer. Especially in the more corporate .net world. When I review candidates, I find that a simple (at a PC, with resharper installed) coding test, with a prebuilt solution, needing only an implementation of a method done, is a great filter for competency. And after all, rough competency is the most I hope to get out of a coding test. The far more important part is always the stuff like how well I think they'll fit in a team, how their approach to solving problems in general is, etc.
Syntax memorization is no longer a measure of a good developer. All it shows is basic competence in a language.
[+] [-] neilk|12 years ago|reply
However, it's true that coding exercises that can be completed in an interview are arbitrary and abstract (by necessity, since you have no context.) In my opinion one should use live coding exercises to test fluency -- can you code at the level you are claiming? Debugging something might be a better test. Then pair that up with a short (short!) take home exam to test problem-solving.
The one thing that really has to go is whiteboard coding. Ask the candidate to bring a laptop or give them a used one.
OP also thinks that high-pressure situations don't occur with programming. But if you work on the web, sooner or later you will be debugging a tricky issue that's costing that company $X per hour while your all your managers up to the CEO hover behind your desk. Being able to communicate with non-technical people and inspire their confidence is also very important. Often more important than coding ability.
[+] [-] venomsnake|12 years ago|reply
I have had my fair share of false positives. And probably I have been one or two times the false positive. And this is something that everyone can relate I suppose.
Sometimes you just need luck - like the gotcha question being something you have debugged soon in a language you are not that competent at.
[+] [-] kasey_junk|12 years ago|reply
If only this were true. There is a whole class of people out there who are stellar face to face and not great for your specific technical/business situation.
[+] [-] lucasnemeth|12 years ago|reply
The problem is that problem solving with fancy algorithm's can even be part of the job, but are normally just a small fraction. I've never seem dumb people going incredibly well in technical interviews, that's true, but I've seem a lot of bad programmers giving great answers to those abstract problems. And sometimes, they're knowledge wasn't actually a fit.
[+] [-] ctdonath|12 years ago|reply
A smart candidate will bring a notebook computer, loaded with suitable IDEs etc ready to go, without being asked to. Impresses people when you tell them to continue the interview while you write the requested code (multitasking, competent enough to spare nontrivial brain cycles answering unrelated questions).
[+] [-] iMark|12 years ago|reply
For my current job I was provided with the specifications for a simple app to display images from a flickr rss feed and asked to code however I felt was appropriate. It was interesting and fun, and vastly less stressful than any whiteboard test.
It was also a great indicator of what working at the company was actually going to be like.
[+] [-] toomuchtodo|12 years ago|reply
This is how I bombed a DevOps role interview at Twilio, but was picked up as a VP of Engineering elsewhere. +1.
[+] [-] akanet|12 years ago|reply
For people looking for alternatives to whiteboarding or phone screens where the candidate writes code in the blind, check out https://coderpad.io
It lets you write and execute code with your interviewee in real-time, and provides a much more native programming experience easily and over the browser. Some rather large companies have started using us exclusively in the in-person technical interview, even buying Chromebooks especially for the application.
Disclaimer: I am the guy who makes CoderPad and am obviously biased.
[+] [-] OWaz|12 years ago|reply
I use a whiteboard at work to pseudo code a solution, and the writing looks like chicken scratch but even my co-workers get what I'm expressing to them. Then I open up a console and start typing out my idea to see if I was right. That's how I normally solve some throw away piece of code. I don't go into a manager's office and call some other random people and in detail explain to them my idea to a solution.
I also got the feeling they never saw my resume because I was asked if I had a github profile, and it's on my resume.
[+] [-] legohead|12 years ago|reply
[+] [-] Florin_Andrei|12 years ago|reply
The proper reaction to such a request would be: "So, you guys do all your work here on whiteboards? That's seems unusual, I used laptops or workstations at all my previous jobs."
[+] [-] c0deporn|12 years ago|reply
When I interview candidates, I look for a good foundation for what they will be working with like do they know the difference between class and struct and the implications of using them (day 1 kind of stuff).
Then I ask them about how they would go about solving a problem they were unfamiliar with. Google-foo is a skill that must be learned and honed. I don't care if you can spit off all sorts of acronyms, I want to know if you are capable of using common sense to solve a problem.
Last but not least, how do they stay up-to-date and relevant. Not looking for the 8 to 5 developers and not interested in those cutting-edge guys either.
Must have good understanding of the basics, principals and skills in problem solving. Telling a block of code that you have a masters in CS will NOT make the bug go away.
[+] [-] manishsharan|12 years ago|reply
It is not the technical interview that is a problem; it is the interviewer. I sit quite often on both sides of the table and I have noticed that some interviewers are eager to show off their skills more than trying to learn about the candidate. Or they are auditioning bros to go clubbing or to invite to barbecues . I have not ever cleared a tech interview when I was interviewed by guys in twenties or early thirties. I have a 100% success rate when I am interviewed by people,all races and gender , over 40.
When I am conducting interviews, I place a high degree of importance on the candidates aptitude and approach to problem solving and I usually build up a pretty good team with candidates who the bros wouldn't hire.
Some people suggest looking at candidate's github repo; this would not work for enterprise software developers and most large companies have restrictions on what code a developer can claim as his/her own and publish.
edit : grammar
[+] [-] mrfusion|12 years ago|reply
[+] [-] walshemj|12 years ago|reply
The hard part about the job is
1 Getting the actual real requirements nailed down 2 Designing the system to run in the real world accounting for all those edge cases and falilure modes.
[+] [-] jarrett|12 years ago|reply
Wherein the programmer plays the role of social worker. Seriously though, the skill sets are very similar. The client is typically the ultimate source of the requirements, but it's never a simple case of asking the client "what should I build? More often than not, the client doesn't know what s/he wants, wants something that will actually hurt him/her, is actually seven different people who want opposite things, wants the roses simultaneously painted white and red, etc. Which is why I find requirements collection the most challenging part of the job.
[+] [-] ayuvar|12 years ago|reply
[+] [-] kasey_junk|12 years ago|reply
[+] [-] lucasnemeth|12 years ago|reply
[+] [-] dasil003|12 years ago|reply
[+] [-] danielweber|12 years ago|reply
[+] [-] logicallee|12 years ago|reply
So, what shall we do? How can we very strongly incentivize every qualified person to upload their profile, in a way that lets us curate people's actual abilities?
The suggestions this article makes, to demand githubs or complete projects done for demonstration purposes, have both been rejected. Sure, it may be a good strong signal. But then so is the signal of someone creating a complete application for your company (complete with branding) to actually A/B test on the front page, and then if it does well, for the canddiate to show up for a 3 month unpaid trial during which he or she must contribute as a full member of the team and can be dismissed at any time for no reason. I guarantee, anyone who passes that test would be a great candidate. The issue is that there are perhaps three people on the planet who would even consider applying to a company on those terms - and they're the original founders' siblings.
The problem is that it is not a reasonable burden on job applicants, and neither is a complete github profile, and neither is a complete programming project. It's just too much.
What is needed is a smaller burden that is a good, strong signal.
We think we've found one, but are not sure. (You can see it on our web site as soon as we announce.)
In the mean time, if anyone here has any breakthrough ideas in this space, we would be very interested.
[+] [-] AnimalMuppet|12 years ago|reply
Even if you don't have the right answer, you at least found the right question.
[+] [-] jowiar|12 years ago|reply
My goal is to answer "Are you honest about what you know, excited and curious about what you don't, willing and able to learn, and driven to excel at the role that we're discussing?" Sometimes answering this requires code, but generally not a whole lot, and mostly I just use it to tease out where someone actually is vs. where they say they are. I don't want to hire a candidate who is best suited to make my problems go away tomorrow. I want, a year or three down the line, to say I built the best team possible.
Maybe I can say this because I don't think the "technical" part of what we're doing is the major challenge, though I think that most engineering teams are actually in the same boat as us. Google has far different problems than we do, so their hiring process is rightfully different than ours. And maybe I'm just getting it all wrong. We'll see what happens.
[+] [-] dap|12 years ago|reply
In my technical interviews, I look to talk through specific technical problems, and they're usually real-world bugs or design issues I've worked through in my job. There's not usually a lot of code involved, and the code isn't that tricky. It doesn't usually even rely on too much specific domain knowledge. It's about being able to take a broad technical question, formalize it a little into something concrete enough to be discussed, identifying constraints on the solution, working towards a solution, reasoning about performance, and discussing tradeoffs of this approach vs. others. In short, it's about technical reasoning. I don't care if we get to the right answer by the end if we've had a fruitful technical discussion.
Code samples are a good idea, but they're as deeply problematic as interviews. Most of the code from most of the best engineers I know is closed-source, not on github. 48-hour programming projects can tell you what someone can cobble together, but they don't say anything about the person's attention to longer-term concerns around design or code quality. Moreover, being able to code up a technical solution to a 48-hour problem is like basic literacy: I expect at least that, but I really want to find people who can make forward progress on the uncertainties associated with a 3-month project, at least.
[+] [-] loumf|12 years ago|reply
If it sounds like they are currently not full-time employed as a programmer (and not programming a lot), I explain that they will probably not do well on technical tests (mine or anyone else's) if they don't practice. I recommend they just find some sample questions online and practice them -- let me know when they think they are ready.
I explain it's just like playing an instrument -- you wouldn't audition without practicing beforehand, right? I also explain that it's very hard to tell the difference between someone who is rusty and someone who is not skilled -- I want them to be at their best.
To everyone, currently programming or not, I explain what the interview will be and everything about it that I can except for the questions. I am hoping they will self-select out if they know they can't program (or talk to me about it).
I also explain that I am not looking for people who know all of the answers, but I am trying to calibrate their resume and see what it's like to collaborate. All tech screens are conducted in the language of the applicant's choice.
The meta-question I am asking them: If I tell you a bunch of requirements and some guidelines for success, will you do the work necessary to succeed.
[+] [-] atom-morgan|12 years ago|reply
[+] [-] chaostheory|12 years ago|reply
That said, I would say Github contributions and maybe paired with StackOverflow activity may be a good substitute for a technical interview when available.
[+] [-] mordocai|12 years ago|reply
[+] [-] FLUX-YOU|12 years ago|reply
[+] [-] samrift|12 years ago|reply
Our team "technical interviews" by having a technology discussion with the applicant. One of the first lines of question is figuring out what they are most familiar with so we can discuss that particular thing, area, library, or whatever. If a person can't discuss what they are most familiar with in the high-pressure interview, I'm not sure they can discuss something they just learned about in a team design meeting either. It's also a great way for the candidate to figure out if he wants to work with us - something that is just as important as the reverse.
Quit making technical interviews a quiz show. Quit checking off boxes on your form. Quit with BAD technical interviews. But don't remove them entirely - that's just as dumb.
*ps: github as a metric is also a bad metric.
[+] [-] vezzy-fnord|12 years ago|reply
I thought most people came to the conclusion that this is a horrible metric by which to gauge competence?
Then again...
Now us Python developers, Ruby developers, Java developers, PHP developers, and (God help you) Perl developers, let us put aside our meaningless and largely annoying quibbles to unite under a single banner. For once, let's say who cares whether Django or Rails is the superior framework and just join our voices to call for an end to the modern technical interview.
The final paragraph shows what demographic the OP belongs to, so it's hardly a surprise they think that way.
[+] [-] mbell|12 years ago|reply
1) Bad problems - implementing string reverse is a silly question. It has little to do with 'real world' optimization, which is often more about architectural issues: caching, etc.
2) Markerboards - I never, ever write code on a markerboard. Why ask me to write code on a marketboard in an interview? Markerboards are great for high level concept organization, they are terrible for writing code. In the real world I often write a crap implementation of something and make it work, add tests for it, then refactor till it's not crap. Demonstrating that workflow on a markerboard is nearly impossible.
[+] [-] jrjarrett|12 years ago|reply
THIS. ALL OF THIS.
I recently had a technical interview where I was asked to write some Java code that printed out every 7th number. I could not, for the life of me, figure out how to do it. And I've been a software engineer for 25 years.
I realized later that it was because I was nervous about how I could present myself in this once chance, and that made all the rest of it difficult.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] tragic|12 years ago|reply
For my money, I'd expect that most interviews in any field are technical to some degree. If you're hiring an HR person at any level of seniority at all, presumably you'll be asking questions that bear on employment/tax law, dispute resolution and so forth - in short, questions that bear on a body of specialised knowledge: technical questions. The problem is execution.
Having never been asked to do code on a whiteboard, I can't comment on whether that's any use. (I think I'd be OK provided it was acceptable to drop into pseudocode: surely we're not testing for encyclopaedic knowledge of every method in X language's standard library.) 'Homework' challenges have the advantage, if they're executed right, that whoever you're hiring won't be going in completely cold to whatever tech you're using - may as well get some of that newbie-googling done in advance. (Just did one for a job using Mongo/Mongoid - what I knew about that beforehand would have fit on the back of a cigarette packet.)
[+] [-] VLM|12 years ago|reply
My experience and impression is its generally the opposite.
Whiteboard is a good place for psuedocode, data flow diagrams, schemas, flowcharts, block diagrams, data structures, and bug related examples. Its a pretty bad spot for source code other than one line notes. I usually have scratch paper with scribbles all over it when I'm coding, so that seems fair. I don't think I've ever written anything in Clojure without a REPL open, it would be a weird experience to write something out entirely on a whiteboard without running all the little parts first. Also the test-driven experience is very weird if you can't actually run tests. Its like testing someones teamwork skills by having them work alone, very strange.
I feel a professional obligation to begin all projects with a bit of google to at least prove I'm not wasting effort on NIH and find some pitfalls, so the suggestions to test a dev without any net access also feels extremely weird to me.
I think the primary fail of tech interviews is its nothing more than a stress test, selecting for candidates who don't really care, or at least are unnaturally calm, and that doesn't seem to correlate very well with ability.