Live data from Hacker News

Programmers are confessing their sins to protest a broken job interview process

theoutline.com

171–180 of 238 posts

Re: Programmers are confessing their sins to protest a broken job interview process

#171

Hello, my name is Tim. I'm a lead at Google with over 30 years coding experience and I need to look up how to get length of a python string. The problem with Python is the arcane, arbitrary and nonsensical syntax. It sure as hell isn't anything as obvious as length(str) or string.length like any reasonable language. And god help you if you want to do something complicated like define a function. But seriously: I have…

As someone who has worked with a lot of languages over the years I can never remember which one is `length(x)`, `len(x)`, `x.length`, `x.len`, and so on.

For me the answer is "never", apparently. Then again I tend to struggle with basic syntax no matter what language I'm using or how frequently I use it.

Re: Programmers are confessing their sins to protest a broken job interview process

#172
post #94
post #11

“Never memorize something that you can look up.” -- Albert Einstein

I disagree with this quote. There is value in memorization. Times tables are an insanely useful thing to memorize. Memorizing historical events and literature can make you into a great lateral thinker.

I think you're taking the quote the wrong way. I believe there is an implicit "work to" that isn't being stated.

'Never (work to) memorize something you can look up.'

This has the meaning of, let your (short term memory) figure out based on how often you look something up if it should be remembered or not.

Re: Programmers are confessing their sins to protest a broken job interview process

#174
post #101
post #6

> Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles. Does the interviewer explain what bubble sort is, or do they expect the candidate to know it? The first is a reasonable interview, the second one isn't.

I guess I would expect just about anyone to know what a bubble sort is, but I wonder if that's bias from the classes I took. Every class on algorithms I ever took would start off with a bubble sort as an example of a sorting algorithm, then use it as exhibit A for figuring out the big O performance of an algorithm (the outcome of which was always, "...and that's why you should never use a bubble sort"). I assume that…

> I guess I would expect just about anyone to know what a bubble sort is, but I wonder if that's bias from the classes I took.

It was covered in my first year CS courses... something like 9 years ago. I've not once needed to be able to re-implement it (or any sorting algorithm) in the intervening time finishing my degree and five years doing software dev as my day-job, much less re-implement it from memory. I would need to look it up to refresh myself on its implementation and characteristics.

Re: Programmers are confessing their sins to protest a broken job interview process

#175
So this makes me think: Has anyone here, when presented with a whiteboard problem, tried to google that problem (or algorithm) during the interview?

I'm generally not a fan of whiteboard problems because: 1) They don't test what I most care about (architectural things) 2) Why not just pull up a laptop and go at it?

but one thing I'd say in defense of them: Thinking through a problem on a whiteboard is a valuable skill I have frequently used.

So it seems the problem is less about "problems on whiteboards" and more about a) the kinds of questions asked and b) the "unrealistic" "working environment".

Re: Programmers are confessing their sins to protest a broken job interview process

#176
post #89

I'm conflicted about this. On one hand I agree with the idea that the best way to test whether someone can do something is to look at evidence that that can do that actual thing (i.e. write real code using best of breed tooling). On the other, a whiteboard provides a very real constraint and tests something a little less tangible than can someone copy/paste. A whiteboard test is not just a test of 'can you solve this…

I wrote a bubble sort in Grade 12 but I can't remember the details well enough to write BUG-FREE code to do it on a whiteboard. Nowadays if I want to sort, I use quicksort() or I use the accepted language way of sorting list.sorted() in Python for instance, or I write an ORDER BY clause at the end of my SQL statement. And so should you. Writing sort algorithm code is a dumb thing for a software engineer to do and I d…

> I wrote a bubble sort in Grade 12 but I can't remember the details well enough

I'm not sure that I've ever written a bubble sort. Like I mentioned, this is a derivation purely based on the name of the algorithm and some vague recollections from my childhood.

>to write BUG-FREE code to do it on a whiteboard

Do you think that you'd want to work for an employer that expected bug free code to be written on a whiteboard? I wouldn't either. But I would work for one where if they noticed a bug in code that I wrote, we then talked about the bug and what the impact of that would be and fixed it. This shows communication skills, as well as the humility to be able to admit situations where you're wrong and take action to fix it.

> Nowadays if I want to sort, I use quicksort() or I use the accepted language way of sorting list.sorted() in Python for instance, or I write an ORDER BY clause at the end of my SQL statement. And so should you.

