Live data from Hacker News

Dear Programming Job Applicants (2010)

joshcarter.com

11–20 of 199 posts

Re: Dear Programming Job Applicants (2010)

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

Re: Dear Programming Job Applicants (2010)

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

Re: Dear Programming Job Applicants (2010)

#13
post #3

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

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…

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.

Re: Dear Programming Job Applicants (2010)

#14

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

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.

Re: Dear Programming Job Applicants (2010)

#15
post #5

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

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.

Re: Dear Programming Job Applicants (2010)

#16

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…

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

Re: Dear Programming Job Applicants (2010)

#17

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…

Get them coding on a whiteboard, problem solved :)

Re: Dear Programming Job Applicants (2010)

#18
post #5

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

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.

Re: Dear Programming Job Applicants (2010)

#19
post #3

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

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.

Re: Dear Programming Job Applicants (2010)

#20
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?

Post reply on HN