Live data from Hacker News

Dear Programming Job Applicants (2010)

joshcarter.com

31–40 of 199 posts

Re: Dear Programming Job Applicants (2010)

#31
post #15

Earlier quoted context omitted.

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

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

I interviewed for the first time in years in 2018 and hell yes it is stressful.

I wish every hiring manager had that experience as it gave me a lot of empathy for candidates.

Re: Dear Programming Job Applicants (2010)

#32
post #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

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.

Re: Dear Programming Job Applicants (2010)

#33
post #16

Earlier quoted context omitted.

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

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.

Yeap. Even the hard-core Emacs fanboys at my work know a few basic vi/vim commands. I mean, you're almost certainly going to use it at some point in your career, might as well learn "i -> type something -> :wq" at the very least.

Re: Dear Programming Job Applicants (2010)

#34
post #13

Earlier quoted context omitted.

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

Exactly! How is it relevant to the job if the applicant is able to adapt to a new editor and new keyboard quickly? Even with a new computer, they will set it up once and then never do it again. Let the programmer chose whatever language, whatever carefully crafted settings in IDE that make them comfortable, to solve the problem effectively, because that's what matters. Problem solving is influenced heavily by these seemingly irrelevant details. It's like inspiration, you need a clear mind for that.

Re: Dear Programming Job Applicants (2010)

#35
post #4

Earlier quoted context omitted.

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

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.

I wouldn't use those exact words, no :).

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.

Re: Dear Programming Job Applicants (2010)

#36
post #8

Earlier quoted context omitted.

Ah, but then you have a great data point, no? If someone cuts you off when you are interviewing, how will they treat you when you are an employee? The information flow goes both ways.

These are usually agency interviewers or HR people. Sure, I'd definitely take that into account if this was interview with IT lead, but you don't get to that before going through this programming task with some HR guy. They will then pass your solution to some devs for assessment, because they don't understand it. But they are the gatekeepers.

Fair enough. I haven't run into that, probably because I interviewed with smaller companies. I have no tips on solving that problem.

Re: Dear Programming Job Applicants (2010)

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

Re: Dear Programming Job Applicants (2010)

#38
post #10

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

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.

Re: Dear Programming Job Applicants (2010)

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

Post reply on HN