Hacker News new | ask | show | jobs
by madracerx 3597 days ago
Interviews suck specially for senior developers. Why should I have to prove myself over and over again by doing idiotic basic algorithm type of questions on the whiteboard? After having worked for over 25 years as developer in major companies, shouldn't interviews be about a conversation? - can you imagine interviewing medical doctors the same way we interview in the tech industry? DR. Smith, please show me how you do open heart surgery in this dummy here... (because most interviews happen at the whiteboard)...
11 comments

I'm a pretty senior developer. I really don't mind doing coding questions. after all, thats what we do, isn't it? As someone mentioned there are plenty of people that are good at projecting experience without actually being very effective at their jobs.

Whats annoying and disappointing is if the questions are at such a low level that there is little room to shine. You leave after your day not feeling as if the employer gained any understanding about you, and you certainly weren't able to get a read on your prospective peers.

The purely conversational interviews almost invariably lead to disappointment for me. The company is so desperate to fill a slot that they ask you probing questions about your work style. They spin grand portraits of exciting collaborations, novel development techniques, fundamental problems of concurrency and consistency. In the end they just want someone to respond to minor bug reports in their massive taped together codebase and make sure the servers stay up.

The part that I fear is the seemingly cookie cutter questions for CS grads, not for developers for that position. I've been doing software dev for almost 3 years. Never had to implement a red black tree. Nor could I, since I never took CS at school.

I'm very good at my job but would bomb the technical part of many of the traditional interviews.

I'm not the biggest fan of the algorithm-theory centric hiring regime, but "implement a red black tree" is a straw man. Even the most CSy interviews are at the level of contiguous vs. linked data structures, binary trees, and recursion, not at the level of very specific algorithms with intricate details like red black trees.
> I'm not the biggest fan of the algorithm-theory centric hiring regime, but "implement a red black tree" is a straw man.

I think it comes from the "Get that job at Google" blog post[1] by Steve Yegge. It is not clear what Steve means here, but he wrote:

  You should be familiar with at least one flavor of balanced 
  binary tree, whether it's a red/black tree, a splay tree or 
  an AVL tree. You should actually know how it's implemented.
I understand the gist of a R-B tree, I can probably write the immutable one on a whiteboard, but I don't think I will ever be able to implement the mutable insert/delete methods on a whiteboard. I have never been asked it in an interview yet, though.

[1]: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...

That question is a filter for "recent graduate" i.e. young, without setting off any HR alarm bells.
you know. thats legit. some people will respect that and find other questions to ask that will convince them that you'll help them out alot.

and some people will be disgusted, and they probably aren't that great to work with. it would be sad if you couldn't find a job, but i doubt thats the case :)

I bet you do mind, specially if they ask you to do these on the whiteboard. What we do has nothing to do with basic CS questions... unless you have a very unique job. It can be done conversational if you know how to conduct an interview. Unfortunately, this is a skill that most programmers lack. best way is to pair program on a real world problem. Get your candidate to pair on fixing a bug on your system.
>shouldn't interviews be about a conversation?

sounds wrong to hire the best conversationalist. I know many people who are all talk and no substance.

>an you imagine interviewing medical doctors the same way we interview in the tech industry

they are already certified by the boards. Computer science degree is not equivalent to medical board certificate.

> sounds wrong to hire the best conversationalist. I know many people who are all talk and no substance.

Talk only goes so far. It isn't hard to make a poseur look like an idiot if you know what you are doing. A "Five Whys"-style line of questions, for example, will blow up most fakers in a few minutes. After all, how do you know these people are all talk? Is their talk really convincing to a technologist or does it just dazzle non-technical people?

> they are already certified by the boards. Computer science degree is not equivalent to medical board certificate.

People like to overstate the power and effectiveness of medical licensing boards. Very few doctors have to prove anything after their residency. All they need to do is complete continuing education requirements (which, in many cases, are pretty fluffy). That's for the most regulated of the regulated professions, too. Lawyers, accountants, engineers, and others have basically one major hurdle to jump, after which it's easy to remain current by the letter of the law.

