I will not do a tech interview
medium.com
medium.com
Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed.
I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/specificity works. Give them an example webapp idea, and ask how they might architect it.
None of these are gotchas. All of them are directly applicable to the work they'll be doing. If you can't explain how closures work, then either you don't understand them (so you shouldn't be hired except for a very junior position), or you're bad at communicating/explaining (which, on teams, can be equally bad).
The author says "Other times I just froze on topics that I know very well." Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients?
If you freeze up in interviews, then it doesn't seem like the problem is with interviews -- the problem is with you freezing up, isn't it? I mean, if you can't answer basic questions about your knowledge in a one-on-one conversation, then that's a real problem, and not just in interviewing. (Obviously, some overly aggressive or unfriendly interviewers can be off-putting, but I'm just talking about "normal" friendly interviewers.)
Of course not. Interview situations are very, very different than the others. Meetings and code reviews are with co-workers, whom you know and trust. Meetings with clients could be nerve-wracking for other reasons, but they're unlikely to challenge your depth of coding knowledge.
For my own personal example, I once interviewed at a place where the interviewer wrote up some HTML on a whiteboard, and then asked me to write out the CSS next to it that would turn it into a horizontal drop down menu.
I don't work that way. I sit with my editor in one screen and a browser window in the other, and I piece together the layout as I go along. I assure you, it works just fine. But the interview situation was so far divorced from any every-day working situation that it felt very unnatural.
I opted out of returning for the second round of interviews. The next place I interviewed I sat down, in front of a computer, with the interviewer, and we talked through code as I wrote it. I took the job.
In the scenario you described, I might try something like this: "I think I see what you're trying to measure by asking that question, but it assumes a working style that is foreign to me. So that you can get a better reading of what I can really do, would you mind if we used my laptop, with you looking over my shoulder, as I solved a problem of similar difficulty?"
An interview is a negotiation. If you want to change it, just ask. Most interviewers will be happy to agree to any changes that will help them get a better read on your true abilities.
Agreed. I once interviewed for a job within the company I already worked for (crazy bureaucratic process aside), and I was being interviewed by my existing boss, and a colleague that used to be on the same team as me.
I was asked a question about ASP.NET ViewState which I drew a complete blank on. I just couldn't wrap my ahead around the question because of nerves. It was only when my boss reminded me that this was something I had actually taught him and my colleague only 6 months ago that my nerves cleared, I relaxed, and then I could suddenly think clearly again.
The interview process creates a dynamic relationship between interviewer and interviewee that never exists between colleagues and bosses.
Really? I disagree. There even exist situations (in the case of some positions) where you will be talking to a client of the company you're working for, effectively interviewing with the client, representing the company. And interviewing is a subset of "sales", which is important for working on many teams -- including selling management on changes that would improve the user experience, for example.
>Meetings and code reviews are with co-workers, whom you know and trust.
Actually, when you first start out, you don't know them much more than you did when they were interviewing you. And honestly, I haven't always learned to trust my coworkers; or rather, some I've learned to not trust.
Regardless, this sounds like a psychological limitation on the side of the interviewee. Which is something you can work to improve.
Disclaimer: I've always been good at interviews. At least good enough that I have a more than 50% job offer rate for interviews I've gone to.
>For my own personal example, I once interviewed at a place where the interviewer wrote up some HTML on a whiteboard, and then asked me to write out the CSS next to it that would turn it into a horizontal drop down menu.
Not my domain, but yes, that sounds like a "parrot from memory something that you could copy-and-paste or build up trivially with a real coding environment," which I agree is not a great question, nor is it a good way to interview.
>I opted out of returning for the second round of interviews.
I think this is where you failed, though. If they asked you back, then even though you didn't feel good about the interview process, you must have passed. Their process is broken, so probably NO ONE was able to do everything perfectly.
>The next place I interviewed I sat down, in front of a computer, with the interviewer, and we talked through code as I wrote it. I took the job.
That's certainly a better interview process. But you do realize that you filtered out a company for having a less-than-optimal interview process? Seems like a poor choice of filter, in both directions.
I didn't prepare for this, but it allowed me to convey my engineering thought process and brag a little :) I really enjoyed it.
How exactly? Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job. Sure, you'll get comfortable with your coworkers, and they'll get more forgiving of temporarily lapses, but I think most interviewers (for non-terrible jobs especially) purposefully give some extra leeway to interviewees, since it's understandable for them to be a bit more nervous than a coworker would be.
If the interviewer would demand exact solution for the problem on the whiteboard, then probably it's time to part your ways and go to the interview with another company.
With a client, it's about the software you're developing, with a interviewer, it's about software architecture or coding principles.
In your example about HTML -> CSS I think you missed the point. It wasn't so much to check that you have something memorized, but to check your familiarity with the subject. Everyone sits with a browser while they code - I don't think that's a unique workflow. The thing is, if you've done this HTML -> CSS conversion a hundred times before, you wouldn't need to look it up. They're trying to gauge your experience level and if you've done this stuff hundreds of times before. I bet even a highschool student could find that with Google.
EDIT: I think a more relatable example would be if the interview gave you a simple geometrical problem and you were upset you can't look up the Pythagorean theorem. You're not being tested on your ability to memorize the Pythagorean theorem per se - it's just that everyone is expected to know the Pythagorean theorem b/c it's so fundamental to the sciences. Super simple problem with no google are testing if you have domain familiarity and experience and are a metric of whether you will hit the ground running or not. They're not gauging you problem solving ability, or your ability to memorize crap.
A code review or client meeting involves defending decisions that you or people working at your company have made, and explaining things for a code base you ought to have at least some familiarity with. That's a far different beast than being asked with no warning to come up with a way to complete someone else's task in a way that they consider "suitable".
Meetings and code reviews happen every day (or at least a few times a month), so you're well versed in their protocol.
Make yourself well versed in the protocol of interviews and they won't be any more stressful than any other type of meeting.
I find its helpful to think of people in a similar situation: door to door salesmen (possibly they're more disadvantaged, than you will be in an interview, I mean you know you've got the skill set or you wouldn't be there, they might get turned away just for being salesmen). Now a door to door salesman doesn't get terribly nervous selling something at the door of their house. Why? Well they do it hundreds of times a day, and before that the practice their marketing spiel, and techniques for getting the customer on side.
Practice questions, practice those body language techniques, practice telling jokes, and generally getting the interviewer to open up. When you do into do the real thing it won't be a big deal at all because you've practically done hundreds of them.
Different people differ in how strong this effect is for them in an interview. I'm unusual - I actually relax. Whereas the author of this article tenses up. And, of course, once you're tense and you notice that you just flubbed something obvious, then you tense up even more. Leading negative reinforcing cycle. And if you experience this in one interview, you'll experience it in the next.
It does not matter how reasonable your questions are. If this is what someone faces, you do not get an accurate picture of how good anyone with interview anxiety is. And a lot of people suffer from this. The author of this article to an extreme degree.
Stressful situations happen a lot more than never in the real world (and sometimes they even involve talking to people, like customers) -- I don't want to have coworkers who can't handle that.
[>>>This is great when you've got to climb a tree to get away from a tiger. This is horrible if you are trying to demonstrate your ability to function mentally.
Climbing a tree won't get you away from a tiger; it's a cat.]
How a person does on a pressure interview certainly tells you something, but it would seem to put a high priority on a particular skill at the expense of others. It probably effectively screens out anxious types. I'm not sure you can generalize what you learn too broadly, though.
Describing a closure is actually a great example of something many great software developers WON'T know based upon their prior domain experience.
A strong Java or old school C/C++ programmer (yes I know C++11 has closures) may actually be an excellent candidate, but have no idea what a closure is.
I would expect that a front end JavaScript developer, RoR dev, or anyone else "experienced" in a language with some functional support (Scala, Haskell, F#, etc...) should be able to explain a closure.
No, the examples you listed are very different settings. An interview is far from a casual conversation, no matter the tone of your voice. An outsider is trying to prove themself to the group, they are under direct scrutiny at all times. One mistake can widely swing the interviewer's impression and cost them the job. No matter how many times you tell them to relax, certain people get into a feedback loop and it freezes them into inaction. Once part of the team being criticized for their code from other developers or clients is much less stressful, it's something they're ready to deal with. They are held with a certain level of respect for even being part of the group at all, and much less likely to lose the job/get fired in such a setting so the stakes are nowhere near as high.
By having an efficient technical interview process, yes, you let good candidates go. Just as you do by only having certain target universities or requiring certain experience. But they don't give a fuck. They get 1000 applications a day. Hundreds of internal referrals. If they were to reject the ~100 candidates/week that get hired based off doing well in their technical interview and take the next 100, Google Engineering would be just as well off. Maybe better. (Harvard says the same thing about its incoming classes).
No technical interview will ever be perfect. But if you have a holistic process that is 50% based on past experience, and 50% based on being a top 10% performer in well-designed technical interviews (among other factors), that's usually good enough to take a bet on the candidate.
Recruiter calls again a year or so after the fact. "You did well in your prior interview, but things didn't line up. Interested in coming back in?" Me - "The last impression left a pretty bad taste in my mouth. Not at this time."
Note - I was on internal referral as well as had apparently incredibly impressed the "phone screen" person (whatever that means). Of anywhere I have talked with, GOOG has been at the bottom of list in overall experience.
Also consider the fact that most companies are not google and don't have the same unlimited streams of top candidates coming in the door (is that even true for google any longer ?). A smaller operation (ie. the typical hn population) needs to work much harder to avoid false negatives. One way of doing that is to optimize the hiring process to allow a good candidate to shine vs the Google way of putting the candidate through endless abuse (I know what I speak of).
I doubt Google's false positives are better than anybody else's.
And if you are reliant on the false negatives coming back, and not being put off by the process, to keep your pipeline full of high-quality candidates, surely that has to be a risky approach longer-term. As Google loses its fast-growing-exciting-upstart reputation, and competition for engineers gets tougher, -- it's gradually going to get harder and harder to convince the best of the false negatives to come back into the process again.
There are plenty of students who are very bright, do outstanding jobs on their projects and homework, and otherwise get fantastic grades who then freeze up and get a C (or worse) on every test. Thankfully most real life situations don't mirror test taking, so often they're still high achievers.
Most job activity doesn't resemble a tech interview, so it's quite possible for this person to not freeze up ever after you hired him.
That said I'd still never hire this guy on the no false positives principle. I have neither the time nor inclination to contract with everyone who gets to that stage. But I rarely have projects for which a short term contractor could make much of a contribution. I suppose that's probably not the case for a lot of startups.
I am not a front-end web developer at all. I play with some front-end stuff occasionally. But if I had to work in that area I'm sure I could pick it up very quickly and become very effective. I think you need to differentiate between things people can read up on a day and catch up and things that are more fundamental to how they think and learn.
A lot of interview questions are also asked using synthetic examples that are not complete solutions. A good programmer will reach out and explore the full technical ramifications of the requirements instead of merely solving the problem. Knowing that complexity adds a whole new level of stress versus simply solving the easy problem the interviewer intended.
A lot of people have trouble sleeping the night before an interview. It's more stressful than anything they will likely encounter at your company because it determines a major, unpredictable branch point in their future. Unless informed their continued employment is at risk over the outcome of a meeting, client meetings will not have the same degree of stress.
I would never hire someone who bowed out of a tech interview. If you can't handle thinking through problems in a collaborative, relatively low-stress interview -- you're not the kind of person I want to work with, sorry.
Is there such thing? I doubt it, unless you're interviewed by someone you already know well.
Are you really saying that your developer meetings are as high-stakes as job interviews?
Most certainly aren't, but some are potentially higher stakes (especially with smaller companies), since you and coworkers losing jobs you have -- which can be the price of getting things wrong -- is a bigger stake than you not getting a job that you currently don't have.
If a person is interviewing for an air traffic controller position or any position with continuous stress and confrontation, well yes.
But if the job isn't a constant stress, constant demand affair but rather an affair of creative, constructive activity, then no.
Now, I suspect one problem might be that more jobs are becoming constant, chaotic stress affairs. In a large sense, that seems like a problem society has but that's just me.
This problem doesn't happen to me when I'm delivering a product pitch, speaking at a conference, meeting with investors, or any other situation where I'm on equal footing with my audience. Frequently, though, I ask to get back to people later with answers to difficult questions. I also prepare fanatically for those situations, where it's very difficult to prepare for a random tech interview.
A huge part of this is simply finding ways to stack the deck in my favor. A great interviewer knows that it's THEIR job to figure out what I can do well. Most people are not great interviewers. This makes a technical interview a total crapshoot that has never worked out for me.
My post is definitely suggesting that companies should examine their process to see if they're filtering for the right things. More importantly, I'm explaining how I've solved this problem for myself. Will I miss opportunities with my approach? Absolutely. I just now believe that I find better ones with my new method.
One caveat... I mostly consider a question like, "Can you explain what a closure is?" to be conversational. Simple knowledge quizzes are great fodder for a phone screen just to find out if someone even belongs in the room and whether they match the needed skills in general way. Where I get into trouble is with with whiteboard coding, brainteasers, etc.
We could have a great chat about async front end dev and then I'd stare blankly at you when you asked about CSS specifics. That's productive and tells you about my experience, though not my aptitude.
I am wondering 2 things: 1. How do you phrase it to a potential employer that you would prefer a take home project? Do you say you do bad under pressure? Do you say you think your abilities would shine though on a larger thought through assignment instead? 2. Do people have other strategies for dealing with such issues? Perhaps using a head hunter who knows the hiring process of each company, and can pass you along to ones with a less rigerous tech interview component.
Maybe I should just find smaller companies that have not figured out their interview process yet and hope they wont drill me.
"Pay me to contract on probation," sounds as if it's low risk for everyone, but it has stalled the pipeline for new candidates. It's not a reasonable request. If it were, then it would be a "contract-to-hire" position, and advertised as such.
I've walked candidates out because they've refused to whiteboard code. I'm very "hey, let's work out this problem together, and don't worry, I'm not going to compile the whiteboard, ha ha," so most people don't get too stressed out. If they do, that's where I step in and help them along, which is my job once they come on board as well, so they can get a feel for my style. It also helps separate the people with 10+ years of c, java, c#, and syntactically similar languages who can't differentiate between parens and braces, understand pointers, etc. The interview is where you can say,"would you do that differently if..." and see if the person has just had an interview brain fart or if they really don't know what they're talking about.
I've had a few candidates over the past 15 years or so that would just refuse to write any code. Certainly, I made the mistake of asking if they wanted to do some problem solving at the whiteboard, but I was flummoxed when the first guy (back at Amazon when interviewing at Amazon was perceived to be like interviewing at Google today) just said,"No."
And kept insisting. I'm a big believer in not wasting people's time, so I walked him out before he talked to the more senior people on the team, who were all working 24/7 to bring out (I think) auctions at the time. Looking back, it may not have been that big a waste of time. :-)
I think you're going too far the other way. Your argument basically seems to be "if you can't pass an interview, there's something wrong with you". Which is probably true. On the other hand, there's dozens of personality quirks (some of which are worse than getting nervous in job interviews) which wouldn't show up in an interview.
I have heard of anonymous classes. I've never used one on the job. Maybe that's a function of me being more server side and I think anonymous classes are use more heavily in Swing. Ditto for reflection -- aware of it and when to use it, but just never had the need. For better or worse, the pieces of functionality I've had to build out over the years simply did not require me to use those pieces of Java. There are countless of pieces of Java that I simply do not use, even if I'm aware of them.
A Java developer (at least in my circles) rarely just codes in Java all day. Often, they're using a framework. It might be Spring. It might be Hibernate. Right there, you have two vertical streams of expertise they could pounce on. Now add SQL. Even if you're using Hibernate, you'll still need some fundamental knowledge of SQL. Likely, they'll hit you with HQL questions. Maybe some lazy loading. Maybe some optimistic locking.
Maybe add EJBs. Maybe add JPA. Throw in some jQuery/HTML/CSS (unless they live exclusively in the server tier). Inevitably, some may ask about stored procs/PL-SQL. Oh what the hell...let's add web services, SOAP, REST, Ajax, JMS, transaction isolation levels, clustering, SSL. And so on. Wait...add Linux admin.
The disconnect (anxiety?) comes from a developer having to use so many technologies, which is realistic, and the interviewer salivating at the opportunity to go deep in any one of those.
"Excuse me...you can't write a static nested inner class? And you call yourself a Java developer?"
I once had an interviewer disappointed in not being able to ask me PL/SQL questions, despite me not even having PL/SQL on my resume. He just wanted to go there.
The interviews are often based on a notion that a developer does nothing else but use the language to its fullest. All day. Every day. Reality suggests that a developer uses only as much of a language as needed to build out a piece of functionality for a given need. They don't use every data structure available, nor necessarily every major piece of the language.
There's seemingly no way around this conflict. The interview is focused on a language. The developer is often focused on putting together solutions. Depth vs. breadth.
For the record, I had an interview once for a Grails developer spot and was asked about UDP. Yes, seriously...UDP.
We're not God. We're just developers.
whoever breezes through such technical interview, has either just had 20 interviews with similar questions and it's fresh on their mind, or studied specifically to become good at technical interviewing.. The latter is what i figured out that i had to do to stop being rejected from jobs i was clearly qualified for, just because i couldn't articulate something i never really had to articulate in the past.
If you freeze up during interviews because it's "high stress" then maybe you need to practice going on more interviews until it doesn't bug you any more.
When you're a developer -- especially at a senior level -- you need to be able to work well under stress. Hell -- you need to be able to do that for nearly any job in the world.
This is like saying "all drivers need to be able to drive well under stress, so let's test them while blaring a foghorn in their ear". Context is important.
I don't want to hire someone who is good at interviewing, I want to hire someone who is good at what I need them to do. While it may behoove the individual to train themselves on being better at interviews, as an employer it is a negative to wash someone out simply because they don't interview well.
Personally I rock at interviews, I've done easily 100+ interviews in my life at this point and I actually relax when I get into the room. This doesn't make me a better coder and it doesn't make me more qualified than the next guy who comes in with sweaty palms, and an employer whose heuristic uses interview-skill as a proxy for engineering-skill would be very misguided.
The entire problem with tech recruiting comes down to stupid proxies. We went through a phase where the top tech companies replaced real questions with logic brain teasers, as if that was a suitable proxy for real engineering ability. Now some startups are doing stupid shit like requiring extensive side projects, as if that is a suitable proxy for real engineering ability.
I'm not sure how many more years it will take for tech as an industry to realize that the best way to know someone is good at X, is to get them to do X.
It's easier to understand if you think of it like a phobia - someone may be irrationally scared of spiders, but that doesn't mean that they are going to be scared of heights, clowns, dogs, and snakes too.
Add to that the fact that most tech interviews are held in non-real world situations and it's easy to see why some people have problems. Putting a person in a room with a piece of paper with a chunk of code that has a 'hidden' flaw with no access to any other resources isn't real-world.
All of us have access to books, manuals, the code, google, any number of places we can use to help.
And usually these interviews focus on nuances of a language or a programming trick that you only know if you've seen it before or encounter it regularly.
The codebase I'm working on now targets the iPad. If I were to interview with a company and the tech reviewer asked me about an IE specific hack chances are it would take me a while to come up with it. Assuming I've encountered it before.
Personally I have no issue with stress. It actually brings out the best in me. I do realize however this whole thing is a game. When I interview others I try to be aware of these factors and get at what I really need but I'm not 100% immune to being in a bad mood etc.
One day I should blog about how to interview. That's a fun subject to write about...
You can do those in a half hour initial phone screen. Getting an idea of the applicant's general and/or domain-specific technical competence before you fly them out absolutely makes sense. I think what the author is criticizing, or at least the part of the author's criticism that I agree with, is the typical on-site interview that spends 3+ hours testing one's algorithmic knowledge and whiteboard coding skills. I do think that approach is vastly superior to doing nothing at all, but my personal experience suggests that testing the applicant's skills in a real life situation, after having vetted their technical knowledge/competence over the phone, seems more likely to identify strong engineers.
Imagine you've been applying to jobs for over half a year (180ish days is the average time it takes for someone to find a job these days), maybe you've had a couple of interviews, maybe this one is your first. You have burned through your savings, maxed out your credit cards, and you are less than a month away from missing your rent payment. When you're in such a situation, every interview becomes the single most important event in your life. If you fuck it up, you might not be able to put enough gas into your car, which you very well may be living in, in order to get to the next one. Trust me, if you've ever been in this situation, it's pretty easy to get freaked out and sound like a fucking idiot in the middle of an interview. It doesn't say anything about a person's ability to communicate in a routine business scenario.
The primary filter for me these days is the pair programming interview. Can they make something? Do they think clearly about what they're making? Do they ask good questions? Can they explain why they did something, and what other options are?
If you truly have only a day or two to get somebody up to speed, then sure, you need somebody who is already intimately familiar with every technology that you use ... but if it's a gigantic project, you're probably going to have a bigger learning curve than a couple of days anyway.
However, if you're looking for the absolute best person you can get for a job, you shouldn't write them off because they haven't had experience with a specific technology. More important is that they have a solid understanding of algorithms, data structures, and various design architectures, have exposure to a number languages, and are capable of rapidly assimilating new concepts. I'll take the lightening fast learner over somebody who knows a few specific techs _really_ well any time, because the lightening fast learner will _also_ learn the specific quirks of my project quickly, whereas somebody who has a difficult time with new concepts but happens to know the right techs might struggle for a long time just to come up to speed on a large project that somebody else created.
Any part way competent interviewer knows the difference between a bad interview and nerves getting the better someone. When it's nerves we're not thinking "they're awful", we're thinking "i don't know how good they are".
At that point I'm generally too busy to try and come up with a bunch of other things myself on the off chance the person will respond better to a different situation BUT if the person were proactive and came back and said "I know I screwed that up, would it be possible to try X instead", I think I'd be open to that.
(That said obviously giving small paid projects work to all potential interviewees doesn't scale particularly well.)
The biggest problem with testing knowledge than checking their work is, you ultimately end up hiring a lots of people who know(or atleast act that way) everything but can do nothing.
No because the interview process is designed to uncover where you're weak. It's a systematic way to figure out what you DON'T know. Other situations are not (at least not overtly).
For someone with inferiority or self esteem issues, this can be a very threatening situation, and totally artificial and unlike a normal working relationship where your intellect and skills get the benefit of the doubt most of the time.
Interviews strip away that easement and raise even the slightest possibility that you might be full of shit. For most people that's easily managed by their ego but for others, not so much.
The author says "Other times I just froze on topics that I
know very well." Maybe somebody can explain this better to me
It's only when I see peoples flaws that I can operate around them. Only when I know they are not perfect. (By the way I realize this is illogical behavior, I really can't help it, I'm ascared T.T)
I don't think this is anything new, I'm timid around new people. That doesn't impair my productivity, it just impairs how attractive I look as a hire.
Developer meetings are about the issues at hand. Code reviews are about the code. Client meetings are about their problems and ways to solve them. Presentations are about the topic you're presenting. Selling your teammates on an idea is about the idea and its merits. Interviews are about you.
(Incidentally, getting a person to go out with you, as some other poster mentioned, is about you. It is also a well known source of major brain freeze.)
First, I'll ignore the fact that contributions can be made to any stack far sooner than "months". It's uncommon for companies to be so incredibly short-sighted. In tech, the hiring goal is for talented people who will contribute for a long time (1 year+).
The company he mentioned was able to get 10 hours worth of work info on him this way.
Personal anecdote/case study:
I interned on the frontend team at Mixpanel in 2011. I had written about 200 lines of Javascript prior to starting work, not a ton of HTML, and literally no CSS. I had however done quite a bit with Python/Django (which they used). My first month consisted of me "getting up to speed" where I was working at a lower rate than others on the team. By the end of summer, I was a fairly productive member of the (3 person) team, building products with tools I had previously had very little experience in.
Fast forward 2+ years:
I've now done 2 years of college. I spent one summer writing distributed machine learning tools for fraud detection, and another summer during deep learning research. The majority of my computer science classes are just theory (no programming), but I've done a bit of programming in C/Python/Rust (for a choose your own language thing) for school and also a bit of programming in Python on the side. Now I apply for your frontend job.
>I'm going to ask them to explain how a closure works
Closes over internal state, talk about read-only (Python)/ read/write (JS) closures and how read/write closures allow you to make basic objects out of functions.
>How they deal with AJAX
Use a callback? Not sure what this question is really asking. Potentially do some kind of client side queuing for some special cases. How to implement server-side push is more interesting.
> What they think about "!important".
Overrides all other CSS rules iirc. Not a best practice thing to use, but still a useful hack to keep in the toolbox.
> Things to be careful about with floats.
I don't remember specifics, but I remember floats can be a bitch. Just Google any problems I'm having. I believe the type of container that floats are in matters.
> How CSS precedence/specificity works.
Could probably work out an example. In general, element inherits all rules that apply to it, and more specific rules overwrite less specific rules. I don't remember the non-trivial ordering for more specific -> less specific (ie id is more specific than class), but would be very easy to look up.
> How to architect a webapp
Would be more comfortable talking about the server-side component, but could talk about client-side code design.
Summary: I'd probably do alright but not exceptionally on your interview. You might give someone else the job. They would probably be more productive on day 1, but I don't know about by the end of week 1.
The twist: If I was interviewing for a frontend job, I'd take a few days to study all of this stuff and significantly increase my interview performance. Would that make me any better at actually doing the job? Probably marginally.
I like the twist of doing the contract off site on the developers own time.
Every time I see someone on hacker news saying, "we've solved the interview problem. We just require every new hire to give up their old job and contract with us for a week to see if they are a good fit", I often wonder about the quality of the people they hire as I have yet to run into a talented dev who would quit their current job to do this one week contract for hire option.
Doing contract work via take home seems like a nice balance here as even people with kids have 2-3 hours free after kids go to bed. Done over a few nights in a week makes much more sense.
Initially, I was going to react negatively to this (as a father of two kids under the age of 11), but the more I think I about it, the more I like it. I assume that if I was scheduled for a technical interview, I'd likely spend at least 10 hours preparing for it (with perhaps only a bit of assurance that I had prepared properly). If I were given a ~10 hour contract project, I would know the problem up front, and be free to complete it without the stress of a whiteboard session.
I wonder that, too. The very best people usually have a job that they like well enough, but might change jobs for a real offer.
"Quit your job and we will probably hire you" is not so attractive to experience people, who are usually no longer in their 20s. Even if a developer were inclined to give it a go on his or her vacation time, most employment contracts require notification for taking on additional employment -- it is rather awkward and annoying to the candidate to jump around these hoops.
Personally, my brain is completely fried by the time I get home in the evening.
The other irritating thing is that people seem to prefer selecting people who are technically more intelligent than they are, but who are less socially apt that they are. It's so bad that I think entrepreneurs need to think about protecting their employees from themselves, because this cannot possibly be good for companies in the long run.
Lets just face it. Engineers often times have low self-esteem (especially compared with "business types")(edit: myself including), and interviews frequently become the one place where they can be on top. It's always re-posed as some "meritocratic" test of skill (isn't it always?), and it's anything but, because an interview setting is not effective at measuring whether someone has the initiative and creativity to get a job done.
Because they have some decent points about how the interviews they've been in have been flubbed by the people conducting the interview, but they seem ENTIRELY inconsistent with my experience at any place I've interviewed ever, and I don't think it's my experience any time I've conducted an interview either.
Maybe I'm just not working in the wrong part of the industry? I mean, I think I've gotten some variety in interviewing, like: Silicon Valley - a small-to-medium networking software startup, and a small social media startup. Seattle - Amazon. NYC - Bloomberg, a tiny mobile-software company, and a medium-size very-late-stage media startup.
... and they all have about the same in-person technical-interview processes, which is to say, a little bit of talking mixed with a series of exercises like: here's a toy question, go solve it for us. I say "okay, here's what I'm thinking, X Y and Z, this what you mean? do you care whether it's built more like this or more like that?" start throwing some code on a whiteboard, etc etc
I think I hold the record for bad interviews amongst my friends when I was asked to write my traditional Chinese name on the whiteboard. I'm not going to pull any punches here. I've simply lost faith in the interview process, and in the way we vet each other, and the way that we manage and communicate with each other, and I think that a core root of it is how we approach the interview process. The valley was supposed to be a collegiate and egalitarian environment, and I hope we keep it that way.
For most people, cooking and eating aren't a big deal. Others create Soylent because it's too much to bear.
For most people, the standard interview process is fine. For others with self esteem (or other) issues, the process is so threatening they have to opt out entirely.
If I don't know the answer to a question or if it is ambiguious, I tell them. For example, I was once asked to describe how a TCP sessions ends. Well, that's implementation defined. What OS? Are we talking FIN ACKs or do TCP resets count as ending a session too? The RFC may say this, but in the real-world, software sometimes does it like that. Etc, etc.
And, many times the questions aren't made to be answered, but to draw things out of you (like the one above). And in these cases, you can turn the questions back on them. Put them on the answering end ;) and that's OK, those exchanges tell both sides a lot about the other.
I do like a few black and white questions. Like, "How many bits are in an IPv4 address" or "What data structure is a C++ set typically implemented in" and if candidates have no idea on an answer, then I do have concern over that. However, if they do not know the answer, but understand types and their sizes and data structures and their pros/cons, then that's good enough in some cases as well.
But either way I would've never had a problem with something that simple sitting here at my own computer. Did the interviewer understand that it was just an interview fluke? Probably not. After all, it was such a simple thing.
So I would warn against believing you can see past people's interview issues. Companies in general seem to have a misplaced level of confidence in their hiring processes, even assuming their proxies for intelligence weren't naive.
They do, and they will count it against you. (A few people in this thread have actually said this)
I may be one of the most contrary programmers here on HN when it comes to this subject. I have never shared code or given references before a job offer and I never will. I believe that reviewing code that's already been written has far too much risk for any benefit; permissions may be required, explanations are often needed (but never given the opportunity), and most of all, taken out of context. I want a prospective employer to do their own work to evaluate me, one on one, without depending on other code or others' opinions. I will do whatever it takes to help them do this, including interviews, meetings, and yes, coding for them.
As an interviewer, I have used many tools to get to know the interviewee, but the coding exercise has alway been, by far, the most important. If you can code, great. If you can't, I'll find out. If you struggle, no problem, we'll work through it. But I have to know, otherwise we can't move on.
The trial project is a great idea, but for many reasons, it's not an option for many employers.
Do whatever it takes to get past the roadblock of not being able to do a tech interview. There are plenty of resources to do that. If you struggle and your interviewer is a jerk, then no problem: you didn't want to work there anyway. If you struggle and your interviewer helps both of you to solve the problem, then you've both learned a lot about each other.
(Also, please try to avoid language like "I will not...". Except for murder and ethical issues, this will probably hurt more than it will help.)
Yes, I think our concerns are different than the OP's.
A scenario that has played out for me is that I get an e-mail or call from a headhunter. They want to send my resume to a company. The company likes my resume so I get an interview. Right away they want three (or sometimes more) references. Often they say they prefer, or even require, that they be managers. Obviously this means I have to contact my former managers and co-workers. I have to make sure I still have current contact info for them for one thing. I also want to give them a heads-up that someone might be calling them for a reference.
Perhaps I'm not asking for a big favor but I'm still asking for a favor. So every time I go on a job interview, I have to ask several people I know for a favor. Some of whom I might not have had much contact with in the subsequent years. Then I have to contact them out of the blue and ask them if they can give me a reference (I usually do keep in contact with people, but don't want every other contact being me asking for a reference or a favor).
Like you, I think it's understandable if the company is about to offer me the job and as a last step want to get some references. But I have people telling me they want to talk to my former managers before I've even had an in-person interview.
Compared with this, someone grilling me on data structures, or paging, or TCP/IP behavior, or whatever is pretty minor.
Having said that, I think that an at-home project prior to the interview is useful both for pre-screening but also as a sanity check on the conclusions of the technical interview - if someone blitzes the project but flunks the interview that would make think that maybe the issue was the interview (or the interviewer) and not the interviewee.
Lastly, I think that if someone is aware that they do not do well at technical interviews then the best way to deal with this is be up-front with the interviewer, and try to bolster your case by having some code (perhaps on Github) for them to review. No-one I know likes an awkward or failed interview - we want people to succeed - and if you're honest with me about the issues I'll take that into account.
Also, I believe there was an article posted here a few weeks back that indicated Google's brainteasers did not lead to quality candidates - I know I am cherry picking something that supports my beliefs but it was here nonetheless.
Also, I have interviewed a lot of people with 4.0 BS/MS in 5 years that turned out to be horrible employees. They were awesome with the brain teaser questions but sucked when they actually had to build something.
I guess I do not see how you can lose if you take the contract-to-hire approach ..
I agree with most of what you said, but one way you can lose if you insist on contract-to-hire is that you are filtering out a portion of the highest quality candidates who are only interested in immediate full time hiring.
No one desires to be in a contract limbo where they aren't sure if they're going to be hired for real or or if they're doing the job search all over again in a few weeks.
Further, as soon as you use contract work to determine hiring criteria -- you've added your management into the mix. Are expectations made clear? Is the person's time managed efficiently? If management fails at any point then it's detrimental to the prospective employee's future, likely not by their own fault.
It also gives the candidate a way to see what kind of problems he'd be working with, and the quality of the code-base, working conditions, etc.
I think it's a win-win.
if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) - well, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply.
Yes, false negatives, people with horrible IP agreements get screwed, etc. False positives are much worse than false negatives in the common business wisdom.
I loved software engineering so much that I decided to turn it into a career, so that I could do it every day. But now you want me to do it every day and every night? No. My work during the day is fulfilling. My hobbies provide variety and an opportunity to pursue other interests.
I don't understand why technical interviews are not more oriented to "how would you design X? Ok, what objects? What interfaces? How does that work, explain like I'm your 10yr old nephew? Ok, pseudo code that part. What are challenges with it? Have you coded similar things? Tell me about one. How would you do it different now? How would you convince me that it's worth refactoring? How about if I was your peer and I told you your idea was the worst thing I'd ever heard? Ok, now assume I'm working for you, and it's my second week, explain how to write your new design from scratch, and what some gotchas I should avoid are?"
We all know that green field coding is a rarity, and most time is spent writing/running tests, refactoring, bug squashing, design writing, code reviewing, team managing (always at least upwards and sideways). Most of this is still "technical", but seems to be overlooked with endless stupid brain teasers. I know what Knuth volumes are, I know what google is, and I know my basic algorithms. Most people don't need to have memorised how to implement random algorithm x.
This is why we at Google don't (or shouldn't, at least - it's widely discouraged) ask brainteaser questions in interviews.
I disagree on whiteboard coding though. I don't find it that easy, but I think it's reasonable to expect a demonstration of relevant skills before you hire a candidate. Any sensible interviewer won't expect syntax-perfect code on a whiteboard, but it's at least a way of seeing if the candidate can walk the walk rather than just talking for an hour.
> I guess I do not see how you can lose if you take the contract-to-hire approach ..
For the first month, the vast majority of people are relatively unproductive. After the next month, good candidates are generally still going through a significant learning curve. Contracting several candidates for a few months to pick one who seems good enough is expensive for relatively little output - apart from salaries, they need desks and computers etc, and you have to do some interviewing to pick them in the first place. It's not a worthless approach, but I don't see it as a panacea.
Which I have argued many times on here, should be glaringly obvious. Measure what you want to measure. I have never said "I'm so happy we hired Jane, she just tore up that smart pointer implementation yesterday". I like and dislike colleagues based not on comp sci algorithms, but whether their code is readable, how many bugs are in it, how quickly they can produce production quality code, whether they are responsible and hit deadlines, if they ask for help when they need it, if they offer help when other need it, if they are creative, if they are doers and achievers, if they take baths (seriously), if they step out of their office and interact once in a while, if they are problem solvers, if they read and keep up with their field, if they are capable of learning, if they write good documentation, if the client likes them, if I like them, if younger people look up to them, if older people feel some pressure because here is somebody up and coming, if when I go to modify their code I only need to change it in one place, and my change fits in naturally without breaking 15 different things (because it is designed with extensibility in mind), and that my heart beats a little faster because their code is just so beautiful. And so on.
Google doesn't try to measure any of that. At all. And then you (google, not you archangle_one) express mystification at why your interviews do no better than chance. There's a clue there, I'd say. If you don't measure job performance, why do you think your measure say anything about job performance?
Every issue the author mentioned can and should be mitigated by a decent internal recruiter or manager. Essentially whoever initiates the contact with the developer maintains a responsibility to ensure that their 'candidate' is as comfortable as possible throughout the process, regardless of who they are meeting.
I've dealt with plenty of people who suffered from the exact issues the author describes. It's a lot more common than you'd realise. I've also dealt with rare occasions where I've helped candidates with autism, aspergers and even down syndrome through the interview process.
If you form a decent rapport with your candidate and truly comprehend what they really want from a job with your company as well as 'grok' their personality type and limitations then there really is no excuse for dumping them into a situation where they feel so stressed and under pressure that they shut down.
Your responsibility doesn't end with the candidate though. It's equally important to ensure that the people who will be interviewing this person after you have a decent understanding of the type of person they are about to meet and to ensure they are equipped to deal with a situation where the person being interviewed begins to crumble.
As for references to previous submissions and comments where people claim to have "solved the interview problem", I call bullshit. Every company, every hiring manager, every team, every job and every candidate is different. The silver bullet to 'solve' the problem simply doesn't exist and never will. Sure there are companies with fantastic processes but for every 'perfect process' you show me, I can show ten companies where that process simply wouldn't work.
The best thing about these discussions is that it encourages people and companies to simply try harder and that's never a bad thing.
What I worry about most isn't that the contemporary coding interview creates false negatives. What I worry about is I suspect that it unevenly creates false negatives.
The interview process is broken and many of the interviewing techniques either do not correctly judge a candidate, or place too much burden on them. I guess the reasoning is that a false negative is better than a false positive.
I did a 5-7 hour programming homework assignment, didn't hear back for weeks, and then it was just from a recruiter (sorry, we've decided not to continue the process).
I won't do it again, ever. It's not the wasted time that I regret so much. I do agree with you that there is a self-respect element to this.
I doesn't seem unreasonable to me to ask even a senior developer to do a small coding assignment as part of the interview process unless they can show a good, relevant coding sample.
If we're going to agree that whiteboard coding isn't a great way to evaluate someone, and we can't ask you to do an assignment on your own, what else is left? Talking about past experience is great and an important part of an interview, but I think most people want to (rightly so) see some code at some point before extending an offer.
Not OP, but it doesn't "feel" like working for free. It is working for free.
Having someone perform work for you without paying them is illegal in the United States (see minimum wage laws).
There's a simple solution; pay them $x per hour to do your 3 hours of work. Even if you pay them $100 per hour that's a cheap way of filtering out pre-screened candidates.
I'll do a take-home programming assignment anytime over an in-person interview to gauge mutual interest.
In that case, I would think I was the subject of a psychological experiment entitled, "How far can we push developers".
Although it would be tempting to accept the offer and then write whatever code they asked for in QuickBasic 4.5 (circa 1988) telling them they need to use something more stable than the crap they're using.
I've only ever answered one interview question in Scheme, the problem was perfect for it. :) I first had to check if the interviewer knew Scheme, and he did!
I fear it has been long enough that I could not repeat such a stunt now days, but last week a resume came by my desk that had LISP listed on it, so I prepared some problems that would be trivial in LISP just in case. Unfortunately it was as I had suspected, a stale language listing that should have been removed from the resume long ago.
I've been a dev for 10 years and worked in Sydney, London, New York & San Francisco. What I noticed is that San Francisco has a very different "technical" interview approach that is very CS focused. I studied a CS degree (7 years ago) and think it's stupid that I have to dig into knowledge that I have not needed professionally over my whole career.
I've built successful startups, coded mamoth apps used by millions of people, but failed interviews at companies like Yammer.
I wrote a post about how I conduct technical interviews for my company airpair.
http://hackerpreneurialism.com/post/43661666180/how-i-conduc...
Pair Programming is KEY.
Also, side plug we've been getting lots of business both around preparing for interviews and helping to interview candidates when you don't have in-house knowledge to vet skills you don't have.
Here are some examples:
http://airpa.ir/1d5sqR6 (Need help reviewing candidates code)
http://airpa.ir/1dteU8H (Need help interviewing an iOS candiate)
http://airpa.ir/173ily2 (Needed help preparing for JavaScript interview)
Let's do the opposite of all these things!
I've recently started writing down an attempt at providing a better replacement I hope to begin following and enforcing 100% without exception going forward. My own system has similarities to what the OA advocated. I call mine RYR, which stands for "Realistic, Yes-Finding and Reciprocal."
On one hand, you are valuable developer, they went through a lot of trouble to find you. What you are faced in the interview is often far from ideal. I did ran into exceptions, but it is still more a standard then exception to encounter what you eloquently described.
I feel this is different than in almost all social interactions, such as working with clients or participating in meetings. There is more equality and control in those kind of negotiations.
So for me, I really want to interview somebody before he can work with me.
But I love programming languages and software development, so I do contracts from time to time, which always go well. Unfortunately, I've not yet done a contract that was actually for a company that was actively hiring employees (most were for small businesses with no full-time developers). But this post has given me some hope. If there are companies willing to let a candidate work on short-term contracts to prove their worth, that means there's hope for me yet to be able to move into software development full-time.
well, welcome to software engineering. The interviews are for the reason, they let you peek into your future job. If you can't manage that environment for 4 hours of the interviews, how you're expecting to manage it for many years if/when you get into software engineering?
I'm not trying to be mean, i'm just warning that something like having a fresh out-of-college arrogant Millenial reviewing your code means - well suffice it to say that at my previous job it drove 6 out of 8 person team in 1 year, all from mid to senior engineers, me being 7th, to either change the team (3) or leave the company (4). The guy is a pest, smart, driven, high GPA from top University...
Many interviewers are poor at doing interviews. :(
I do not try to trick anyone in any interview I do. I put forth a problem and ask people to work towards a solution. If I feel the solution can be improved upon (not necessarily to get the answer "I want", but in an overall sense of software engineering) I start asking exploratory questions about why some piece of code was implemented some particular way.
I have a set of questions I ask every candidate that comes through, the questions start off easy and work their way up through a progression of difficulty. None of the questions are me thinking I know how to do best, and on 2 occasions so far I have hired people for at least in part giving better answers on the questions than the solutions I knew.
As for confrontational, I try to remember that almost everyone is below optimal during interviews! I get nervous during interviews as well, I don't expect people to be at the top of their game and nail everything, silly mistakes that normally would get filtered out before fingers hit keyboard end up being put on a white board for fear of time. I get that, I do the same damn thing when being interviewed. :)
I'm sure there is a lot of that out there, but that is definitely not my reason for asking hard questions.
We will always be interviewing at least a few people to fill a position, I think that's natural. Suppose I ask you and the other candidates questions... and you all get them all right. Well, that's fabulous, but now I have no way to distinguish which of you actually knows more about a particular subject.
And I think it would be stupid for me to ask the interviewees to answer questions to which I don't know the answers.
So we're always going to be in a situation where I'm asking you at least some questions that you don't have the answers for. I need to test your limits, and see how firm a grasp you have on various subjects.
I gain much more insight into a person by asking them to describe a large system they've designed, what choices they made, the effects those choices had, ect. How did their initial assumptions hold up through the course of the project? How did they adapt to changing requirements? These are the things you can't find the answer to in 30 seconds on stack overflow.
I think the attitude of "they should hire me, since I can learn anything" is self-centered. There are a lot more people that can't learn. Without testing methods available there is no way to distinguish the self-starters from the frauds.
In my own current position, I would not have gotten the job if they had interviewed me then like they interview new hires now.
Don't know how to find and recover active but deleted files? Goodbye. Don't know how to follow strace around a distributed environment? See ya. No idea how the elevator works? Why are you even applying?
I know how to do all of those things now, because I asked questions of my colleagues and the internet. I'm now the lead developer, not because I knew everything coming in, but because I am able to learn.
Recognition is easier than rediscovery.
btree index is also something that can be learned conceptually in about 10 minutes.
It is far more important for me to see that someone can explain a project that they've worked on in the past with enough details to demonstrate sufficient technical knowledge than a litmus test based on somewhat arbitrary facts. 'don't know what lsof is? Not hired, I don't want someone who can't use shell'
Why? You just answered it well enough. There are people who could not say what you just said; you don't want to waste your time on them.
I blanked. They just handed me the laptop and didn't even tell me it was a test. There were some comments at the top of a few javascript files and like an idiot I answered the questions verbally. The two devs just sat their smirking at each other like they'd won at something.
I'm not averse to tech interviews, but I do not enjoy the "look at how smart we are that we caught you out" attitude that comes with them. I'm shit at crosswords, that doesn't make me illiterate.
I've since been keeping an eye on their work and now I get to feel smug because it's been universally panned.
I also had to sit a test for what I call "the worst agency in the world" (AKQA and after 7 hellish months there I'm happy to stand by and put my name to that assessment, they're simply awful). I forgot to specify the radix in a call to parseInt. It was the only flaw and while they didn't make a big deal out of it, the interviewer was clearly pleased with himself for finding it. They then proceeded to ask ZERO questions about why I'd coded the test the way I had. Which is a shame, they might have learned something.
In my experience, there's nothing wrong with tech interviews, but there's a lot wrong with the people administering them. If I want to know wether a dev knows what they're talking about, I ask them to explain something they've already coded. If they can explain it, they understand it, and I usually learn something to boot. Everybody wins.
Off-site contract work is NOT a solution. Hint: the candidate may not be doing the work himself; he may be farming it out to oDesk or Elance at a fraction of the price and playing WoW all day.
The point of resumes is to see if the candidate actually has the requisite skills for the job. The point of interviews is to verify what is represented on the resume is likely to be true. And, as the op is suggesting, a small contract would verify that the candidate can complete projects for the company and to their satisfaction.
he may be farming it out to oDesk or Elance at a fraction of the price
This is just plain paranoia. No one would do this and expect to be employed at a company for very long. Also, if you've ever farmed work out to oDesk/Elance, you might not want that work to represent you in an interview process (even if you were able to have it completed in a reasonable amount of time).
Also, after they have submitted it, go into detail with them as to why they did this, or why they did that. Tech interviews with puzzles, quizzes, and logic are just a massive waste of everyones time.
And if someone at oDesk or Elance does that nice of a job you should just hire them.
"Hey, as I'm sure you may understand, these sorts of on-the-spot interviews are a significant departure from the day-to-day environment under which I normally perform these sorts of tasks. I know this stuff well, but still might fumble a bit because of this atmosphere. Do you mind if I talk through this problem with you as I would if we were working on the job together?"
Short contracts can be great when you can afford them (ie, have time/are not currently otherwise engaged), but sometimes you have to work within the framework provided. Being your own salesperson is not all that complicated: manage expectations, build rapport, and under sell/over deliver.
A good recruiter can help fill in these gaps for you -- pre-setting the hiring managers expectations, coaching you up on interview strategy and tactics, and helping you understand a given company's interview process in full so you can mentally prepare. Unfortunately, most recruiters are not good and dealing with them tends to be a pain. We're building a better recruiter, online, at Mighty Spring (https://www.mightyspring.com). You control the whole process through a web interface, and simply request contact when desired. We're geared towards engineers and are currently in private beta. Will expedite invites to HN signups -- feel free to email me (address in profile).
I know recruiters have a bad reputations among most developers, but someone like that would be worth their weight in gold to me.
All managers dream of robots that can read minds and work for titles but lazy managers prefer to hire those who do what they are told, even if its pointless, even when done poorly or without imagination.
A good manager is worth his weight in gold. "I will not do your tech interview" while offering a short contract is an excellent way to screen out the lazy managers.
There was a huge emphasis on avoiding false positives in the interview process - largely because a single bad hire can do great damage to a software development team. But people seem to be learning that these grueling processes may not do as much to avoid the false positives as we thought, and are creating a vast number of false negatives.
I am no longer interested in participating in this sort of multi-day technical exam taking. I've studied stochastic processes, mathematical optimization, data structures and algorithms. I've taken exams on them. I've hit the books for a couple of weeks prior to interviews where I've been grilled on these subjects in greater depth than I experienced during my exams in grad school. It's important knowledge, I get that, but I don't want to have to mentally reload the material in "exam ready" memory simply to pass yet another interview. I will rely on my general knowledge and my ability to look things up on the job. My interviewers should feel free to evaluate my knowledge, but does this really have to be more grueling and take four times as long my final exams in college/grad school?
It's not that a technical screening isn't valuable, it's that the grueling nature of these interviews means that if you can't recursively print out all permutations of a string on the spot, right now, don't get confused up there at the whiteboard, you're a no-hire. It can be very clear that the interviewee is aware of what mergesort is, how recursion works, the importance of run time in algorithms, and that the candidate almost certainly at one point implemented it. They want to see it, now, in code, on the whiteboard. Or, these days, typed into a screen that an interviewer is looking at.
A couple of years back, last time I was looking for jobs, I spent one and a half days in interviews. I was asked to code a singleton, add a branch to a binary tree, traverse a binary tree, now without recursion please!, find the long term probabilities in a markov chain, formulate a linear program and prove that the dual of the primal is the primal of the dual, now with matrix notation please!, write a bunch of outer joins, convert a curve into a piecewise linear function (don't lose convexity, please), on and on. Each interviewer was fresh, I was shuttled from room to room. Then I came back for three hours of interviews with management. No hire.
Another special one was where I only got to talk to a recruiter, passed a few java tests (about an hour), and then took a homework assignment (spend no more than 5-7 hours, please!). Didn't hear back, didn't hear back, didn't hear back. About a month, and the recruiter calls, oh, they've decided not to pursue this any further.
This is a rant, and perhaps an angry one. I feel bad about that, and it doesn't feel great to admit that I've failed in these interviews, either. But I'm glad that some pushback against this practice seems to be building.
On the bright side, in my most recent job search, I've noticed this type of interview style has become a lot less common. It still happens at the big SV firms (for example, I spent an entire hour phone interview doing multiple algo code problems and not once asked about my experience), but I think the smaller companies avoid it.
Edit: Or it could be that "school's out for summer", and there are a fresh new batch of grads, masters grads and PhD's on the market.
Can I have money now?
I had an interview with a small startup I adore and had to code a simple python scrapper with the startup's CEO. I was so freaked out I totally bungled it up. Needless to say, my confidence went down the toilet.
I think I should accept that I don't do the traditional tech interview well. Next time, I find myself in such a situation, I'll suggest the short contract or coding exercise.
https://news.ycombinator.com/item?id=5227923
I've posted here on HN from time to time, which I expect to add to my personal website in a while. A job candidate who doesn't want to do a work-sample test is a job candidate who doesn't want to work for a smart employer.
The UK civil service used interview boards consisting of a manager of the role, a subject matter expert and an independent person from outside the organisation. It is an inherently high-stress situation for the candidate due to the numbers involved and and usually due to the room layout.
I was trained to account for the stress reactions and see past a freeze due to the situation and focus on clear demonstrations of skill and experience. If anything we were trained to try to make the candidates perform at their best in the board rather than probe to see their worst sides.
It was complicated by the fact I was employed in a highly technical specialist team (It was a military research agency) and few people we interviewed had any experience of what we were planning to employ them for.
We also consciously went beyond a general knowledge test and focused on how the candidate thought about answering questions rather than if they knew every technical detail. In that role technical detail was only a man page or a conversation with a colleague away if you know what you didn't know and were prepared to ask for help.
Any interview that stresses the candidate, quizzes the candidates memory of detailed technical facts and doesn't work from the premise that it is a high stress artificial situation is not going to provide a valuable outcome for anyone involved.
Edit: My best question to identify general technical competence starts with "Can you describe the TCP handshake?" and if they know is quickly followed up with "Why is it like that?". Unless there is role specific reasons to know TCP then it doesn't really matter if they don't know, if they do know I am really interested in their answer to why it is the way it is. Many even quite senior candidates have never considered it before and watching their process of thinking about it is very instructive about their ability to think about technical details in the abstract.
a) Acknowledge and minimize the unavoidable stress of the situation.
b) Use more general questions where candidates can choose their preferred approach.
c) Allow them to show their strengths instead of seeking out weaknesses.
You request this because you can't tell from the URL, yes? Do you have some authors you'd have a greater desire to read?
I just got my invite to Medium and on some research saw where a notable dev (who's name slips my mind) was moving off then platform for a few reasons and I believe the URLs was one of them.
Now seeing your request I am thinking this is an interesting situation where it sort of levels the playing field (or could cheapen the experience) since you don't know who you're going to read based on the Medium URL.
It sounds like contracting might be what the OP wants to do more than employment if he's so good at selling that and not interviewing, but also not keeping those jobs long enough.
Or maybe I misread it? Sounded like he was hired a number of times for jobs, but went back to interviewing not long after anyways.
I've had similar experiences to the guy who wrote the article. Something about interviews seems to make my heart race and I can stumble on very simple code. This is in strong contrast to how I am in normal social situations where I am highly confident and my personality is often infectious and passionate. I think it's a case of high anxiety in authoritarian/test conditions. Those that imply their working conditions are similar to interview conditions make a good point, however if that is the case I would prefer somewhere less confrontational and more forgiving.
Generally I prefer proper timed tests [0] without anybody watching. This is how I normally work.
I'm also one of those people that has to constantly look things up; actually I have a broad range of experience but I often find myself delving deeply into things I have only cursory knowledge in - imagine a librarian that remembers the locations of the books in a library and the analogy to knowing high-level concepts that allow thinking on your feet when used together with the correct reference materials.
Of course I believe that it's better to be good at making do with limited information. Understanding things from scratch is what I have been doing all my life. Like a chameleon when I look at some code that I did not write, it becomes my syntax and I quickly understand the contents. However different organisations and cultures sometimes prefer different kinds of engineers: there is either a preference towards robustness or flexibility [1].
[1] A test I would excel on would be being passed code in an unfamiliar language, domain, library or ecosystem and being told to quickly get to grips with it and add features/fixes (aka. flexible knowledge: unfamiliar territory which requires me to pull together a broad range of skills.) This is opposed to being passed a piece of code in a familiar language, domain, library and ecosystem and being told to quickly and robustly add a feature or fix to it (aka. robust knowledge: familiar territory which requires only a very specific set of skills.)
Disclaimer: My parents are non-native English speakers and I can't understand a thing they say over the phone, but in person I have no trouble.
We have these differences--linguistic, cultural, even physical characteristics--that are huge. The differences that highlight a lack of shared background/experiences/origin/etc. can be found not only to be at play between, say, native and non-native speakers of a language but even separate groups within the same culture. You see that in how we handle subjective feelings of personal space, for instance --we Americans, for instance, tend to prefer greater personal space over say Scandinavian or certain East Asian cultures. But the fascinating thing is how those expectations can shift based on region, and on an even more micro level, affluence etc.
Even when the differences are minor, such as say race and skin color, the effects can be profound. If you look into what's called the cross-race effect, you'll find a tendency to have difficulty processing faces of members of other groups. If you've ever heard anyone say "all Asians look alike" or the similar "all Westerners look alike", this effect is what's behind that sentiment. And it's universal: this processing difficulty isn't limited to any particular ethnic group. Cross-racial identification statistics for eyewitnesses prove all too well just how troubling this can be even amongst ethnic groups that are otherwise readily familiar (i.e. whites identifying blacks and vice versa). But what a lot of the current literature shows is that the rate of difficulty can decrease with familiarity that shapes how we code faces and integrate them into
Anyhow, as far as communication is concerned, it's not just verbal. On the contrary, most of our cues are distinctly non-verbal: body language, gestures, expressions, prosody, paralanguage, and a lot more. People toss around Albert Mehrabian's "93%" number a lot without considering its context (namely, his work was limited to the communication of feelings and attitudes), but the broader point is that these cues serve as a means of helping to imply meaning to the words they accompany.
Now, where the really fun stuff begins is when you start to consider the universality of some of these nonverbal cues. Particularly with the face with microexpressions: involuntary expressions lasting only a tiny fraction of a second that correspond to six basic emotions. Contrary to the idea that expressions and meaning were culturally determinate, the research is fairly overwhelming that despite differences in culture, language, and even physical face characteristics, microexpressions and the emotions represented are consistent. Rules governing those emotions are be culturally specific, but how they're expressed and the emotions themselves aren't. Back in '71, Ekman went to the Papua New Guinea to show this with the Fore people even though they had almost no direct contact with the outside world up until the fifties, and at the time Ekman went, had no access to Western media or entertainment that might have given the Fore the experience with outsiders and their facial expressions.
Related to your post, however, are the findings that show we're able to recognize these expressions by people outside our own ethnic groups. In a sense, not only are the emotions and expressions universal but so too are our ability to recognize them. Biologically determined, hardwired. So talking in person, rather than on the phone, can make all the difference in the world.
If you're curious, I'd recommend taking a look at a reprint of Ekman's Unmasking the Face and Darwin and Facial Expression: A Century of Research in Review if you're curious about some of the historical origins of the work. The latter, in particular, is truly fascinating.
My free time is very limited and valuable. Google sounds interesting, but here are my options:
a) Spend my free time exploring and building small projects with new technologies and techniques. Maybe work on a mobile app that could make some money.
b) Find my old CS textbook and notes and do algorithm studying and exercises just to prepare for an interview.
Doing a) directly improves my skills and has lots of benefits. I've been able to improve projects and gain a lot of good reputation at work because of things I discovered doing a). a) could also lead to making a revenue-generating mobile app. And perhaps most important of all, a) is FUN.
Doing b) just feels like a giant waste of time. Doing b) is a direct opportunity cost of not doing a). The potential return for b) is what? Going through a day long interview with judgmental engineers trying to look smart? And it's boring. It was fun learning in college when it was the first time and I had that aha moment of understanding. Now its just boring to go over it again and again just to rote memorize things. I would rather be building or learning something new.
A week or two goes by, and they hired him without doing an interview.
On a separate note, I've always had the test anxiety problem so I could understand how an interview is more of an acquired skill and less of an indication of your coding ability. I can code, and I have no problem with understanding the material, but when it comes to taking a timed test and using a pencil and paper for something that I usually use a completely different input for (a keyboard and a monitor), I struggle with it. Some people dismiss it and say "well you obviously didn't know the material if you couldn't get it on a test," but I never agreed with that.
Most people I know, myself included, have suffered from anxiety or panic attacks at some point in their lives. It's usually possible to overcome this, though. When you realize that you don't interview well, are afraid to speak in public, freeze up on dates, are afraid to speak to clients, panic when your boss disagrees with you, etc., you can either work on it or try to avoid those situations forever. Frankly, I'd rather not hire somebody who convinced themselves that they have to avoid certain situations because they can't handle them.
I do love the contractor idea, though. Perhaps it would be best to hire somebody as a contractor for a small project and then have them present in front of the entire team and ask specific questions or ask for live modifications?
After going through an initial resume screening and phone call, you show up on-site in the morning.
You then give a presentation about some recent work you've done. For those fresh out of school, it's generally about their grad work.
Then you have a series of 1/2 to 1 hour interviews through the day, mostly with people who were at your talk that morning.
The individual interviews tend not to be the Google-style "please implement a data structure for XYZ on the board" sort of thing. Rather, we'll ask about things from your talk or your resume that interest us. We might describe some work we've done here, to hear what you think about the problem, how you might have solved it.
A lot of what we're looking for is how well you're able to communicate your responses. We also want to get a feel for personality, how well you work with others and how well your personality will interact with the people here. I believe this place is actually pretty diverse, and I like to think we don't fall into the "culture fit = 20-something white male" trap; however, some of the restrictions and circumstances of the work we do may make some people unhappy and we'd like to avoid that.
We also pick two people to take the candidate to lunch. This is supposed to be a chance to talk more about life in the area and what it's like to work here, although honestly a lot of that comes up during the regular interviews.
After all the interviews are done and the candidate leaves, the interviewers get together, share their impressions, and say whether or not they recommend hiring. The hiring manager then makes the final call.
It's not really suitable to everywhere, I'm sure, but I'm pretty happy with it.
The real technical skills part is the presentation. If you can give a good, 40 minute talk about what you've been working on, you've already put yourself in a good place.
One of the facts of research life is that you'll spend a good chunk of time talking to people and presenting your work--it's the price you pay for being able to choose what you work on. This interview process seems to help select for people who work well in that environment.
i've had multiple interviews where i did well on the phone and the tech-out, only to receive a "take home exercise".. with guidelines such as "it will be graded by style and architecture in addition to correctness of function".
This would mean half of my saturday in a coffee shop coding an elaborate solution using latest technology and good patterns.. with some resentment because i just wasted hours of precious (and scarce) free time.
Not only has this never lead to an offer, but in some cases i'd not hear back for weeks, with eventual vague comment like "it was good, but not great" or "it was great, but we decided to go with someone who happened to have more experience in X domain".. that's nice..
I got an open ended problem that would take a measure of forever to solve: Specifically to write a program (in your favorite language!) that would do natural language processing and discern emotions and feelings about subjects from text. We were supposed to include our own lexical parser.
The author's strategy scales poorly with complex and interlocking problems. Where it is more important to show potential ability to solve the problem (puzzles), holistic understanding (talkin' about it), or prioir experience (specific questions about libraries).
This guy should address his core problem (stage anxiety?) instead of advocating a solution that is only tenable in a limited number of cases and represents far too much commitment from the participants.
I know of a YC alumni company that asks for a weekend project on roughly that level and when rejected candidates ask if they can upload their work to Github, the company declines because they'd "like to keep an even playing field for future candidates."
Then you're left with choosing between having an awesome project you can't show off and being an inconsiderate jerk who uploaded code despite being asked not to.
Doesn't really make one enthusiastic for the next time you're asked to do an "exercise" or a "project."
This is a recipe for only finding unemployed people, and in my opinion, the best people already have jobs.
I have been offered to interview with YC startups that wanted me to fly out, spend a week writing code with them, and _then_ they'd offer me a job. I'm already employed, by an employer that legally owns all my code. I can't take a week off, write your code, and then _possibly_ get an offer. I don't have time for that.
Technical interviews can go afoul, yes. But, IMHO, they are the best we've got. They show respect for the interviewees time, and decisions should be made quickly. Will you occasionally miss a good candidate, yes. Will a bad one get through, less likely. That's about the best one can hope for.
I like this approach. In fact, something similar has happened to me in several of my job acquisitions. Networking trumps pretty much anything else.
Now, a good interview isn't one where you ask question about the technical details of a language or a framework or how HTTP works or anything like that. Sure, good technical knowledge is necessary for most positions, especially senior ones, but information is really easy to pick up as you go, whereas real talent is not. Good interviews ask more broad, open-ended questions. "If you wanted to build X, how would you build it?" "If your app was really slow, where would you look to fix it?" "What do you think about framework/language/tool X in relation to tool Y?" Etc, etc. These kinds of questions let you really get into the candidate's head and figure out if he's a good fit, while still allowing him room to go in a different direction and play to his own strengths.
Practice can work against you. In one case I was worried about the algorithm and data structures side of things based on glassdoor posts. Spent a week of evenings coding algorithmic whizbangery. In the interview I obsessed on getting every line of from-scratch code right (obsessively focused is often how I code real software) and stopped "listening" to what was being asked. Double whammy was the interviewer was actually not very familiar with the solution to the problem (canned and complex do not mix well) and when I confidently but politely corrected him as we were coding, boy the color of the interview changed fast and game over. My bad, In the real world I'd politely correct a coworker too.
Or maybe what you should practice is writing out JavaScript with pen and paper like another interview. I hadn't written code out by hand for 15 years .. like since the invention of the keyboard. I did a terrible job despite having just completed a non-trivial very modern mobile front end project. Ri-donk-u-lous.
Be yourself, stay balanced, do your best, HR science is evolving too.
One of their main features is contract to hire. I find many great candidates through them where I work.
This article reeks of privilege, namely that of location.
The suggested is horrendously unfair to people that would need to relocate (possibly even internationally) to get a job.
I am currently interviewing for a large tech. company in Silicon Valley. I am living in England. It would take a substantial amount of resources for me to even meet the team in person, so of course they want to vet me via Skype or whatever before they commit to this. On the flip-side, if I'm going to be uprooting my entire life and moving to SF, I want some sort of guarantee I have a solid, full-time position.
I also wouldn't be able to afford a £1,000+ flight (and countless days of missed work) in order to do an on-site interview. Utterly preposterous.
Thankfully, the person doing the technical interviews has been a person who basically has the same job as me, so they understand the position and can see if I'm a good fit. The interviews were of the format that they pasted into some questions to a collaborative editor, I get to choose a language, and solve them. We are Skyping so I explain the reasoning behind what I'm doing etc. Code doesn't have to compile, I don't have to know the exact syntax for function calls (because who can't find that in seconds anyway), but it's about figuring out my though processes, confidence, ability to deal with new things, etc.
It'll be interesting to see what they think of me, but it seems like a reasonable process, and does not exclude people based internationally.
TL;DR: Everything you need to know about if I'm a good fit is available online in my OSS (et al) track-records. If that's not good enough for you, that's not the kind of job I want anyway. I want to work for companies that value the full lifecycle of OSS work, which you can only see in such a way, and CANNOT judge via tech interviews.
By the time I walk in the door for an in-person interview, I expect you to already know that I am fully qualified (tech and otherwise), and you're looking now to judge my cultural fit by sitting me down in a real team meeting and seeing how it works, etc.
If I show up and you try to quiz my tech skills, you didn't do your homework on me, and I have no more time for you, so I'll just chuckle and walk out. Politely of course.
That was 2004 or 2005. He's still here. Great hire.
Sometimes you can just tell right away.
All that rambling aside, I'm with the people who dislike the techy interviews. I was #4 at Google and I don't think there is a chance in hell that I could pass their interview questions today. But I've done good work, created good stuff, they ping me from time to time to come back. So perhaps I should be hired but I wouldn't pass the interview process so far as I can tell.
What's wrong with the contract idea in the original article? As a manager, I love the idea of someone who is willing to demonstrate their skills in a contract. If I were out looking for a job I'd offer that up, it's try before you buy, what's the downside?
Can other managers tell me what is wrong with that approach?
Plus, in a large company, internal transfers are common. The social dynamic of asking for an employee who works elsewhere in the same company to do work for a different part of the company seems awkward.
Does anyone have any success (or failure) stories about trying to make this sort of approach work in a large company?
So what's the answer? no, not contract to hire. Although good in theory, in practice many companies won't support or approve contract to hire for full time position. Call it HR inertia, a.k.a 1 of the 4 horsemen of death in bigger more established tech businesses.
So where am i going with all this? Well, that's why networking is important. Get the people you worked with to bring you in places. You don't have to impress anyone on a white board (who codes on whiteboards anyway) but put the emphasis on culture fit since you already pretty much have been tech screened by your old pals.
In conclusion, be nice to your peers. Especially the smart ones you work well with.
My point? Don't just ignore the problem of anxiety when it cripples your life. Address it head on and try to work through it. It will help your life greatly if you can.
Meeting potential employers outside the office like this (over lunch or coffee) has been so much more effective for me as well. It takes the pressure off on both sides and lets everyone really get to know each other. If you can't sit down with someone over coffee or lunch, how are you going to work with them?
We're gathering companies who are interested in this approach to hiring (and trying to make it a trend). Employees at the companies offer coffee meetings (their treat) that anyone interested in the company can request. If there's mutual interest, they meet for coffee to chat about the company.
www.treatin.gs
The issue is that where I work we can't subcontract as a way to 'test' for candidates. The code is so proprietary, and have so much red tape (Options Trading platform) that we don't trust anyone unless you are full-time. Also, the code is fairly complex and embedded in it's industry-speak that unless you come from the same industry subset, you will not be productive (like knowing what Black-scholes, instrument, or delta means). So the investment to getting any good developer to be able to produce is immense. We considered subcontracting for assessing a candidate, but it is fairly hard.
Also we have seen people that do extremely well on every other aspect of the interview but can't deliver when asked to write a piece of code. Good or bad it does show your ability to work under pressure (I am not sure if it's extreme in the financial industry, but stress levels here run fairly high... for a fun read http://codesnipers.com/?q=interview-the-wall-street-programm...). So when you're getting your coffee, someone comes and says 'we need to fix this' it will probably be as intimidating (or more) as having a code interview.
Lastly, maybe because we've seen it often enough, there are a ton of programmers that can't write code (yes, the fizzbuzz crew). Having the codility test filter in front of all eliminates a lot of that chaff we see, so we don't even bother with the candidates unless they get a good-enough result in codility (we do look at the code, not just if it passes/fails the unit tests, but we don't bring the candidate for an actual interview until we have a reasonable expectation that they can program). We understand we will miss Ike Ellis, and we accept that as part of the tradeoffs between time and opportunities.
I ask people for a list of projects that they designed and coded (live projects, so I can see how they function), to get a sense for how good they are overall, then will look at the underlying code. I value readability and documentation over fancy tricks meant to show off the author's MENSA status.
When it comes to the interview, that's all about assessing their personality, work habits, and broader interests. Friendly personality, good work ethic and broader interests = someone who is flexible, which is vital in a small company where everyone has to do a bit of everything.
They did a pivot after acquiring Kyle's TinyProj [2] customer base, which included us. Wondering if anyone has any good experience with GroupTalent?
[1] https://grouptalent.com/welcome/ [2] http://techcrunch.com/2012/01/16/tinyproj-shuts-down-users-s...
There are many reasons why people would come to you to ask for help or why you are more successful then colleagues. E.g. in my company we have a guy who thinks of himself as a web developer but thinks that CGI is the protocol the browser talks to the web server. It is not hard to be the best in such an environment. Don't compare yourself inside your company! Compare yourself to the rest of the world! Look on GitHub, read blogs, talk with people on software development mailing lists. If you still feel stronger than most people around you, you probably are.
I also insist on doing some work there, to prove myself of course and see how things work. how they are organized, tools and frameworks they use etc. And most important to get a feeling about the people there. I know it's hard in just one day but you get an impression. I left my last job because I wasn't feeling good there. No team spirit and a "cold" atmosphere. Why should I spend 8-9 hours a day at a place like that?
Nice idea. Though I hope you don't expect to be given high priority stuff or be paid a full senior dev's wage during this short contract before which I don't know your abilities as I've not had some other chance to assess them.
Of course an active public portfolio helps here, as potential employers can get some idea of your output from that, but we can't truly rely on it as it can be faked (or be misleading for far more equitable reasons).
The nature of the work isn't that important. However, asking someone to take a low-ball contract is a great way to filter talent. People who are good, or busy, will completely turn you down. People who are desperate or suck will gladly take the money.
This contract test should be last one you do. It should be either the full day on-site or the short contract. You also need to pay market rate if you hope to hire market rate talent.
It definitely doesn't help with my confidence going into an interview and not knowing if I admit I am not an encyclopedia is going to get me disqualified right then and there.
I am sure that it has to do with the jobs and the locations and the companies but definitely freaks me out about my future.
2nd to references is looking at real work products. You're in advertising? Show me your ads. You build websites, show me your websites.
Your method of short term contracts is a good way to get to both at the same point.
Any thoughts on recruiting college hires? They don't have work products, and in many cases don't know enough to be useful on a project with low guidance.
For instance, a gamer who enjoys TF2 or better yet, Left4Dead...that's a partial sign that they enjoy teamwork, despite the downsides of dealing with weak-links and griefers. Someone who enjoys only Halo deathmatch...well, hopefully their skills match their bravado ;)
Each of those people are important to have depending on the companies situation and that's why no one interview process works for all programming positions.
I interviewed at a company that gave a software engineer's interview for a data scientist position. Because I'd actually worked as a data scientist, my software engineering was a little crusty. I failed the puzzles, and its really frustrating that way.
I've done the 'start as a contractor' thing twice and it works.
Heres a choice quote that I'm still happy with:
"Programming isn’t theatre or performance, “on demand” isn’t how your job works"
But I support this because a lot of technical interviews are ripoffs of people's time. I've put a lot of effort into technical presentation, done well, and then been disqualified based on other criteria. That sucks and the companies have done it that way because it's easy for them.
Anyways, the article is good, but mostly for very experienced developers who can demand certain accommodations.
>> getting it correct isn't even that important .. Perfectly proving the point. Coding the day before, you're aggressively focused on getting it right and shipping a quality product. Suddenly you're in an interview and you're doing the opposite, coding just so much irrelevant nonsense that doesn't really matter and being judged out of context. Wasted time, effort, angst, in short a potentially bad start to what might be a great relationship.
Why should Oracle be any different?
What I understood from parent was: good college + good GPA => meets minimum hiring criteria, so make them an offer.
What you are saying is: (good college, good GPA) is not correlated with magnitude of performance among PEOPLE ALREADY HIRED INTO GOOGLE.
Many larger firms with technical employees are worried about their lack of diversity, and the relevant legal risks. They may have to bend their effective practices to mitigate this risk.
Beyond making this claim as an ulterior rationalization, mendaciously spreading it might help trip up competitors.
Do I want to hire a person who is great when things are going well but who goes to pieces under pressure?
Learning how to be interviewed is as useful a skill as learning how to code.
Its like attending an exam, its not the same getting work done in the real world.
>>Learning how to be interviewed is as useful a skill as learning how to code.
No, learning how to build is a useful skill. Learning how to be interviewed is mastering the art of being the best rat in the rat race.
The whole point is even if you win, you still remain a rat.
Of course it's not. Real world is much more stressful than an interview. During an interview you chat with another developer in a room with a whiteboard. In the real world you are woken up by a phone call at 4 AM to fix a critical system, knowing that if you screw up even slightly, you'll lose a very important customer. I've experienced both and I can confidently say that I prefer the former.
And I am certainly not going to introduce a TON of overhead into our process bringing you up to speed just to assess this. You go from asking for 3-5 hours of my time to asking for over a week like that is reasonable. Like that is somehow a superior outcome for everyone? Here's a hint: it is not.
You live the life you wanna lead buddy, but I am not going to "trust" that you are a good developer without getting at least some indication that you are not a very convincing impostor. I have trouble with high-stress googletard interviews too (and I don't give them), but to ask for tech jobs without any real evidence of tech capability?
That's unreasonable.
Does anyone know how interviews at Apple and Facebook are like? There are often praises of Microsoft's interview procedures and bash on Google's on HN. Wondering what these two other companies are like.
- How long have you been doing this career for?
- How many jobs have you had?
- How long you had those jobs?
- How many technical interviews did you do?
- Since when have you started practicing your new 'technique'?
- Over which period have you effectively applied it?
In a non ad-hominem manner, I guess what I mean is: what useful data is this? Should people base their future behavior on your anecdotical reliable experiment/measurement?
I was working on a project myself, that I kept getting stuck at a particular point. It could just have been that I was looking at it, by myself, too long and was too close to the problem that I couldn't solve it.
I was looking for Rails devs because 5KMVP started getting more requests for work.
I got a few recommendations and people reached out to me about that freelance Rails position. I whittled down the list to a few I was interested in and I decided to do exactly this.
I created a mini-spec of the problem I was trying to solve, pushed the codebase to a private bitbucket repo and added the guy I was evaluating.
Told him what I wanted completed, and told him I would pay him to complete that micro-job. If it works out, then we will move on to other projects.
Once he finished the project (in a few days) we both walked through his solution. That was such an insightful process for me, because I got an inside look into the way another developer thinks. I even learned from his approach, from his code style and was pleasantly surprised with the quality of the output.
Going through the 'post-code analysis' also allowed me to see how he communicates in the way that I will really communicate (which is via Email and Skype).
I have since hired him and I love working with him. We do have things to work out - specifically on the communication side, but I was pleasantly surprised at the outcome of the little experiment.
For a relatively small amount of money, I was able to a) Learn an interesting approach to solving that particular problem, b) learn new coding approaches, c) figure out how he communicates, d) see how we would work together - he didn't understand something, so he asked questions while he worked through it, e) he was able to do all of that at his leisure - not necessarily through a timed examination.
It's a wonderful screening tool - and while I am not sure how that will scale - that has been my experience with this approach too.
I will definitely continue hiring freelancers like this....by the way, I only did this after I looked through his Github account and checked out any projects and web properties he had online. That's the first line of screening from my perspective.
Edit 1: I thought I should add that I think that this worked so well for me, because this was a problem that I had been tackling for weeks and couldn't solve. So I was intimately familiar with the inner workings of the problem and so could fully appreciate the solution.
I'm not alone.
the brainteaser-whiteboard-fizz-buzz-5-member-panel interview is, and has always been, highly unreliable, if only for the sole reason that PEOPLE GET NERVOUS. gee whiz, what a concept. back here on earth us mere mortals have to deal with things like nervousness, forgetfulness, and intimidation on a regular basis.
let's not forget sociopaths or assholes in a bad mood who deliberately try to make people feel nervous. they exist. that's a thing. i've seen it with my own eyes.
it is an unreasonably strict high-pass filter that gives false negatives people who are otherwise perfectly valid for developer jobs. that's great if you've got millions or billions in the bank and have carnegie mellon grads lined up out the door. that's awful if you've got $50k in the bank and you need someone competent working on things yesterday.
SO much value can be won by hiring people who can't or won't deal with this kind of scenario. on both sides of the table.
We forget this at our peril.
The real reason we indulge hoop-jumping is that it gives a veneer of equality to a process that (really) has more to do with natural gifts than certifications.