Dear Programming Job Applicants (2010)

http://joshcarter.com/software/dear_programming_job_applicant/

by jacquesm • 7 years ago

101 196 7 years ago

mooreds9• 7 years ago

Note this is from 2010, but still has many relevant points. As someone who has made some of these mistakes, I'd say the tl;dr is:

Good hiring managers prepare for an interview, so you best prepare as well.

nzjrs• 7 years ago

Depressingly, the difference between then and now is today's blog post would be advice for how to ace your 3 part interview, each with a 1 hour coding test and the take home project for which you are expected to sign an NDA

spyspy• 7 years ago

So, your code isn’t working, what do you do? Stare blankly at the monitor?

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.

mooreds9• 7 years ago

Hmm. The point of an interview isn't for an applicant just to solve the problem, it's to prove they can solve the problem. I think saying "let me think about it for a moment" is perfectly acceptable. But going quiet without guiding the interviewer is not communicating what your plan is.

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.

trickstra14• 7 years ago

I think saying "let me think about it for a moment" is perfectly acceptable.

yes, you do, but many interviewers don't and that's the problem

ubersoldat2k7• 7 years ago

I have had such hard times with this. I find it very hard to think about the problem and to think what to say to this person without fucking up the interview.

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.

clarry6• 7 years ago

The point of an interview isn't for an applicant just to solve the problem, it's to prove they can solve the problem.

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

trickstra14• 7 years ago

It only shows this interviewer doesn't really know much about programmers' daily job and has never been programming themselves.

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.

mooreds9• 7 years ago

I once interviewed in a code base I didn't know, using a language I didn't know (kotlin, so close to a language I do know, Java), in an editor I didn't know. I didn't get the job, but I don't believe it was because of my performance on the coding portion of the application (based on inference). But that was an error on my part. They offered to let me code a different problem on my own machine and I didn't take advantage, having a bit of overconfidence in my ability to pick up things quickly.

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.

scarface745• 7 years ago

I’m glad one of my interviewers didn’t feel that way. I was about to start a pair programming session and they had an ergonomic split keyboard for me to use. I just asked for a regular keyboard, I purposefully didn’t explain why just to see what they would say. They had no problem finding me one.

After they gave me the keyboard, I told them that I can only type with one hand for physical reasons.

wccrawford2• 7 years ago

While I wouldn't consider that a "correct answer", I'd be willing to be patient and let them think about it for a minute or 2. I may look annoyed, or even pull out my phone and start browsing news, but it's not actually taking points away from them until it drags on too long.

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.

bostik• 7 years ago

* I may look annoyed, or even pull out my phone and start browsing news*

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.

hjk053• 7 years ago

Well of cause you can think quietly about it, but you in an interview situation so you need to communicate that’s what your doing. Literally just saying “hmm, that should not happen, let me think about what’s going on” is all it takes.

yani• 7 years ago

I was interviewing a guy for IT position 6 years ago. After one of the questions, he went silent for a long period of time. It has not happened to me before. I did not think for a moment about interrupting him, it was obvious he is thinking how to approach the problem or his answer. Interviewing people requires patience, cut down on caffeine before an interview

fit2rule2• 7 years ago

When I interview people, and they get stuck on a programming problem like this, I tell them "it is completely acceptable for you to show me your Google fu to overcome this problem".

Google-fu is just as important a skill as knowing how to exit vi.

thiht• 7 years ago

What's a fu?

mcherm• 7 years ago

Actually, in an interview situation, "Let me think about that for a minute." followed by 120 seconds of silence, followed by a solid answer is a GREAT response.

That's different from when the candidate is asked a question and they literally just become silent, with a "deer in the headlights" expression.

GoToRO3• 7 years ago

Usually when you ask for a minute the guy says yes and then just continues rambling...

retrac98• 7 years ago

Some people completely blank when they’re under examination like conditions. It doesn’t make them bad programmers.

mooreds9• 7 years ago

Sure, agreed. Except in very special circumstances (devrel, prod system admin, startup first hires) the ability to think clearly under pressure isn't key to success as a developer.

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.

rootsofallevil2• 7 years ago

Interestingly, I've heard people say: if you can't code under pressure then you might not be a good fit here, to which my reply has always been:

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.

clarry6• 7 years ago

Except in very special circumstances (devrel, prod system admin, startup first hires) the ability to think clearly under pressure isn't key to success as a developer.

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.

hjk053• 7 years ago

No one is saying that, but companies are trying to create a accurate estimate of the applicants ability and blanking gets in the way of that, so they end up hiring someone who they are more certain about.