Of course it would start with a conversation and then move on to the implementation where the ones with knowledge would shine through. Having the same start line as someone fresh out of college does not give an experienced person, the chance to demonstrate his abilities. And also after some time it can become boring to brush up the same old algorithm style questions in my opinion.
They have certification. Imagine if they had to distinguish themselves from an army of mouth-breathers with just enough coaching to know which end of a scalpel is pointy.
It's the shiny end, right?
If the questions are relevant to the job, it shouldn't matter if the candidate has 0 or 25 years of experience, because longer experience doesn't necessarily imply greater skill. That being said, it's legitimate to ask whether all those algo questions are actually relevant to begin with.
your willingness to be condescended to by someone with approx 10-15% your years of experience is a litmus test as to whether you will be a good 'culture fit'. age won't count against you as long as you're willing to put in the hours, eat dinners at work, put up with scrum management, etc etc.
On the flip side, I just interviewed two candidates claiming 10 and 16 years of experience for a "Senior DevOps" position. Neither of them could tell me what a default route was - one of them spewed some nonsense buzzwords and the other one thought it might have something to do with DNS.
DevOps is a culture not a job.

Most good candidates know this, and will actively avoid "DevOps" roles.

Now someone claiming 10 - 16 years experience as a DevOp, is : A: Lying. The term is 6-7 years old B: If they have even been using / administering computers for that long should know what a default route is.

Could they have misinterpreted the question? I know the even at a senior level, interviewees can get flustered and confuse themselves.

I didn't write the job title/posting, but the description makes it clear that strong linux and programming skills are required. These folks have 10+ years of "software engineer" and "systems administrator" jobs on their resumes, they're not claiming specific "devops" experience. I just talked to two more similar folks and I'm starting to despair at the state of the industry.

What job title would you suggest to find people with a working knowledge of programming, config management, and infrastructure/systems internals? If all you can do is copy-paste jenkins tutorials off of the internet, you're not a "senior" anything.

DevOps doesn't imply network knowledge. It can include CI/CD, dev tooling, automation, containers, cloud engineering etc.

Just saying in case you and your candidates have a different idea of the role you are hiring for.

I'd say that network knowledge is a key part of the Ops part of DevOps (especially when talking about cloud engineering).

But that is what you get with great buzzwords like DevOps.

I'm not saying I agree with the interview process of developers however it's much harder to become a doctor than a developer. Not to mention faking it and hoping you make it is very common in the software IMO.
Totally understand your viewpoint, with your level of experience it's borderline offensive to ask you to jump through similar hoops as a recent graduate. Arguments of standardization/filtering and homogeneity of candidates aside, let's be a little contrarian.

You've been doing a job for x years. There's been some personal development and it's been challenging (maybe you're now managing 10 developers and are having to write proposals, for example) but ultimately you've not had to prove yourself in the way you do in an interview in over a decade. What's to say you haven't allowed other aspects of your skillset that you've acquired over the years? If you're reviewing 20 peoples' code per week, when would you have had time to code out your algorithms? Using your own example, it's not at all unusual for senior doctors to lose their skills at suturing or putting in IVs. That's not to say that they've not acquired other valuable skills but there's also something to be said about keeping your fundamentals sharp.

Now maybe I've been drinking the kool-aid, but my understanding is that at your Googs and FBs they have open remits and expect their staff to be dynamic and quick to learn. One of the most valuable skills in that case is sharp fundamentals.

Losing that familiarity with the nitty gritty is a perfectly human thing, I saw it happen with professors being "outsmarted" by undergrads while at uni and early into my professional dev career I am already feeling certain aspects of my skill base deteriorating, I can only imagine what it'll be like in a couple of decades.

With all that, it's not hard to imagine why your big 5 do have such rigorous hiring loops, especially when they're already oversubscribed...

> If you're reviewing 20 peoples' code per week, when would you have had time to code out your algorithms?

You work on system design, databases, high availability and making sure large clusters don't fall and are able to talk to each other. None of the above require "algorithms". Also, it's hilarious how every company are asking the Google and FB questions now. And, you rarely get a SQL or database questions. I've had to work with colleagues who think they know everything just because they answer the algorithm question and can't do a simple "group by".

I see your point. However, a shitty surgeon would likely kill someone which would terminate his/her practice. A shitty programmer would keep making shitty software until the day he/she retires. Having said that I do agree that a simple technical conversation works well. The trick is weeding out the talkers which is fairly easy to do once you get to the nitty-gritty stuff and their wheels fall off.
Surgeons can sometimes get away with doing shitty work for a long time: "Paterson is charged with 21 counts of unlawfully and maliciously wounding 11 patients between 1997 and 2011." [0]

[0] http://www.birminghammail.co.uk/news/midlands-news/ian-pater...

Oh so you get interviews? I get asked to do 2 - 4 hours of unpaid dev work on my weekends in order to get a phone screening or an onsite... maybe.

So far that's pretty much been a deal breaker because I have other things I'd like to put my energy in, but eventually I'll just implement a generic rest api that handles common interview cases in languages I want to interview in, and use that, and adapt it as needed.

The medical profession has AMA that does a pretty good job of protecting their members. Maybe we need a Software association.