You know, a whiteboard coding task can be a good place to talk about alternatives. It's not just a place to jump straight to code solutions. If you're treating it that way you're missing out on a bunch of opportunity to sell yourself as a potential employee. All of the above are valid topics of conversation that show your skills and experience. They're not wrong. In a recent interview I was asked to solve something and my first response was "There's only 2000 or so cases, write a lookup table, move on with life, but you know that doesn't show that I can code, so here's the solution you're looking for that would fill that lookup table".

> Writing sort algorithm code is a dumb thing for a software engineer to do and I don't care if you have never heard of bubble sort because it is useless historical knowledge for everyone except historians.

Given that you want to understand how a person communicates when talking about and writing code, what would you ask instead?

>Just consider these whiteboard interviews as a way of warning you that the potential employer probably is not such a great place to work after all.

I don't think this is the case at all. The conversation you have in front of that whiteboard is significantly more telling than the presence of an erasable writing surface.

Re: Programmers are confessing their sins to protest a broken job interview process

#177

I actively interviewed job candidates while my wife went through her licensing process to be a doctor. A doctor's job interview spends no time making sure that a doctor is competent. Why? Because the licensing process does that. The most frustrating part of interviewing a software engineer job candidate is that a degree doesn't show that the candidate is competent. Thus, we need to waste our time on imperfect ways to…

I feel ambivalence about formal licensing, but I do agree this would be a positive element.

I would be, even 15 years after the fact, perfectly happy to study intensely for an exam on basic math, data structures, and algorithms, similar to the initial mathematics exams used for the actuarial field. Such an exam would be a lasting and widely respected credential, consistently administered and graded. I wouldn't want to put this kind of effort into a single corporation's exam, because those are graded in secrecy, I have no idea what the credentials are of the people who evaluate it, and I don't get much (any) feedback other than "we decided not to continue with your application at this time...".

My worry comes from regulatory capture. I'd hate to see something like a bar association that forces people to go through a very expensive three year post graduate degree, putting them deeply in debt, in order to meet licensing requirements. Would the governing body be allowed to deny math or physics or non-cs engineering related majors the right to take the exam?

Also, imagine if people who wrote the EJB spec or the ones who decided all client side code should be written in tag libraries gained control over the licensing procedure? Would the test-driven advocates be able to revoke the license from anyone who publicly questions the value of test-driven methodologies?

This could be great - something along the lines of the actuarial exams are appealing to me, as they are rigorous but allow different educational paths to prepare. But this can also go very wrong, it is a real risk.

Re: Programmers are confessing their sins to protest a broken job interview process

#178
post #36

Earlier quoted context omitted.

I throw real life problems I've run into (and fixed!) at people and ask them to give me things they would do to troubleshoot, and compare it to what I did. Always nice when somebody suggests something new. I also ask 10,000 foot questions. "Say you're wanting to build a new app that behaves like Instagram. What's your hosting platform, your technology stack, and explain why?".

> I also ask 10,000 foot questions. "Say you're wanting to build a new app that behaves like Instagram. What's your hosting platform, your technology stack, and explain why?". Please forgive the uncomfortable question but isn't that a tacit admission that many developers' role consists of simply gluing together libraries and frameworks built by better engineers who actually do know how fundamental algorithms, etc. wo…

"simply" indicates you've never tried to stand up a fairly recent javascript stack :D

that being said, you're not wrong. Maybe 5% (maybe less) of the guys out there are smart enough to build libraries and frameworks. the next 45% of the guys out there are smart enough to see all the pieces and figure out how to fit them together.

the other 50% understand syntax and can write code, but aren't capable of any sort of bigger picture stuff.

and if my recent interviews are any indication, the split outside of silicon valley is more like 2/18/80.

Shoot, I'm not in that "let's build brilliant frameworks" crew. I don't think I am at least. Haven't really tried :D

Re: Programmers are confessing their sins to protest a broken job interview process

#179

Has anyone ever noticed that a whiteboard is the 1960's way of writing code? I started in the 80's and we used a scrap of paper sometimes and then a video terminal to type the code into an editor. Does anybody do coding interviews using an IDE hooked up to a fully functional Virtualbox server complete with all the usual tools?

We sometimes use online code editors

Re: Programmers are confessing their sins to protest a broken job interview process

#180

Earlier quoted context omitted.

I would say further, that If you are in a position to be implementing some non-trivial algorithm that's not currently in the toolbox, then your best approach is probably to go read a few papers first, and make sure that the algorithm you're looking at has not been surpassed. (Or, perhaps, you just need to dig something up from the '70s. A lot has been forgotten). Then again, if you can implement Paxos on the first tr…

I just googled Paxos and I still can't implement it. =(

Try raft. It's the easy version that works most of the time.
Post reply on HN