iamaelephant• 7 years ago

"I'll spend hours brushing up on Scheme just to test you on something completely irrelevant to the role just because I like playing Resumé Gotcha".

Yeah that's a thanks but no thanks from me. I wouldn't work for this guy in a thousand years.

turbinerneiter• 7 years ago

You could also interpret as the interviewer making the effort to ask the candidate questions where they can shine.

I always try to start with a technical question where the candidate can make a good impression and get confident.

trickstra14• 7 years ago

You could, but sometimes the interviewer doesn't even know exactly why they are doing it.

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...

mrisoli• 7 years ago

It's a good investment for the company, if the interviewer can red flag a candidate who is blatantly lying on his resumé because the candidate would assume no one would know said technology, it would save a lot of money from cutting ties with an employee in a later stage.

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.

wolco• 7 years ago

Imagine he got the role and did well. Trying to find the perfect person doesn't always work out as expected.

em-bee2• 7 years ago

that's why i like live coding. i had candidates who were dumbfounded with something like elevatorsaga.com.

rdiddly• 7 years ago

Yeah, bottom line, if you don't know an answer, then "I don't know" is always the right answer and the (ironically) most impressive answer. Plus you can always do things to mitigate, like talk about related or adjacent concepts a bit, state how you're willing to learn, maybe even take a guess at it. But if you bullshit you're either going to get caught, or, almost worse, get the job and feel like a fraud for months.

Always be hired or not hired for who you actually are!

mxcrossb• 7 years ago

I think the problem is that programmers have been taught to list every language and tech they have used on order to pass through HR. So, for example, when I was a student I wrote a ton of c# code. I’d be inclined to put that on a resume. But if they then asked me to code something in the language, it would certainly go poorly due to rust. Heck, I was a TA for a course where we taught lisp, but that doesn’t mean I can just start coding.

But if it’s listed as a job requirement, sure start quizzing.

fma• 7 years ago

Agreed. But also I think a lot of job requirements list every programing language under the sun...so candidates just trying to match the resume screening algorithms.

scarface745• 7 years ago

I did C afor over a decade, I was really good at it. I haven’t used it in a decade. But, I left it off of my resume after an experience I had 4 years ago. I was applying for a C#/JavaScript job that didn’t have one line of C in the codebase, but one of the interviewers started asking me trivia about C. I happened to remember it, I got the job, but I learned my lesson.

sys_647385• 7 years ago

I didn't find this confusing. If scheme isn't the language used in the job them who cares? If I am hiring a C++ programmer then I don't really want to drill into your Algol'60 background to trip you up!

sys_647385• 7 years ago

I 'did' find this confusing.

bitL6• 7 years ago

- "Hey, I worked at FAANG or better, creating latest super-duper tech you use daily, was featured on TV, got multiple awards etc."

- "Let's see if you can do Fizz Buzz!"

wccrawford2• 7 years ago

I worked with a guy that had FAANG on his resume, and we ended up letting him go because he couldn't actually do real programming for a device from that same company. He flailed for months to get simple things done, and failed.

Just having worked somewhere doesn't mean you actually did well there.

crusso• 7 years ago

Having worked at a FAANG, I can concur. Sure, some of the developers were world class. Some of them, though, had been there for years just kind of "lost in the sauce".

hjk053• 7 years ago

Yes, and if your interviewing for a sales position they might ask you to “Sell me this pen”. It’s a trivial task for someone experienced, so why take issue with it?

bitL6• 7 years ago

Junior sales position right out of school.

yoz-y4• 7 years ago

Well, if you are a good programmer then getting a Fizz Buzz on the interview is a jackpot no? It seems weird that half of the complaints about tech interviews is that they are too easy and the other half is that they are too tedious (I know that these are not mutually exclusive). The one alternative I see is to give one, really hard problem to people, but then the complaints about difficulty would come.

bitL6• 7 years ago

It's like telling the candidate "we are a bunch of idiots that don't appreciate your time, we are infantile and joyous about it, and in this place we don't really solve anything interesting as we have time for these stupid tasks."

bartread2• 7 years ago

- "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.

GordonS8• 7 years ago

It's such a simple task, but in reality it's a fantastic way to weed out those that really don't have a clue what they're doing. Saves a lot of time interviewing.

nobody271• 7 years ago

I can feel the pain here but in my own way. As a hiring manager it must be so frustrating to be assaulted with massive idiocy when you are looking for a candidate. Think about it:

- 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".

larkeith• 7 years ago

Most of this is good, but one real WTF:

"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.

emidln• 7 years ago

