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...
I suffer from interview anxiety to the same extent as the author of this blog post. Though I am a very skilled developer, I completely freeze in these situations (I even failed a fizz buzz test once). This doesn't translate to difficulty with on-the-job stressful situations however, as my anxiety is only present in interviews.
Most of the anxiety stems from me running through negative thoughts in my head ("I'd REALLY like this job - I'd better not screw up.", "I did poorly on my last interview. I'll probably do poorly this time", "The interviewer can probably see that I'm anxious.", "Does my voice sound shaky?", etc.) to the point where they trigger a fight-or-flight response.
my point isn't about denying interview anxiety existence (i suffer from it myself), and it has solid science foundation - speed of dopamine removal once your system is flushed with it. Some people have it faster, some slower. The former ones are great performers in acute short-term stress, while the latter ones are better at long/deep concentration on a task.
My point is about interview situation being preview to a lot [not all, yet a lot and many of them will be key ones] of future situations.
>I actually find that I work quite well under high-stress and high-stakes work environments
not getting the stress and being able to manage it is 2 different things. Couple jobs ago we had real clients with real problems, and it happened pretty naturally that i became the top "firefighter" that is brought in when support, escalated support, services/solutions, related development, etc.. exhausted their options and various executives on both sides are having sparks out their tailpipes - one may call this a high-stress and high-stakes environment, yet i just wasn't getting any stress, to me it was a simple 2 step algorithm : 1. forward me your AWR report (and this is instructions on getting it) 2. this is your root cause, config changes, emergency patch, etc... Simple, familiar, no stress (which i can't manage as i just get paralized/stuporred by it, like, in particular, in many interview situations)
In any case, what are you doing now, having left your company because of the environment that you see as plaguing software engineering? Did you change professions, start up your own company, or find a company that didn't have these issues?
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.
Deleted comment
I could make similar presumptions about you based on your response, but since I don't know you at all, I'll refrain.
It's funny, for years, I was always the one who relaxed and excelled at interviews, because in my current profession, interviews are fundamentally social affairs where you talk about your accomplishments, publications, etc. So as you can imagine, I went into my first tech interview entirely unprepared for the confrontational puzzle-fest that was to ensue. I found the whole experience so jarring that I still am hesitating to pick up the phone and try to schedule an interview for a company I know I would enjoy working for, and for whom I could do great work. I think I require some sort of Zen experience that rids me of my ego entirely before I can approach an interview with the same equanimity that I used to have.
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.
If you're asking interview questions that can be googled in 20-30 seconds, you're wasting your time and theirs.
An interview should be the same as a discussion about concepts you'd have with a colleague. Does the person know the concepts? That's all that matters.
http://slady.net/java/bt/view.php?w=800&h=600 http://en.wikipedia.org/wiki/B-tree http://en.wikipedia.org/wiki/B%2B_tree http://guide.couchdb.org/draft/btree.html
Now if you make understanding B-trees a prerequisite for the job, I can at least learn it ahead of time for the position.
If you don't know about these data structures or algorithms, you won't even know where to look.
What about just some things. And in most cases, it's not learning for the first time but brushing up on the topic. To expect people to have encyclopedic knowledge of every edge-case problem your company deals with on a day-to-day basis is ridiculous.
There's a difference between things you know you don't know (and therefore can google), and things you don't know you don't know (and therefore will not google).
Imagine you hired some Cobol developers some decades ago, and therefore you would still be stuck using Cobol on your projects.
How does one become an experienced Pascal developer? That's somebody else's problem.
You can require knowledge without using dealbreakers like "you must know b-trees". A better alternative would be to say "you need to know 30% of the following group of things: b-trees, tcp/ip vs udp, ..." and so on.
I don't mean to imply that this wouldn't be acceptable to you. I do "know" that I've been screened out after giving an answer like this (to the extent that I can really know the reason, legally they aren't allowed to say).
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.
Being familiar with protocol design is important no matter what type of programming one is doing, the ideas of ACKs, NACKs, and flow control pop up all over the place!