Dear Programming Job Applicants (2010)
joshcarter.com
joshcarter.com
I get the overall sentiment, but come on, "I hired him" sounds like self-absorbed anecdata - so this post is about how to quickly appeal to some manager dude on the interwebs? A more useful metric would be, did this hire survive the first two years, and what do the people around him have to say about his performance.
> It’s funny how many people can’t edit text on any machine but their own
How often does this person himself get thrown into random-ass editors and forced to quickly work through some rando algorithm while absolutely not forgetting to eloquently detail out loud their entire thought process? Self-absorbed, out of touch with how humans work.
Interviewer: here, a laptop with vi
Applicant: I've never used vi
Interviewer: just hit "i" to be dropped into insert mode, then just navigate with the arrows and use backspace like in any other editor. Ask me when you're ready to save and I'll teach you the magic incantation.
Applicant: types away
If you're not able to code in what's essentially just a test box then that's a useful thing for an interviewer to know. It's a strong indication that you don't fully grasp where the editor stops and the language begins, and unless you're applying for a junior role that's a negative sign.
Yeah maybe. The default vi config that comes with FreeBSD will get out of insert mode if you use the arrow keys to go beyond the end of the line (and maybe some other situations I've forgotten).
Editors are extremely personal, there's a pretty good reason that vi vs emacs is one of the eternal flame wars. I would absolutely expect a bit of discomfort and less proficiency with a different computer and a different keyboard. And, quite frankly, I'd be pretty put off by an interviewer who expected I'd hit the ground running with neither apprehension nor mistakes on someone else's computer.
No it doesn't.
I checked before I made the post on a FreeBSD 12 machine. The stock vi on OSX (vim 8) behaves more "normally".
i a b c [right arrow] d e f
results in vi displaying the text:
ab
Note that the key f generates a bell as vi is no longer in insert/append mode.
If you're seeing different behavior I can only assume you've got wildly different terminal settings, you've configured vi and forgot about it, or have aliased vi to vim or some vi variant from ports.
Either way that lends credence to the idea that judging someone for being uncomfortable at a vi prompt is a bad way to interview candidates.
abcdef
I'm super confused by your comment.
CALL -151
!
But if you insist on me using Vi, an editor I’ve never used and I get dinged for that, it tells me a lot about your company and I will move on to the other 6 or 7 interviews I have lined up. Your company is not that special.
But that's not the task they use for interviews. It's gonna be something like one special scenario of an abstract academic problem that you will never encounter in a high traffic website project. You either shouldn't need to code it and the thought process should be enough for the purpose of the interview, or you need to think and focus really hard, and being constantly distracted by an editor that doesn't do what you expected, because you have a muscle memory for your own keyboard shortcuts totally ruins that.
The result is that your performance in this task has nothing in common with your performance in the job.
Expecting someone to grasp a dramatically different editor with interview jitters is unfair. Frankly, that’s the kind of behaviour that would be a massive red flag for me - it would absolutely lead me to reject any position I was offered.
Anecdotal - I use zsh, with the bureau theme - pretty obvious it's not just a bash shell. During a more operations-focused interview I had someone ask me if he could use bash because he wasn't very familiar with zsh and would like to work with a known tool. Super competent guy.
I thought it was a perfectly reasonable request.
Didn't even think of that - you could totally say the same about my Sublime editor =D
People are comfortable with their own tools and I don't like putting candidates into a corner with what they're using.
I've been working as a mediocre programmer at the same company for the last 10 years. when I landed this job, I had never ever even heard of vi. I was "gently" introduced to it by my boss, and eventually got to kind of get used to a basic usage of it.
But in the box where our server run it is configured to highlight syntax, maintain tabs and shit, delete deletes, you can move using arrow keys, and a slew of other non default niceties.
Over the years I more or less got acquainted with different tastes of Linux, and used and installed it in a few of my own boxes (Debian, mostly).
Even thought vi respects arrow keys by default now it seems (thanks god I don't have to use hjkl. It is hjkl, right?) there's this conf issue that I've never been able to fix _because I don't know how to formulated the question in order to google it_ and it's the fact that when you're in non edit mode, _the cursor never goes to the end of the line_, so if I have to let's say add a new line, and the last word is `return;` I have to convert that to `return;;` put the line jump between the 2 ;; and then remove the extra ;. Plus, arrow keys in non edit mode add lines with crap in it.
I can't even fathom how stressfull would be doing a job interview under this circumstances.
Force a person to use a different OS than they are used to? Well, may be. Even thought I don't like nano, it would be a better choice than vi because at least it beheaves as a "normal" editor.
force a person to use vi with default settings? thank you very much for your time.
Found out when I was looking for something else, and improved my quality of life quite a bit. (I still hate distributions where arrow keys in insert mode don’t work like any reasonable human would expect, but they are thankfully getting thinner on the ground).
"NEXT! Obviously you just can't drive, your claim that you were a professional Formula 1 driver is a complete fabrication, and worse, you're clearly bone idle and don't want to learn anything new."
Interviewer: here, a laptop with vi
Applicant: I've never used vi
Interviewer: ....
Interviewer: REPENT, SINNER!
If you don't understand why you're hiring people, and what specific skills, psychological mindset and attitude, and abilities you're looking for - not assumed, but rationally chosen, preferably with some peer input - then you'll be bad at it.
OP obviously wants waterfall programmers - give them a predigested problem of limited scope, set them loose, and pick up working code in $time_interval.
That's actually fine for some jobs, but it's going to be a disaster in other contexts.
That is a great description of what an interview actually is. While your larger point is valid, you do have to get the job in the first place to have the opportunity to prove they were right to hire you. So you need to appeal to whomever you are talking to.
"Editor Flailing
It’s funny how many people can’t edit text on any machine but their own. I tend to interview people on a laptop running Ubuntu, and I open gedit for them to use, with the offer that they can use any other Unix editor they like. Most can barely navigate gedit, and it’s stupid simple.
Don’t ever let yourself get hung up on the editor. If you can’t figure out the magic command keys to indent code the way you like, just press the damn space bar and indent it yourself. Flailing in the editor wastes time."
Talk about an arbitrary condition. Sure, being adaptable and/or pragmatic with respect to tooling is a nice thing for your candidate to have, but to prioritize it at a similar level to knowing what your company does?! Are you really going to hire the incompetent-but-familiar-with-emacs Linux user over the capable-but-rigid Windows dev? Unless you're looking for an SA or full-stack dev, this seems rather arbitrary, especially considering the availability of plenty of cross-platform, fully-featured editors.
Disclosure: I'm an emacs user
It almost litterally is. Even busybox contains a vi clone. While I have encountered more systems without nano nor Emacs than I can remember. Plus, there is no excuse for learning the basic set of commands: i,ESC,x,u, and maybe navigating with the letters (which I'm not proficient at).
All that does is remind me that I haven't set nano as the default editor on that box and then I move on.
Any modeless editor should not cause trouble but vi (especially) is quite pernicious and the candidate would be just losing time.
But I agree, it should not be a show stopper.
(Emacs and vscode user here)
I love vi and set it as editing mode everywhere, nevertheless I accept that it might not be something people actively seek. If I was looking for a unix server admin then I would definitely assume they know vi.
While I don’t think vi is a showstopper, it would certainly be curious how a mid to senior engineer wouldn’t know how to use insert and quit in vi. This would make me think that a Windows only background never even meant connecting to a shell and having to view a file.
I’ve experienced lots of app developers who only use an IDE and don’t know how code is deployed or runs so they’ve never debugged a deployment, ever. They are in a big enough environment where that’s someone else’s job and they never have to talk with them.
That’s perfectly cool and folks will make a living and retiring in that world. But I don’t typically hire too many of those because I work in cross functional teams where the windows devs have to at least be able to understand and communicate with the Linux devs, and vice versa. That means having basic user level skills like two commands in vi, because it is almost always available on Unix systems. And frequently the only one allowed.
I think folks confuse this as meaning that people who don’t know vi are dumb, they aren’t. They could be geniuses who just don’t need to know vi. But for many types of interviews, it’s a super easy screening question that makes me follow up with more questions if they answer “I have to google.” It would be similar if a developer didn’t know cd or had never seen notepad or something.
For a Linux desktop user, including devs, I wouldn't consider not knowing vi to be that odd, given that other editors commonly ship or are a single install command away. For someone not working on Linux, it's even less expected.
My point is that you can be a perfectly nice programmer with a full career without being really good.
A bad engineer is happy that he has learned framework X and doesn't feel he needs to learn anything else.
Putting the Linux admin candidate in front of an xcode window is a quick and to find out where he stands. If he looks totally lost, he is definitely a 10x guy.
> Putting the Linux admin candidate in front of an xcode window is a quick and to find out where he stands. If he looks totally lost, he is definitely a 10x guy.
They are or they are not? Judging by the previous paragraph this sentence seems odd.
And I would argue that you could apply that to all programmers
I've interviewed a lot of people in Amazon and always offered choice between at least 4 editors.
If you cannot pass a coding challenge the problem is not in the editor.
Did you read the next sentence? The Windows guy that chose to use vi was hired.
If you've been writing a lot of software, I would expect you to be good at actually putting the characters into a file and moving them around therein. I would be very suspicious of someone who claimed to be a master carpenter but couldn't drive a nail cleanly. Muscle memory is a real thing, and the mechanics of a task matter. What is the point of all our fetishization of editors and keyboards and such if not to smooth the transition between brain and paper?
This isn't even always a matter of candidates operating in an unfamiliar environment. Even on their own personal computers, in the editor they presumably use for work, I see a lot of flailing.
Do yourself and the candidates a favor and step back from it to allow yourself to lose such prejudices.
>I open gedit for them to use, with the offer that they can use any other Unix editor they like.
I wonder if he required using vi when that Windows programmer interviewed or if the Windows guy chose to use vi.
IMAO most companies are not any better than the applicants applying. And no, you didn't hire only the best from all candidates, you just have a rich imagination that favours your ego.
I’ve rejected plenty of offers because I didn’t like the interviewer.
Yeah that's a thanks but no thanks from me. I wouldn't work for this guy in a thousand years.
As an anecdote, I used to work for a company and would require candidates to know some Ruby, for one guy with several years experience in Python we changed the requirements of the home assignment so he could write it using whatever he wanted. he hands over a nodeJS application claiming he took the opportunity to learn something new(why not Ruby?), seemed like it was well done, so we bring him in for an interview, unlucky for him, there was one member in our team with some nodeJS experience(me), having reviewed the code, I asked him to do a minor feature addition to his own code, he froze, couldn't do it because he didn't write the code(copying from some repo) and didn't know any nodeJS at all, asked him to do it in Python instead and he still couldn't do it, he had just spiced up his resumé with tech we didn't use to see if he could weasel his way in.
Always be hired or not hired for who you actually are!
But if it’s listed as a job requirement, sure start quizzing.
I always try to start with a technical question where the candidate can make a good impression and get confident.
First, it's a natural tendency. If you want to find if somebody "knows" a particular subject, an inexperienced person would start asking for factoids and interpret every incorrect answer as the proof that they don't really know the subject.
Second, many interviewers learn from other interviewers or just by trial and error, or from some courses, many of which have very dubious origins. There are many beliefs that are simply wrong, but still get circulated among interviewers, because nobody does 30 year careers in interviewing React programmers - wonder why...
This always gets me. When the interviewer asks a question, the correct answer is literally never, “let me think about it quietly for a moment”. This is one of the disconnects between interview programming and real programming people get frustrated over.
Also this: "It’s funny how many people can’t edit text on any machine but their own." - I bought a notebook without properly checking the keyboard and even now after 3 years it still bugs me everytime I type. Nobody can understand how these things can really limit focus. If I got a different computer with different keyboard, different operating system, different text editor (not even an IDE) and was asked to write a program, my focus would be totally ruined, compared to my actual daily work.
But I prefer to let applicants pick whatever language (within limits) and editor/ide they want for our current hiring process.
It's much more about how they solve a problem and navigate their tools (because that's an indicator too) than how they can use my stack.
After they gave me the keyboard, I told them that I can only type with one hand for physical reasons.
Not saying interviewing isn't broken in a myriad of ways, but asking a candidate to talk through their process to illuminate it isn't unreasonable.
I mean, you don't want to say: "I'm going to trial & error this shit while the fucking compiler builds and the stupid tests say it works" which is how must programming is done anyway.
But hopefully you have some ideas on what you want to try (and what your experience says you shouldn't, equally important) and talking about that thought process is exactly the kind of data I would want.
It doesn't even take an interview, we've quit pair sessions because it's sometimes fucking impossible to focus on deep stuff with another person competing for your attention.
Shut up, go away, let me focus and solve this is a perfectly good approach in real work.
yes, you do, but many interviewers don't and that's the problem
The information flow goes both ways.
Well if you solve it, then you've proved that you can solve it, right? So let people solve it the way they solve it when they're working for real. If that means sitting quietly and focusing on their screen, so be it.
Alternatively, the point of an interview is for the applicant to pretend they're bright and solving it on the spot while broadcasting how smart they are: https://news.ycombinator.com/item?id=17106291
Which gives you more data on how someone works and thinks?
1. Person silently sits for 15 minutes and then codes up a solution that meets the test criteria in another 15 minutes, typing quickly.
2. Person talks about the issues, tradeoffs and experiences while coding. They ask questions and engage in some discussion around the problem set. They end up with a partial solution after 30 minutes.
Of course those are hypothetical extremes, but it is clear to me which scenario gives the interviewer more information.
That's different from when the candidate is asked a question and they literally just become silent, with a "deer in the headlights" expression.
Of course, there's not really a way to tell in advance if you get an interviewer like me, or a jerk that insists you know everything off the top of your head.
If I, as an interviewer, ever did that I would:
a) expect the candidate to walk out, and
b) get told off by pretty much everyone in the company. Deservedly.
I really cannot think of a ruder way to express "you do not matter" sentiment than completely ignoring the candidate and flip through random stuff on my phone - while conducting an interview.
Google-fu is just as important a skill as knowing how to exit vi.
I see there being two parts to an SWE interview:
1) What experience does the candidate bring? Do they have compatible core competencies? If yes, then what’s novel about their experience—- will they help the team grok unknown unknowns? (And if the team’s burning issue is not unknown unknowns... then how does the candidate’s background add to the team’s creativity?)
2) How well does the candidate adapt on their feet? How effectively can they communicate? (If English is not a primary language, can they still get an idea across, perhaps using code instead of prose?). Can they code their way out of a paper bag?
The interview session is the interviewer’s responsibility to make the strongest case possible for the candidate. Let’s say that again: the interviewer needs to play doctor and adapt to the candidate. The interviewer is getting paid, not the candidate. Only once that sample has been taken properly can a hiring manager (who might very well be the interviewer..) begin to make an effective prediction as to how the candidate might do on the job.
Folks, demand for SWE jobs far outweighs supply. And it’s gonna be that way for at least another decade as universities catch up. It’s time to stop discriminating for the wrong reasons.
As someone that's done aot of hiring, I can concur with the author that there are many poor candidates out there, many who grossly "stretch the truth" about their capabilities and experiences. Unless you want to be lumbered with a dud, some kind of practical test is a must.
> It’s time to stop discriminating for the wrong reasons
I wasn't sure what you meant was the discriminating factor here?
1) Be humble. Don't expect people to take it easy on you because you got street cred (You are a ruby contributor? You still need to show them how good you are at coding Ruby). Many people with creds get offended when they realize they are not as good as their credentials would imply.
2) Know yourself. Most candidates I've seen, including myself, encounter a moment in the interview where they get hit by the nerves. Know that it's going to happen, announce it to the interviewer, recompose yourself, start again when calmer. You are not going to fail an interview because you are nervous. You will not succeed if you are terrified, panic, and shut up.
3) Explain your reasoning. The way you approach a problem, which is a large part of what the interviewer wants to see is in your mind only unless you vocalize it. With a good enough mental approach, you will get a lot of slack on the actual code by most interviewers.
4) Interview your interviewer. Go prepared with smart, non-trivial questions on the job and the company. Ensure your interviewer is an empathic, intelligent, and humble person. Assume anything annoying you experience is going to be relatively permanent at the job -- will that be acceptable or not?
And people lie on their resumes all the time. It's amazing how many outright lies we've caught when interviewing people (even those with "streed cred").
Several jobs in 7 years might very well imply several companies gave that person a chance and then gave up.
I often got questions about that years ago, and it was completely reasonable, at one point I'd worked in 4 different positions in 5 years. (There were good reasons for it and I had good references so I just explained it and it was OK, but I can easily see why they asked.)
Nobody "gives a chance" for a year. Either the problems were discovered during the probation period, or they were not as bad. Definitely not so bad that you'd have any chance discovering it during the interview. Besides, this high fluctuation is quite normal in IT.
Most of the folks I personally ditched were working for company for about 1y. You still may not want to kick a person if he fails because you might recognize that he could be better at a different type of job (frontend -> automatic tests -> ci/cd ?). Notably, I didn't have success with this type of shifting so far but sample size is still small, maybe its just a failure bias. Nevertheless, in my mind this is the right thing to do, to offer another chance at something different, rather then kick people out on inability to adapt to particular problem space.
And yet, I have a computer science master with an 8.1 (equivalent to a 4.0 GPA) and companies like Spotify/Google won't even give me a chance to do an automated online coding test.
> One other thing: if I ask for a program sample ahead of an interview, don’t even think about sending in code that doesn’t include unit tests.
I haven't learned about testing in school or at my previous jobs or freelance gigs. Where's a good place to practice it? I mean, I know what assert does and all but I don't have a strong mentality to write a unit test, unless I'm writing code that is finicky like a Red Black tree, then I do write some tests.
I hate these snarky posts, because I don't even get to an interview. In all fairness, maybe I shouldn't apply to A-tier companies such as:
- Spotify
- Digital McKinsey (I did some business studies back in the day)
Shout out to Optiver and OpenAI for giving me a chance though. Optiver made me realize I needed to brush up on my algorithms in the first place. OpenAI made me realize that I need to brush up on my math.
but he covers a good amount of algo resources and writes well.
I would, if whoever gave the exercise told me they want unit tests.
Not telling that, and then failing people for the lack of tests is fucking stupid imo. At that point it's just rejecting them for not having the right (secret) religion.
since I consider the ability to write well designed unittests as crucial.
That's why I think that a paid take home test is the best way to understand how someone can program.
But the job of an interviewer is to get data any way they can, and the job of the interviewee is to provide that data as best they can. For the interviewee that means it is almost impossible to over communicate what you are thinking when faced with a problem. (I know, it's not easy to do, I have been there.) It's not natural or what you do when you are programming typically, but an interview is not a natural environment, nor should it be.
If day to day coding in your company generates my interview level of anxiety and stress then you are 100% right that I would not be a good fit and you are doing me a favour by not hiring me.
The problem is that some people don't realise just how stressful interviews can be due to them not suffering that level of stress, anxiety etc. so it's difficult for them to see themselves in that position.
I wish every hiring manager had that experience as it gave me a lot of empathy for candidates.
Even pressure comes in many forms. When your future and career is on the line and you're being judged by a bunch of strangers, it can feel very very adversarial. Instead of having the interviewer's trust, you have the anxiety that comes from the mere thought that they're looking out for all your mistakes and failures. They're doubting you, out to get you. (Even if they weren't, that's how many people often feel)
By contrast, you can have immense pressure in production when shit is on fire and you got a sudden unexpected hard deadline and your team & customer is relying on you. How this feels depends on many factors but it can definitely feel more like being a comrade in battle (and the hero of the day). It can even be energizing. Usually, you have the team's trust and support here. It might be stressful as heck, yet the total opposite of adversarial.
It's kind of a big deal. I would never want to work in an adversarial environment, I don't think it's healthy for anyone. But a bit of stress here and there can help maintain a good pace and make the work more satisfying.
If I get your job, you and I are going to share our lives together. We will spend a lot of time creating something new out of the ether, and it will be a rocky, adventurous ride for both of us. Hopefully, you will be worth working for. The job market is large - me coming to you means I'm interested in what you have to offer, too.
If I accept your offer to spend a sizeable portion of my life working for you, it will be because I evaluated your authority, calculated the effect that your snark will have on my life, and decided it was worth it.
Programming interviews are where I can see, for myself, just how ignorant you are of Putts Corollary. Don't know what that is? You just flunked the interview. Got some clue about it, and have designed the interview to test me on it, too? Great, we're going to be able to work together.
- "Let's see if you can do Fizz Buzz!"
Yes, exactly. I'd like to verify that you can string a few lines of code together to solve a trivially simple problem. This is not an unreasonable ask, and I really don't care how impressive your CV is. If you can't solve fizzbuzz you're not going to be able to solve any of the much more complicated problems we wrestle with on a day to day basis.
Therefore, the fizzbuzz test is not useful and it's offensive (or at least, boring) to any good candidate.
> it's offensive (or at least, boring) to any good candidate
Personally, I find this preposterous. When I get a CV, I don't know the person, and I need to decide if they are worth spending time on. FizzBuzz is a simple filter that I've found to be very effective the fact is that a lot of candidates just aren't up to even the most basic of tasks.
If being asked to do a dirt simple task that will take you less than 5 minutes offends you, then I don't want you on my team.
It's equivalent to asking a partner of another law company you want to join you what were the most important things that happened in 1753 and then rejecting them because they didn't know.
...in that case they just proved they were childish and I'd be happy to avoid working with them.
> and your business goes belly up as you can't find anyone on the market with the skills that person was bringing, essential to your business.
I think you are overestimating the value of childish ex-FAANGs :-)
If someone is too full of themselves to write a FizzBuzz once they are too full of themselves for a number of other tasks as well.
Agreed: and one of the related issues that's worth stating is the damage and demoralisation to your team(s) that's likely to result, were they hired.
Literally not sure of this was meant to be ironic?
And the "imaginative" notion of a company going under because they dared to not hire you - a guru above all other, resplendent in technical magnificence - is, frankly, ridiculous.
Just having worked somewhere doesn't mean you actually did well there.
Interviewing people by waiting around while they plod away at a text editor isn't appropriate use of your or the candidates time. You should be interacting with the individual via talking to them. If they claim to be an expert in TCP/IP then you can peel back the layers back asking open-ended questions to see where the conversation goes. If they have the depth of expertise then it'll become pretty apparent when you discuss the intricacies of the topic.
Trying to trip somebody up with returning int V long is just redundant. That is an mistake to make and will be trapped by the compiler at compile time.
To interviewers I say stop wasting everybody's time and focus on discussion not exam style questions.
I think this approach results in too many false negatives. I prefer adapting my hiring process, asking questions and/or helping.
I feel that this makes it easier for the candidate to demonstrate their skills. Staying humble helps too.
EDIT: it’s possible that this article doesn’t represent author’s current opinion; we should add „(2010)” to the title.
No, it's not funny. Accessibility is important, what if, for example, the person is used to a different keyboard layout?
I would always encourage people to use their own machine and setup. If a programmer is uncomfortable on a different machine that might just stress them out and ruin the interview.
Also, you could be missing out on some hidden skills. I could show off some ninja moves in sublime text or emacs, or in my customised shell, but I'm pretty sure I'd suck on a fresh ubuntu in Gedit.
I agree that most programmers should be able to ssh into a server and edit a file without any issue, but that's different from completing a programming task. It's like testing if a tennis player can ace a serve with a golf club.
So, yes, I'll fiddle with the editor, because I'm not a fucking mind reader.
Besides, putting the candidate into gedit and then talking about debuggers is a bit inconsistent. If you put me into this situation, I'll of course use printf() debugging, whereas in a familiar environment I'd use the debugger.
"you can’t program anymore" and forever?
"can’t edit text on any machine" and forever?
"can’t figure out the magic command keys to indent code" and forever?
He sees the developer as having static knowledge that somehow, in the very moment of the interview, becomes frozen in time and nothing can be done about it.
I should copy/paste this article and change the name "How not to hire -the best-"
I do not agree with this at all. For a person who has a proper understanding of how a computers works from the basics, getting up to speed on any language and paradigm might take a short time but telling a person they cannot program anymore is complete BS.
Ok, object oriented environments are now more common but so what; they were invented 50 years ago and most of us have had some exposure to them at least on a general level.
So telling us we can't program anymore because we cannot pick up your laptop and your editor and toss out a program in five minutes is not a test of the person, but more designed to make the tester feel superior.
I am happy that I do not have to interview with Josh Carter.
He means if you have not been writing any code regularly recently (because you have been a Manager or Architect or whatever) then your programming skills will be rusty. You will struggle with FizzBuzz because you have have spent less than 5 hours programming in the last 12 months.
> it’s worth a few hours of my time to prepare for an interview
So, how many interviews he did in one week? 1 or even 0.5? Today typical manager with 2-3 open positions performs no less than 3 interviews a week. I personally will not spend all my time learning some irrelevant languages or frameworks just to show off in front of random people passed through HR screening.
That's when I realised the author was quite obviously lying.
That's fascism, what's your problem if I write my code on CLion? Should I write code on a hipster typewriter and scan my printed document straight to the compiler? Does that make me a qualified programmer?
yep. :) all lot of applicants should take a note at this.
The goal of interviewing is never under any circumstances to "bury" someone with obscure, difficult questions. Even as the OP is obviously impressed with his own skill set ("I've maintained a TCP/IP stack") I'm sure someone coming from a different vantage point could stump him easily, there's too many nooks & crannies of a field that vast.
> I’ve interviewed several people that couldn’t write Fibonacci sequence. I’d tell them what it was and write on the whiteboard the first ten numbers so they could see it. They’d start typing and immediately go into the weeds.
There's a lot of pressure in the live format to produce right away. Maybe you should consider take-homes instead of instantly assuming the candidates lack your superior communication and abstract reasoning skills?
> Don’t make me point out cases where your code breaks.
Right. I'm sure you've never written a bug in your life -- especially as a C programmer.
> I tend to interview people on a laptop running Ubuntu, and I open gedit for them to use, with the offer that they can use any other Unix editor they like.
I run Ubuntu desktop but why throw someone out of their comfort zone? Just ask them to bring a machine, or remote into a Google Hangout. The point of the interview is not to surprise candidates in unknown environments then feel superior because they don't know what you know.
> ...I ask if you’ve got questions for me, and you say, “so what does your company do?” the interview is over.
If it's cheapfurnaces.com, sure. But most companies it's not completely obvious what the company does exactly, even if you browse the company website or LinkedIn -- don't be so snide in your assumptions the candidates did no research on the company first, maybe they're just not articulate in their phrasing when asking what exactly a company does. They applied for a developer role, not to be CEO. This seems like an arrogant position to take.
> I’m not trying to beat up candidates because I’m a sadist, I’m looking for people I want to work with.
There's also a fair amount of chest-beating going on here, IMHO. The OP doesn't just want to assess the skill level of the candidates he simultaneously wants to assert his own perceived superiority ("most programming job applicants suck").
OP should consider acting more humble and try to demonstrate more empathy toward others -- often it's not the candidates "sucks" but his or her particular skill set or career level isn't ideally suited to the open role.
He would be a massive red flag to me as an indicator I don't want to work there.
Good hiring managers prepare for an interview, so you best prepare as well.
Here are some common mistakes that interviewers make:
1. Not testing the candidate’s argumentative skills. The interviewer should take a questionable stance on a topic and see how the candidate argues their point.
2. Never testing a candidate’s ability to read and understand code. Without this skill a candidate is more likely to reject your team’s existing code base and rewrite things from scratch. Instead of asking them to implement an algorithm (which, btw, they already may have practice doing - making the test pointless) get them to read a lot of regular code. Not a complex algorithm but something that spans multiple files and is quite large. It could be your codebase or something you found on GitHub. “Tell me what this does” “Tell me what you think is wrong with this code” “How would you change it?”. Being able to read code and write it are two separate skills and both need to be tested in the interview.
3. Making the candidate feel uncomfortable. For example, two interviewers against one candidate could make certain devs uncomfortable. Why is this important? A developer is going to get settled in the team at some point and feel comfortable. Wouldn’t you rather test them in that state rather than a state they would rarely be in? Unfamiliar text editors, interviewers watching you code; these are further examples. Sure, some devs are unfazed but others are, and they may be good devs that an interviewer is chucking away.
3. The interview should always involve a tech test and I strongly believe that the candidate should be left alone to do the test. However, this depends on how pair-programmer heavy the team is. Regardless, the most important part comes later when going through the results. So many interviewers miss the opportunity to question the interviewee on what they have written. It can be quite distracting if the interviewer is constantly picking through the code as it is being written.
4. Not going through the candidates cv during the interview. This should happen first and is part of the prep that an interviewer should make. As boring and full of exaggerations as other people’s CVs sometimes are, it is a good way to increase the confidence of the candidate so that the interviewer can get the most out of them for the rest of the interview.
- candidates have zero penalty for applying to something they know they aren't qualified for
- there's constant noise about getting one of those well paying "tech jobs"
- everyone who has ever logged hello world to the console thinks they are the best programmer in the world
- people are desperate and will lie
- the ratio of unqualified to qualified candidates must be 100 to 1
It must be like dying of thirst in the middle of the ocean. The one thing I love about this, though, is the "senior developer" who hasn't read a book in a decade and has to get a new job. ahahahahaha. The moment when that mountain of BS collapses underneath them must be ga-lorious.
Also though, I get the feeling it's a different job market than it was in 2010. I'm still trying to understand what I think I see.
Languages seem to be able to cover multiple platforms now. Programming I don't think is as technical as it once was. At the same time everything seems to be a mess right now. Everything's broken. There's a million and a half frameworks for everything. ...It's like programming as a field has become much more broad, while simultaneously lowering in quality, with knowledge that was once spent on technical mastery now being traded for either lower wages or domain knowledge. So if you went to school and got a degree in programming that was once pretty impressive but now you're just some dude who can "code".