Well, I need to interview candidates because I need to know if they are up for the job when systems breaks. If a table query fails because it needs a btree index due to range searches, I want the candidate to know how a btree index works and why it fixes the issue. Also If somebody cant tell me the difference between http udp and tcp, its a no hire for me.
So for me, I really want to interview somebody before he can work with me.
Can you not understand that there might be people who can complete your task easily, yet who have extreme anxiety about interviews? I actually understand this issue -- I've been trying to switch careers into programming for the past year. I've know several languages well (Python, JavaScript, some C), can use git, and have a few decently impressive projects on my Github profile. I also contribute to a pretty well-known open source project. As a result, it's not hard for me to get an interview. Nonetheless, I've discovered that despite being very good at interviewing in my prior (well, still current) career, I completely freeze when I interview for programming jobs. Programming interviews seem incredibly confrontational compared to my current profession. Interviewers seem to be out to trick you at something, or else to prove how much smarter they are than you. So I predictably freeze in these types of situations, to the point where I blank on things that I can usually do, even under pressure. It's been a big shock for me, since I did very well in school and went over a decade without "failing" an interview (i.e., taking an interview and not getting an offer) before attempting to transition into programming.
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.
>Programming interviews seem incredibly confrontational compared to my current profession. Interviewers seem to be out to trick you at something, or else to prove how much smarter they are than you.
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 realize that it can be hard to understand without having experienced interview anxiety yourself, but it is an entirely different environment.
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.
>I realize that it can be hard to understand without having experienced interview anxiety yourself, but it is an entirely different environment.
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 understand where you're coming from, but I disagree that this is a matter of individuals' responses to stress in general. I know that in my case there is nothing else I have ever experienced that can trigger a stress response equivalent or even similar to what I experience during an interview. It is irrational, but it is entirely separate to anything I could experience through professional work. It is not the questions being asked during the interview that cause anxiety, it is the interview itself. I actually find that I work quite well under high-stress and high-stakes work environments.
from your descriptions it sounds pretty much like my situation.
>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)
I hear what you're saying, and to a certain extent I agree. However, maybe that's the other benefit of doing these kind of pre-hiring contract jobs. They let me see what kind of an organization I would be working with.
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?
> Programming interviews seem incredibly confrontational compared to my current profession. Interviewers seem to be out to trick you at something, or else to prove how much smarter they are than you.
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. :)
Interviewers seem to be out to trick you at something, or else to prove how much smarter they are than you.
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.
Well, that is pretty offensive. You're calling me incompetent, whereas I'm definitely a competent person. I did well in school (3.6 GPA in a good college), finished a master's degree, and have done well in an established, albeit dying, profession, including speaking at conferences and writing for trade publications (and even co-wrote an article for a peer-reviewed journal, which is unusual for my profession). If you're referring to my programming chops, well, I think it's pretty impressive that I taught myself to code in my 30s, and that I am now very comfortable in Python, JavaScript, and (to a lesser extent) C and Lua. I even play around with languages like Haskell and Ada for fun. I taught myself git, built several large web applications (which are part of my portfolio), and have almost finished a complex Android application (thus adding basic Java to my list of languages). I've unfortunately not yet had the opportunity to be mentored by someone more experienced than me, or participate in a large team-driven project, which I realize is now holding me back from the next level of programming expertise.
I could make similar presumptions about you based on your response, but since I don't know you at all, I'll refrain.
Perhaps the solution is for the interviewer to tell you upfront "I don't know the answer to this as well, let's try and find a solution, together, but you start first"?
Hmm. That might work. But I'm skeptical, for the following reason: the main problem seems to be that most people who have done tech interviews and who don't excel at them have already been "traumatized" by prior interviews that their adrenaline is pumping and almost no amount of sane approaches can lower that tension in an hour or two. Maybe if you spent a half-day doing non-stressful activities and meeting people, and established some modicum of trust, that approach might work. But in an hour or two, there's no way for a stressed candidate to dial-down their anxiety.
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 never understood the fascination with asking an applicant about minutia of data structures and algorithms. Isn't that the domain of reference material?
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.
Put yourselves in the shoes of an employer. There are a hundred candidates applying to your position. Would the answer of "just trust me" convince you to hire one person above the 99 other applicants? If only one of those 100 applicants showed they had the skills you wanted, right out of the box, wouldn't you feel better about hiring him?
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.
The problem is that most companies make terrible decisions about which skills they want right out of the box. They can't get people that are 100% on everything they actually need (as such people are unhireable for the job/pay they're offering), so they settle for people who know a lot about B+ trees (or more likely, how to reverse a linked list and do a bad version of quicksort on a whiteboard) because that's what the folks who have been studying their "how to get hired at a tech company" webpage know.
I get your point, but knowing the differences between http, udp and tcp isn't minutia ... it's cornerstone knowledge for anyone working with distributed systems.
On the job training? Heresy! Shun the unbeliever, shun!
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.
I don't want my employees to have to learn everything just-in-time. By that logic, the people you hire wouldn't need to know anything. In addition, they don't know what they don't know, so they may not even know that they need a btree index.
You have a pretty low opinion of our field if you think everything that you need to know about our field can be googled in 20-30 seconds. I'm not arguing about minutia questions, but if you can't be bothered to understand how and why to optimize a database or the difference between TCP and UDP (really?) and that's what the job requires, then I don't want to hire you.
My argument is don't play puzzles, don't ask stupid questions about "What does this command do with these flags?".
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.
Basic computer science knowledge (and yes, B-Trees qualifies) cannot be learned in 20 seconds. Most of this knowledge is actually a prerequisite to being able to search Google properly.
Fair point. I was unfamiliar with B-Trees because most of my time is spent as DevOps/Networking/Sysadmin. It took me 15 minutes to learn and understand what they are and how they work.
Basic computer science problems creep up often enough (about once a month) at my mostly normal job. We had to implement a prefix trie (specifically a modified radix trie with extra caching) to solve an interesting problem.
If you don't know about these data structures or algorithms, you won't even know where to look.
Database indexes are very frequently btrees; understanding how a btree works can inform how you structure and query data, resulting in substantially better software. They're also a generalization of the binary search pattern, which every programmer should be able to describe and utilize.
This is a popular opinion which still makes hiring an art.
The best people I have ever worked with are the people who are fast to learn, have amazing problem solving skills and are socially intelligent. That's it. No knowledge of btree required.
> I don't want my employees to have to learn everything just-in-time
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.
As OP said, you would not be able to google the specific B-Tree question because if you don't know about B-Trees you wouldn't know that you need to google it.
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).
"I can see you're a bright individual and you have a great track record for writing and shipping good software, which is clear from your github account and your previous employers' endorsements. I have no doubt you'll be able to come up to speed on <insert obscure discipline> which is something we use a lot around here. We're looking for people who can learn quickly. Welcome aboard!"
Except that in my experience, software development is mostly about learning things just-in-time. Most projects pose new challenges, or you want to use new technologies, and so on.
Imagine you hired some Cobol developers some decades ago, and therefore you would still be stuck using Cobol on your projects.
>I don't want my employees to have to learn everything just-in-time.
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.
This is a lot like what I try to do in interviews, because I'm mostly just trying to filter out liars. I pick projects out of the candidate's resume and ask them about things they had to have learned to do the job they did.
What if they could explain what a b-tree is, and why they are useful, but that they'd have trouble implementing one on the spot. If they told you the name of a good book they know that has an explanation of b-trees. That they read the chapter a while ago, which is why they can generally explain what a b-tree is, and that that's where they'd go if b-trees came up and they needed to write/implement one?
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).
The truth of the matter is that, for most of us, when faced with a problem we work with what we know. If you ensure breadth of knowledge, you can get better at each aspect, but if you only know a few fundamental ideas, that means that you have to be capable of looking at a problem and rediscovering the right data structure to handle it with. Essentially, you have to be as smart as the guys who came up with it in the first place and more. Better to know the data structures and how they work.
I suppose if you're a network engineer http/udp/tcp is necessary to know maybe off hand but not really, http isn't even in the same network layer so I'd find it strange to even ask about the 'difference'. UDP and TCP differences are more or less a well known question but even then I've had some ask the question expecting the most basic of differences and others with the minutiae.
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'
Actually UDP and TCP are the prototypical examples of a reliable versus an unreliable protocol.
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!
I don't know what kind of work you're in, but "knowing how a btree index works" (i mean how it really works, not just knowing the word "b-tree", if that's what you meant, nm) ranks pretty high in my book, it'd be outright bizarre if that same person didn't know the difference between udp and tcp?
Believe me, your DBA or the person who writes queries doesn't need to know how exactly B-tree index works. Or even "B-tree" term. Just being aware about indexes and knowing when and where to add it would be sufficient.
I agree in principle that not everyone needs his entire algorithms curriculum resident in his head all the time. However, a DBA should understand the characteristics of the type of index he is implementing. B-tree isn't the only game in town.
So for me, I really want to interview somebody before he can work with me.