This is a great reason to learn vi for basic editing tasks. It's everywhere. Even if you typically use a different editor/ide, vi is a common ground.

Disclosure: I'm an emacs user

SOLAR_FIELDS• 7 years ago

It’s kind of weird to NOT know basic vi/vim if you get to a certain point in your career. If you can’t at least open the software, go into insert mode, and save/quit, have you ever had to ssh into a remote server and edit a config file before? Only excuse I could think of is if you literally did everything in windows for your entire career.

yoz-y4• 7 years ago

Knowing vi basics is useful, I agree. However, for interviews I really don't think that putting a candidate who is not familiar with it is a nice thing to do.

Any modeless editor should not cause trouble but vi (especially) is quite pernicious and the candidate would be just losing time.

walshemj4• 7 years ago

Pity I cant upvote you more than once, everyone who works on a unix system should know the basics of vi.

And I would argue that you could apply that to all programmers

verbify• 7 years ago

It's everywhere if you're on unix systems. Windows devs have little exposure to it.

sys_647385• 7 years ago

I think vi is the de-facto install of an editor on any non-Windows machine. You can't assume any other as vi in its simplest form is extremely lightweight and prevalent.

rootsofallevil2• 7 years ago

Get them coding on a whiteboard, problem solved :)

SamReidHughes• 7 years ago

I don’t know, I’ve found in my experience with some people that being only able to operate productively in a very particular setup is a real negative signal. And you’re giving the article a very inaccurate reading.

hdra• 7 years ago

I think thats what the article is trying to say with that second paragraph. Don't worry about how to use the editor the "right" way and just focus on the getting the code to work with whats available, which he pretty much confirmed in the third paragraph by mentioning how he hired someone who struggled with the editor but got the job done anyway.

meuk• 7 years ago

Letting a windows programmer use vi in an interview is just cruel. I mean, I like vim after months of practice, but just exiting vi(m) is notoriously hard for a newbie.

saagarjha2• 7 years ago

Being able to use vim at a basic level doesn't really take all that long to learn. Sure, there's the memes about vim being impossible to escape, but it's really not that hard to learn how to do so.

saltminer• 7 years ago

I'd agree if they were forced to use vi, but it seems like vi is just an option.

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.

ex_amazon_sde2• 7 years ago

Talk about an arbitrary condition.

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.

nat• 7 years ago

As someone spending a large amount of their week doing interviews these days, I really empathize with the spirit of this article. I've expressed an annoyance very similar to this one many times before - it's astounding how many nominally senior programmers are not adept at manipulating text.

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.

sys_647385• 7 years ago

This sounds like you're suffering from interview burn out to me. If you have a condescending voice towards interviewees outside interviews then it is usually a manifestation of how you perceive them in the interviews.

Do yourself and the candidates a favor and step back from it to allow yourself to lose such prejudices.

sklivvz19712• 7 years ago

A few more things:

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?

trickstra14• 7 years ago

ad 1.) yes, being a contributor doesn't automatically make you good programmer. But having 7 years of coding practice in several companies kinda does, because why else would those companies have you for so long? Yet these programming interviews are required even for them. Probation period is much much more telling about a programmer than the 15 minute coding task.

eitland2• 7 years ago

But having 7 years of coding practice in several companies kinda does, because why else would those companies have you for so long?

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.)

sklivvz19712• 7 years ago

Agreed, but they are not alternatives, they are both possible. Also, I was not referring to super hard questions that require practicing "cracking the coding interview" for a month before passing. I've had "popular" candidates that could not shuffle an array, find a substring within a string or do some other relatively simple task that requires the candidate to think a bit. The reality is that of course, people with seven years experience should not need to do such tests, but in practice, there are many candidates with such prerequisites that can't even code anything. How they get the seven years, is beyond me. All I know is that they can't code.

photonios• 7 years ago

#1 does not make always sense to me. Open-source authors and contributors have their work out in the open. You can see their work, the way they interact with others online. Would you reject Guido van Rossum if he can't solve your whiteboard problem? Assuming he's suited for the job, his work speaks for itself.

izacus2• 7 years ago

But that's exactly the thing - just because Guido did some project it doesn't automatically mean he has the skills for the job you're hiring for. Especially if you're interviewing people who aren't Guido (most of them aren't!) but are more local celebrity level contributor - being a contributor to something doesn't always give transferrable skills.

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").

mettamage• 7 years ago

I brought in a guy that hadn’t programmed professionally in years, in fact he didn’t even have programming on the first page of his resume. However, he had been practicing while looking for a job and he rocked my programming interview. He reasoned through the problem, wrote the code, it ran perfectly the first time. I hired him.

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:

