Hacker News new | past | comments | ask | show | jobs | submit login

This is a good post. Have been in the UK startup environment it was crazy how many companies got funding but didn't had a strong senior in their software department.

Because of this their hiring process was aimed to hire more "strong juniors" even tho they didn't realize it. A strong senior is a person who completely changes how you are even approaching the problem or someone who shows you problems you hadn't seen before. They often see tech in the context of business as well.

As you said, usually, they can't be bothered about learning the new framework of the month or new backend language of the month, but, they have a set of battle proven tools to solve tech problems for businesses.

P.S: I do find it hard to distinguish between bullshit talkers and people who actually get stuff done in the interview process.

There's times when i think i'm coming across as the bullshitter. "Tell me of an accomplishment you're proud of". I struggle with this one, but I've given this example years ago.

Worked at a company which did nightly data imports. Things worked until 'companyx' became a cEient, and the imports were huge. They would take 18-20 hours. Then longer. eventually they were touching the 24 hour mark - unacceptable. Client's data would be more than a day behind. Granted it was a moderate amount of data, but shouldn't take that long.

I was 'new' there - only started a month before - and the rest of the team who'd put this together had been there a year or more. I reviewed what was in place, took a couple of days, and got it down to an hour. Then worked with the existing team and we got it down to under 30 minutes with some tweaking.

I do see some eyes rolling when I tell that, as I know it can sound terribly self-aggrandizing. However, I had a decade of experience at this point, and the rest of the team was just out of college; they'd never faced this problem before. I basically just took the data and imported in small chunks in to in-memory tables (to avoid hitting the disk), and copied those to disk every X rows, and dropped indexes until everything was done. It wasn't rocket science, but did take someone who had a deeper understanding of DB mechanics.

As I'm telling this, I always realize they have no way of verifying this, and essentially I'm just another bullshitter. The more believable I sound, there's an equally high chance I'm either really good, or just a really good bullshitter, and nearly every time, the person I'm talking to has no idea how to tell the difference. It's worse as you get older, because the younger folks just think you're waxing nostaligic about the 'good old days'.

It doesn't help that in our field the context for many of these past achievements is quickly lost and forgotten.

You can't just say "I did X in Y by using Z": you need to begin by explaining that once upon a time there used to be a thing called Y, and on that thing it used to be very hard to achieve X, but in those ancient days there was also a tool called Z, etc.

This could be an example of the start of a competency based interviewing question. These questions usually start similar to "tell me about a time when". You ask for an example of them displaying some trait you care about, and then dig in to the details of what happened, why they did what they did etc.

CBI is a fairly effective technique for general interviewing, because you uncover how people actually behave rather than how they like to think they behave. Most of the gold is in the follow up digging questions, which should separate the bullshit answer from a real one.

I think it's also important for seniors to look at new ideas at a regular basis. People who don't, tend to overrate the "good old [insert language/framework here]". You should not stop improving yourself, just because you are already able to get stuff done. (Example: Java introduced lambda functions in Java 8 and many Java seniors are still not using them)

I think the difference a senior person can make is to see what things the new language/framework/paradigm still doesn't solve and think of ways to evaluate their risk to a particular project's requirements and how to mitigate that risk. Things like downtime for upgrades or migrations, handling dependencies on ecosystems of community developed libraries without quality and feature change controls, the ability to update the system when it's been in production for 3 years and see few changes have been made and the original developers have all moved on, etc.

> A strong senior is a person who completely changes how you are even approaching the problem or someone who shows you problems you hadn't seen before.

I think this is overstated. Disruption for the sake of it is often not that helpful in the context of the business (although, in fairness, you do go on to state they often see tech in that context).

I much prefer people who are delivery focused to those who are overly idealistic or want to change everything out of the gate: a good senior understands priorities and knows when to make a trade-off to live with a sub-optimal situation or solution in one area in order to deliver greater value elsewhere.

> I much prefer people who are delivery focused to those who are overly idealistic or want to change everything out of the gate

Do you have problems to solve or not? Often the problem isn't really a problem, except that your current 'solution' is making it so.

I've untied a lot of gordian knots in my career. It really is a thing.

And if you don't have big problems to solve, why do you want a senior developer then? Just hire a junior and keep on going as usual.

Delivery focus is good, till you realise that it's often just delivering status quo for years on end.

Great post

The higher you go the more compromises you have to make.

That said, nobody is talking about disruption, just wisdom.

It just so happens, sometimes that wisdom will tell you that shipping shit out the door in the name of delivery focus is going to cost you more than its worth in the long run. Calling them overly idealistic to justify your laziness just makes you look bad.

I'd say a truly good senior can tell the difference between a startup and a mature company and adapt accordingly. It takes one set of skills to ship shit out the door as quick as possible and an entirely different set of skills to come in and clean up the mess the kids left behind.

This is why you are selling. Not buying. Because nobody wants to clean up your delivery focused mess.

or... nobody wants to pay to clean up the mess. i know people who will do it. I will do it, but I can't clean it up, and delivery loads of shiny new features, and do it all while trying to justify every 30 minute block of time and asking if xyz is 'really' necessary. oh, and you also need to be able to answer some real questions about your own business process, because often your existing practices are just 3000 lines of crap in a function file. when you say "it's broken" and I ask "what's the correct behaviour?" and you don't answer... it'll never get 'fixed'.

I think this falls under the why are you hiring a senior?

Because hiring a senior to ignore the problem is a good way to waste a lot of cash.

Who's talking about shipping "shit"? You are overreading by a very wide margin.

I also don't appreciate being called lazy, and especially by somebody who knows nothing about my business or my team.

Please try to keep your tone civil in future.

I'm not overreading, you said you prefer shipping sub optimal solutions. Sounds like to me.

I didn't call you lazy, I said that shipping in the name of delivery focus was lazy, or at least your argument about idealism was.

Fact is, shipping quality is the far more optimal solution and always will be. Making the trade off and adding technical debt is never a worthy trade long term. The only people who gain from it are you and your team. The rest of the company eventually grinds to a halt and begins taking more and more shortcuts around the code which just reinforces everything in a viscous cycle.

You might find this useful: https://youtu.be/DngAZyWMGR0

> I'm not overreading, you said you prefer shipping sub optimal solutions. Sounds like to me.

I was talking about prioritisation. I am very wary (or perhaps jaded) with people who want to fix everything all at once with no regard to the wider effects on the business of doing so.

I didn't mention anything about quality with respect to what we do choose to deliver, although I can assure you that user experience - of which quality is a key facet - is our utmost concern.

I thought my intent was clear, but sorry if not, and hence my comment about overreading. I wrote very little from which you (and you're not the only one) appear to have extrapolated quite a long way.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact