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.
Dear Programming Job Applicants (2010)
121–130 of 199 posts
Re: Dear Programming Job Applicants (2010)
#122"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.
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…
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.
Re: Dear Programming Job Applicants (2010)
#123> 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.
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'…
> 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
Re: Dear Programming Job Applicants (2010)
#124> 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…
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.
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.
Re: Dear Programming Job Applicants (2010)
#125> 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…
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.
At the top he wrote something about putting on a flame suit.
Re: Dear Programming Job Applicants (2010)
#126Earlier quoted context omitted.
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.
Is it? There's plenty of amazing engineers and systems architects who develop (gasp!) on Windows and don't even use command line. And many many of those have designed highly reliable systems driving your basic infrastructure, power plants, industrial systems and myriad of other systems. Why on earth is knowing an old editor connected to anything useful you need from a person in a job?
Honestly I don't know a single good Windows guy that don't even use command line, there are basic things like ping, tracert, curl and openssl that you run in a command prompt. This is assuming you can get around using powershell.
Re: Dear Programming Job Applicants (2010)
#127Earlier 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 find it very hard to think about the problem and to think what to say to this person without fucking up the interview.
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.
Re: Dear Programming Job Applicants (2010)
#128Earlier quoted context omitted.
#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 o…
And just because someone solved (or didn't) a whiteboard puzzle doesn't mean they have (or don't have) the skills for the job you're hiring for. I would argue that actual working code out in the open speaks more than a puzzle solving session.
Re: Dear Programming Job Applicants (2010)
#129A 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…
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.
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.
Re: Dear Programming Job Applicants (2010)
#130> 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.