- Google

- Facebook

- 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.

shearskill• 7 years ago

I was just in the rabbit hole in this guy’s posts about tech job strategy is worth reading - I started here https://haseebq.com/my-ten-rules-for-negotiating-a-job-offer...

but he covers a good amount of algo resources and writes well.

RealDinosaur• 7 years ago

I've written tests before, but there ain't no way I'm writing unit tests for a throw away coding exercise that used 4 hours of my time already.

je422• 7 years ago

usually for a coding challenge i include in the instructions to add unittests. ;)

since I consider the ability to write well designed unittests as crucial.

clarry6• 7 years ago

but there ain't no way I'm writing unit tests for a throw away coding exercise

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.

twelve40• 7 years ago

He reasoned through the problem, wrote the code, it ran perfectly the first time. I hired him.

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.

notimetorelax• 7 years ago

When reading the article I was ready to accept some of practical advice, but lack of empathy makes me not want to listen to the author.

AdrianB12• 7 years ago

The value of an article does not come from the empathy of the author. For example, my physics manual was very cold describing the formula for acceleration, but I did not ignore it because of that.

jimhefferon• 7 years ago

At the top he wrote something about putting on a flame suit.

skrebbel2• 7 years ago

Bullshit. It'll go like this:

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.

ubercow13• 7 years ago

Have you seen some of the other comments in this thread? Seems like there's a good chance it would be more like:

Interviewer: here, a laptop with vi

Applicant: I've never used vi

Interviewer: ....

inferiorhuman4• 7 years ago

just hit "i" to be dropped into insert mode, then just navigate with the arrows and use backspace like in any other editor.

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.

hluska• 7 years ago

Walking into an interview, being given vi and told to write code would be a horrible experience.

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.

trickstra14• 7 years ago

If the task was "write me a basic function that adds two numbers" then sure, editor doesn't matter, anyone with basic understanding of the language must absolutely be able to do that without google.

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.

TheOtherHobbes2• 7 years ago

"I've never driven a semi before."

"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."

scarface745• 7 years ago

I’ve programmed professionally for over 20 years gotten paid to program in more than a half a dozen languages and before that I learned how to program on an Apple //e by typing:

  CALL -151
  !

To get to the built in mini assembler.

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.

ericol2• 7 years ago

just hit "i" to be dropped into insert mode, then just navigate with the arrows and use backspace like in any other editor. Yeah, no. Let me call bullshit on you calling bullshit.

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.

codingdave• 7 years ago

how to quickly appeal to some manager dude

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.

trickstra14• 7 years ago

But the fact that it is being like that is the problem. It shouldn't be about who performs the most elaborate mating dance. This is a job and the performance of the project will be measurable and might have far-reaching consequences even for many people outside the company. None of the victims of the Equfax hack cares that the people on the job impressed their managers.

shshhdhs2• 7 years ago

I agree, but I think the idea is “can they deal with the unexpected or new? How fast do they grok things” Which happens all the time with these new frameworks, tools, etc

Pierre-ch• 7 years ago

The colleague who interviewed me later confided that i was the first he ever had who brought his own laptop for the interview. Apparently, it is not common!

clarry6• 7 years ago

Interesting, I brought my laptop to every interview for a software job I've had. Figured that's the best way for me to show and talk about some of my code, and maybe even code too if it comes to that.

kissgyorgy• 7 years ago

Honestly, the guy has valid points, but he is probably an asshole I wouldn't want to work for. I appreciate getting valuable advice, but the tone doesn't have to be like this. Maybe he is mad because of the "bad candidates", but that is his job, so he should be able to handle it.

alanfranz• 7 years ago

If you interview for Java or C# positions, editor matters. Give me an IDE. It'll take me hours to get the details right, because I'm used to the IDE fixing it

choppaface• 7 years ago

Oof, this is pretty antithetical to hiring. Author seems pretty frustrated. I hope this guy takes a long vacation. If I’m a candidate, I’d say this guy is clearly way overworked and I’d bail. Good points, but the volume of negative sadly speaks louder than the rationality of the points.

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.

GordonS8• 7 years ago

This is mostly agreeable, but you do need to actually test the competencies the candidate says they have.

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?

battletested• 7 years ago

So author, who are you? You start already with an authoritarian touch. What makes you believe you are not an incompetent interviewer? How can an applicant assess your skills, you could easily be the greatest fuck up in the company. Is your company really that cool that I should want to die to work there? Did you first weed out all the incompetent staff that is duck sitting there playing business politics?

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.

