Hacker News Reader

You have a quality of work mentality in a business running in a capitalist society. Theyre less removed and have to force you to abandon quality time to focus on new things just like your competitors.

There's little management innovation, they all mostly copy each other

> There's little management innovation, they all mostly copy each other

Boy this is the freaking truth isn't it? Makes you wonder where the innovation is going to come from because it certainly isn't going to be universities -- all those management textbooks used in MBA programs across the country are just utter and complete rubbish.

I'd rather spent 6 hours on a toy project instead of the 200+ hours I spent studying for Google. Solving problems on a white board is very different compared to solving problems on a computer with a plain text editor. I did significantly better in another interview where I was given a laptop connected to a projector instead of having to stand and write on a white board for 4 hours in one day.

The skills I would have to hone to do well in a Google style interview are very different from the skills I would have to improve to excel at my job. I wonder if Google prefers this system because the type of people that are willing to spent hundreds of hours honing their interview skills are also the type of people that are willing to invest a lot of their free time into their job beyond what is required.

> "...instead of the 200+ hours I spent studying for Google"

That sounds like an exaggeration. I'd bet that very few people who work here had to spend that much time preparing...

I got a job at Aflac on my first try. I was even offered my choice of jobs as I qualified for more than one position. I applied because my mother suggested it. It was outside of the field I desired to go into.

A coworker of mine spent 5 years applying and reapplying and trying to improve their qualifications until they finally got hired.

I don't see any reason to question the statement that GP invested 200 hours.

