Live data from Hacker News

Dear Programming Job Applicants (2010)

joshcarter.com

111–120 of 199 posts

Re: Dear Programming Job Applicants (2010)

#111

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 hi…

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

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

Re: Dear Programming Job Applicants (2010)

#113
post #101
post #48

Earlier quoted context omitted.

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…

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

Yeah, but lying to that extent is a huge red flag, not just saying your Spanish is "mediocre" instead of "beginner".

Re: Dear Programming Job Applicants (2010)

#114

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

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 thin…

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.

Re: Dear Programming Job Applicants (2010)

#115
post #70

Earlier quoted context omitted.

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.

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.

I learned vi by being too lazy to change my default editor in git..

Re: Dear Programming Job Applicants (2010)

#116

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

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 thin…

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.

Re: Dear Programming Job Applicants (2010)

#117

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

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 thin…

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.

Re: Dear Programming Job Applicants (2010)

#118
post #54
post #52

Earlier quoted context omitted.

I only have to edit a file on Linux once every couple of months of so - I tired of forgetting how to exit vi (or enter/exit edit mode, save the file... just about anything really), so started installing nano as the first thing I do on any system. Nano is so much more obvious than vi.

Also, there's a reason why there are so many "can't quit vi" memes.

Reading the comments about vi... Am I the only one that knows/uses ZZ to save and quit?
Post reply on HN