trickstra14• 7 years ago

the title should have the (2010) appended to it. And just judging by the website, the author is a 3d printing nerd with interest in weird keyboards and wrote a sudoku solver in 2012: https://github.com/joshcarter

scarface745• 7 years ago

And what makes him think that his company is so special that I would be willing to deal with his attitude at the interview let alone accept the job?

I’ve rejected plenty of offers because I didn’t like the interviewer.

trickstra14• 7 years ago

I once rejected a company because they had a big framed picture with 4 naked girls full frontal in the interviewing room. And because the manager pointed to it saying how "open minded" the company is.

_pmf_• 7 years ago

The thing is that the candidate does not know if the interviewer falls into the pragmatic or dogmatic camp. I've absolutely had cases where the interviewers insisted that the applicant was proficient in a specific compiler toolchain + hardware debugger setup (for pretty generic embedded ARM where skills transfer nicely from other commerical ARM ecosystems), and cases where the interviewer gets hung up on coding style.

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.

fit2rule2• 7 years ago

Dear Programming Job Recruiter,

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.

ordinaryperson• 7 years ago

If you say you’re a master of network protocols, guess what, I’ve maintained a TCP/IP stack, and unless you’re really a master I’m going to bury you.

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.

LandR• 7 years ago

Exactly, it sounds like this guy sees interviews as a way to feed his ego and make himself feel smarter than the candidate.

He would be a massive red flag to me as an indicator I don't want to work there.

8675678386942• 7 years ago

Definitely a solid pass on a job here.

davidhyde• 7 years ago

Something I don’t see enough of is developers who have a lot of recent interview experience (as an interviewee) being the interviewer. These devs are inevitably contractors so they are rarely chosen to be the interviewer in a company. Rather, the team lead who has been there for years is chosen. The thing is, as a person who has a lot of experience at being interviewed, I know the mistakes that interviewers make and they never get to learn this information. An candidate gets to correct their mistakes and become better at the interview process in preparation for the next one they do. An interviewer learns, 3 months down the line, that they have made some mistake but never learn what went wrong.

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.

thih9• 7 years ago

Looks like the author favours candidates that are able to adapt to his hiring process.

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.

ekzy• 7 years ago

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.

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.

myhf• 7 years ago

This is why I bring my split ergonomic keyboard with dvorak firmware to on-site interviews.

je422• 7 years ago

if you say you’re a master of network protocols, guess what, I’ve maintained a TCP/IP stack, and unless you’re really a master I’m going to bury you.

yep. :) all lot of applicants should take a note at this.

8675678386942• 7 years ago

I'd bet 10 bucks this guys built one shitty ass team of people and I'm not even talking about their programming skills. He's so caught up in being cheeky and a dick he shows how unskilled he is at building an actual performant cohesive team that works well together. He's not building a team of robots, well maybe he is. I'd bet another 10 bucks his salary/hourly rates are also sub-market.

thrax2• 7 years ago

TFW Dwight Shrute is your programming job interviewer...

jsqu99• 7 years ago

Programming _is_ like riding a bike...after a brief reimmersion. Maybe a little wobbly at first, but it's never taken me long to jump back into something that used to be an old friend.

Uptrenda• 7 years ago

This guy seems like the kind of interviewer to quiz you on how to type-cast a binary-void floating function-function pointer array to a U64_INT_WIDE TCHAR and then fail you for not using the right number of spaces in your code. Lmaoo. Would not work with / 10.

daniel-s• 7 years ago

I’ll brush up on Scheme myself just so I can give you a Scheme programming question.

That's when I realised the author was quite obviously lying.

GoToRO3• 7 years ago

Summary: if you don't know little thing X for sure you can't do Y! now and forever! because Y can no longer be learned!

"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-"

GoToRO3• 7 years ago

Oh, after they complain about everything that is not really important, they spend 2 weeks to create a user/pass for you and months to learn the project because the senior left.

Jemm• 7 years ago

"if you haven’t been programming for a while, you can’t program anymore."

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.

slyall• 7 years ago

He doesn't mean that you don't know the JavaScript framework of the week.

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.

rayraegah• 7 years ago

The article was okay to read but calling people out for not being able to use an editor you know how to use is low.

sys_647385• 7 years ago

This interviewer seems to have a machoistic view of interviewing people. At all times you should be treating people with dignity and respect, not trying to nail them to the ground to see them flounder.

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.

craftoman• 7 years ago

Write code on Gedit?

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?

SergeAx• 7 years ago

This brought me to full stop:

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.

Dear Programming Job Applicants (2010)

Related Stories