I interviewed there as an SRE many years ago (early-mid 2000's) and I was asked about mathematical algorithms, whether I'd published any books in tech, and what open source I contributed to.

I would have needed to study for a year or more of math since I never studied math in college, and I wasn't just out of college. Even someone with a computer science degree, once they've been a professional for a few years, would need to crack open college textbooks again to pass a Google interview.

Unless they did math as a hobby, which I will refrain from commenting on at this time.

It isn't an exaggeration. In the same time span (2 months) I spent about 90 hours playing Oxygen Not Included and about 60 hours playing Darkest Dungeon. And that was me trying to play games less.

When I started I didn't know what dynamic programming meant and I didn't know how to implement a breadth first search. (I thought it required a priority queue). So a lot of time was spent reviewing things like N Queens and dijkstra's algorithm because I hadn't touched it since university.

In the end I spent too much time on things I never got asked and I should have been practicing on paper instead of a computer.

I partially disagree.

In hiring you need some way to assess whether or not applicants can actually produce useful work. You can't get that from a resume, you can't get that from education background, and you can't get that from talking to people.

Now, you could just ask applicants for a sample of their work (preferably open source) and evaluate them on that.

Coding challenges probably get done instead of that because it is easier for companies to evaluate a single coding challenge than to evaluate a broad range of unique work from different individuals.

As an engineer the employment process gives you an opportunity to evaluate companies in the same way that they have an opportunity to evaluate you. If a company has a sub-par hiring process then you cross them off the list and move on.

We're not even going to get to the mutual evaluation part if we can't get past the initial hurdles.

You don't want to get to the mutual evaluation part with people who can't complete a basic programming task. That would waste an inordinate amount of your time and theirs.

They're not asking me to complete a basic programming task. They're asking me to greenfield a project and implement complex features, often under ridiculous constraints.

When looking for a software developer you're not just looking for someone who can implement a solution to a problem. Daily duties involve discussing issues and impediments, navigating organizational bureaucracy, managing code bases via source control repositories, troubleshooting environment issues, playing nice with other developer's code, updating ticketing systems, providing systems documentation, and writing maintainable code.

A coding challenge addresses none of that, it just asks the candidate to solve a problem. Often coding challenges are sent to candidates and there's no verification that they're even the one completing the work. I've spoken with many candidates who submitted coding samples or code challenges and were completely unable to discuss the code. Often times I wondered if their recruiter supplied the code and not the candidate because of their confusion surrounding the code.

I've had more luck accessing candidates by asking simple requests like "tell me about your daily duties at your last/present job" or "oh you've language x, what's your least favorite part of developing with it?" If the candidate can't discuss simple things with mild depth or command then they're probably not a good fit.

>I've had more luck accessing candidates by asking simple requests like "tell me about your daily duties at your last/present job" or "oh you've language x, what's your least favorite part of developing with it?" If the candidate can't discuss simple things with mild depth or command then they're probably not a good fit.

This is what I do. If an interviewer can be bullshitted doing it this way, they don't need to be interviewing. Non-technical managers really need to defer this sort of thing to technical people.

> If an interviewer can be bullshitted doing it this way, they don't need to be interviewing

There is no magical BS detector. You can't judge a person's skill without seeing them work.

Everyone I have met who thinks they are smart enough to not get duped by smooth talkers gets duped all the time.

>There is no magical BS detector. You can't judge a person's skill without seeing them work.

You are conflating the issues. A tech top can detect BS, but no one can judge a person's skill without seeing them work for several months.

Think of it this way. How long do you think it would take an MD to detect a fraud MD talking shop? Not long. How long does it take a military veteran to spot a fraud? Seconds. You have to be technical to spot the issues though. If something pops up that makes you think they are bullshitting, you have to drill in on it.

Those examples are not the same though.

You can have someone who has an extensive education in Computer Science and can talk about it all day long very articulately but has no implementation skills.

You might be able to catch someone with no comp-sci background by talking to them but not someone who has an advanced comp sci education.

The doctor example is relevant though.

Doctors don't get hired based on talking. They have to do residencies, get certified, and demonstrate ability before even applying for a job. Same reason. Someone could learn how to repeat everything in the text books without being able to do the procedures, which require practice to master.

To use our Doctor simile, you wouldn't ask about anatomy (or only briefly), you ask about diagnosing and treating ailments; that's what you are paying the person to do.

For technical interviews, you don't ask them about Computer Science things (or only briefly), you ask them about real-world software development; that's what you are paying them to do. The stuff they really don't go over in CompSci classes.

What was the project you were most proud of and why?

What was the hardest project for you and why?

What are some of the ways you've connected to a database / datastore (if applicable)?

What were some database design decisions you've grappled over? What designs were you considering?

What's the most impressive code you've seen written by someone else and why?

Tell me about how you organized classes in a particular project and why you did it that way.

Describe a way you've organized your classes and wish you had done it another way, and why.

How do you make sure if your software has a problem, you know about it and can figure it out quickly?

What's the hardest software you've written and why?

How do you handle disagreements with a colleague? Can you site an example of a disagreement and each person's reasoning?

Notice almost all of those examples asked "why." That's the most important part. If someone isn't up to par, they will do one of two things:

1. Answer Briefly. 2. Babble on to the point it's obvious they don't know what they are talking about.

#1 of course can be because the person is shy or intimidated or an extreme introvert, but not likely. Because you're talking about a subject they should feel extremely comfortable about, even introverts will come out of their shell.

Talking to someone is not a magical, but highly effective bullshit detector.

> I've had more luck accessing candidates by asking simple requests like "tell me about your daily duties at your last/present job" or "oh you've language x, what's your least favorite part of developing with it?" If the candidate can't discuss simple things with mild depth or command then they're probably not a good fit.

Being able to answer those still doesn't mean they can actually code proficiently, which would also make them not a good fit.

You seem to be swinging the other way too much. Not testing their programming ability just because other things are important doesn't sound like a great way to interview people, either.

Perhaps but we're not hiring for our autonomous car division, we're hiring people to write and maintain line-of-business applications based on half-baked requirements from non-technical business owners. The problems aren't terribly complicated and the code is relatively simple.

> My main disconnect with the hiring process these days is the near-ubiquitous use of code challenges that just keep getting more and more time-consuming.

They are still pretty rare as far as I have seen, at least any that are especially long.

> Code challenges are sucking all the liquidity out of the job market...

How exactly do they do that?

> One challenge asked me to do everything in Vanilla Javascript.

As if wanting a candidate with a reasonable level of knowledge on that is outlandish?

> Code challenges feel incredibly lazy to me.

I'd love to know a better way to weed out the people who can talk the talk but can't walk the walk. And every time I ask, the best response is something absurdly vague like, "I'd just talk to them and know, because I'd know what to ask them."

> Your organization sucks at hiring, so let's throw all the obstacles we can at applicants and see who makes it through.

As if testing for basic programming proficiency is 'all the obstacles'?

Re sucking liquidity - any good candidate will go "fuck no" and your left with candidates "in need of some improvement" or those who rote learned through a CS degree.

Is that really bad for the programmers in this case?

If you can't trust the five years of industry experience I have and my ability to convey that experience in an interview, then I don't need to deal with your company. I'm sorry if you guys are so bad at ascertaining a candidate's rough skill level from a conversation. I'm not.

One code challenge is fine. But if they're all asking for them then applying for a job while I still have a job then I'm spending 8+ hours of my free time a week just doing code challenges. I'd have to really hate my life before that becomes something I want to do.

I don't know what segment of the job market you're in, but in mine it's getting a lot more common. They're treating mid-level and senior candidates like recent grads.

How would you fairly evaluate 20 candidates in a month or two and make a couple of hires?

This question lacks context. What sort of business are we dealing with here? SaaS? Consulting? Game development? Are we making websites? What does the existing technology look like?

From these questions I can come to an understanding of what sort of talent is needed. Can we get away with junior talent or is a senior perspective required? What sorts of management resources are available, will we need the candidates to take on those roles too?

Sit down with them, have a decent human to human chat, and see if they can at least talk like they know their shit. If you dig down in conversation deep enough you will figure out what they truly know even with the bullshitters, if you are a domain expert yourself. If not you are unable to evaluate someone in any case.