Hacker News Reader

Comment by weeksie | Hacker News Reader

If you're an emacs user there's nothing worse than doing an on-site interview where someone wants you to pair program using their editor. Nothing works right and you spend half the time flipper-handing it over the keys trying to remember how normal editors work.

Then again, it's rare that I interview anymore. I've done maybe two of those kinds of (pair programming, someone else's rig) interviews in the last ten years and neither was for a job that I really wanted after spending time with the devs conducting the interviews.

You want me to consult with you? Let me talk to your biz people to see if I'm the right person to solve your problems, and let the technical folk go over code I've written and we can deep dive on that if there is any question about my chops. Otherwise, fuck off. I'm too old to play "dance monkey".

View on HN

I sort of hear you. Having said that as someone who has done a lot of hiring in the past we'd pass on someone like you immediately unless you came very highly recommended. We need a consistent process to have any basis for comparison over time. Also your "fuck you, I'm not a monkey" attitude almost always shines through during initial screening call and is the last thing we want to bring in.

I do feel for you. Maybe we're about the same age and level of experience? It sucks to be put through some one size fits all hiring process and it sucks to constantly feel like more jr people are reinventing process and best practices every few years. But what are you going to do if you are a consultant? you have to be the boss or you have to play ball.

While teams do need leaders with experience they also need collaborative (vs combative) team players who can ride out the details and help improve hiring and work process in a positive and constructive way.

I think more experienced devs get jaded. It is a trap IMO and probably contributes to a lot of the ageism that is perceived and that really exists in the industry.

The OP has a point. Pair programming into somebody's else code, with no context of the overall functionality, and having to use somebody's else system (different shortcuts, editor layout/environment), is a very poor experience.

I have been in two of them, and they were not a pleasant experience overall.

Most senior engineers take some time to understand what's going before diving into somebody's else code and making changes left and right. We all have that experience where fixing a bug, the right way, starts causing/surfaces other problems in the system. I am talking as a dev that has shipped multiple apps, and some of them very successful.

In anyway, if it works for you, keep on doing it, but it will absolutely turn off the more experienced folks from your company.

That has been my own experience as well.

I noticed that companies with rigid hiring processes usually also have rigid development processes and those are indeed highly toxic to experienced engineers. I've seen my share of companies whose senior engineers were quite below average, but since they have no other engineers to compare to they come out as rock stars!

This is in stark contrast to companies whose hiring processes are tuned towards more experienced folks.

I would much rather work with someone that says "Fuck you I'm not a monkey" than with someone who encourages me to "play ball".

Interview is a two way street. He's interviewing you and your organization as much as you doing on him. Your organization's rigid rules and attitude speak volume about the culture. He'll probably filter your organization out early in the process as well. Good for everyone.

I think jaded developers get jaded.

I'm hardly a spring chicken, but despite watching the industry rediscover the same things over and over, thinking they are discovering something new, and despite the industry looking almost nothing like when I started, and despite all of the crazy broken ways things get done... I _still_ get goosebumps over how excited I am to be working on software.

Getting jaded is giving up. I'll give up when I'm dead.

Sure, I'm 20 years into my software career (with another 10 dabbling as a child) and I still feel that same excitement about the actual work.

But the interview process? I went basically 18 years without a serious interview on the strength of my reputation, and then I jumped head first into the modern SV interview process and suffice it to say I got extremely jaded extremely quickly.

If you'd been interviewed in that way, probably you didn't want that position anyway. Unless it was an interview with Google, in that case they advertise upfront - they have high false negative rate.

BTW - if you are looking and interested in autonomous driving / NVIDIA, ping me on LinkedIn. Same user ID as on HN.

I mean you are justifying why your process is the way it is from the perspective of the company. Great, no one doubts you have your reasons. But does the candidates perspective not matter?

He rightfully doesn't want to spend 3-4 hours of his time on an artificial interview process. You can call that combative or jaded, I call it knowing what you are worth. Or just protecting your limited time on earth.

Seems like you ultimately do want monkeys who consistently put their own interest behind the company's. No surprise that older people are less willing to do this - its not because they are "jaded", its because they recognize that no one else will put their interests ahead of their own.

Its a 2-way interview though, so overall you both steer clear of each other - great.

I see the particulars of the interview process as just another part of the negotiation around a potential business agreement between an employee and an employer. If you have a good BATNA, maybe you can push back a bit. If you don't, then that sucks for you, but I don't see why the company wouldn't pass you over for someone who's a bit more willing to jump through some hoops. It's not just about being a "monkey"; it can also be seen as a metric of how much a candidate wants the job, and all other things being equal I'd much rather hire someone with enthusiasm.

Or maybe (as you say) a candidate will simply disagree with a potential employer's philosophy on interviews and drop out of the process for that reason alone. That's fine too, and if a company's process is so onerous that nobody worth hiring is willing to go through it then that's on them.

I agree 100% with the direction of your conclusion - different companies can have different cultures / different processes and candidates (especially experienced ones with high market value) can just go with whatever style of company you feel is best.

That said, your characterization of the parent as wanting "want monkeys who consistently put their own interest behind the company's" is missing a key third stakeholder besides the company and the candidate - and that's the other employees! In my experience, a company built around a strong collaborative working culture will have employees that a) want to see what it's like working through a problem with you, in some form, b) feel that an environment where every incoming candidate has to pass the same bar, regardless of pedigree, is fairer c) prefer working with others that exhibit the humility you characterize as being a 'monkey'.

Again, ymmv, choose the culture you want, etc...

Hmm honestly there are better ways to let your employees get to know a candidate than a 1-hour tech screen - how about a 15-minute chat instead? And if you need a tech competency bar that fresh college grads generally do better on than experienced devs to manufacture a social consensus on fairness, I feel your team does not trust the interviewers enough.

My idea of a collaborative working culture is where

1. we trust each employee to do their job well enough that we do not have to look over their shoulder

2. we respect each employee enough that we value their time

3. we can work together with low friction

I would not characterize these positions as a lack of humility. The use of 'monkey' was in the sense of OPs use of "dance monkey" where candidates go through a ritualized process that tests little but mostly serves to preserve a social illusion of fairness. Pedigree is one thing, actual experience and references to back it up absolutely is a reason to "bend the bar" unless preserving the appearance of fairness is more important than actually evaluating skill.

But overall, thank god for free choice. These are very different value systems I think - manifesting as differences in interview style, but they are more fundamental political differences.

I agree that the technical screening can go away and be replaced by a chat. I've gotten to know new employees at my work by going for a beer with them and asking "Oh so your iPhone's jailbroken? How'd you do that?" or "So I saw you're using Gnome3, why do you prefer that?" and most of the time they're pretty eager to give a well-thought-out explanation behind those sort of personal computing choices. I really enjoy working with the people who are well-versed in some niche topic like that and can communicate its 'good-enough practices' well.

Money quote: "You have to be the boss or you have to play ball."

Pretty much sums it up - when you reach a point of having so much experience you know what has to be done, and how to do it, you'll inevitably take exception to others trying to tell you what to do and how to do it. At that point you could step up and be the person who communicates & reinforces that with the team. People need that, especially if you're the kind who's right often, and helps people.

What's awkward for a lot of engineers is of course the fact that getting into a leadership role inevitably takes you away from the kind of work that first made you get into the business. You have enough experience to know how things should go, but too much experience to continue being an "individual contributor" as they say.

Consulting seems like an interesting "middle path" in that you're an expert and a leader in a way, yet you might still get to do some actual work sometimes!

> At that point you could step up and be the person who communicates & reinforces that with the team.

You have a year or two when you can do that with authority without being in the code day to day. After that, you're a fucking blowhard.

Wow lots of pretty defensive responses. I'm not saying, nor did I ever say I did want monkeys. And anyone who has ever worked with us I'm 100% sure would not consider us to be rigid or obsessed with process. I'm just saying you can be constructive and flexible in acknowledging the company's challenges as well vs just saying "fuck you". I really don't get how that message was turned into "your company is rigid and you probably get filtered by sr devs". We have very good Sr devs and have very good luck recruiting them compared to the challenges most face in SF.

Also to be clear we don't do 1-1 pairing sessions in our code using our editors (nor did I say that either). My point was entirely that a "fuck you I'm not a monkey" response is pretty jaded and that jaded developers, even very sr devs, have a cost all their own that no company should want to take on.

To be fair, the OP was not "fuck you I'm not a monkey".

And your response to it was deftly passive aggressive. Kudos to you on mastering that tongue.

"Let me talk to your biz people to see if I'm the right person to solve your problems, and let the technical folk go over code I've written and we can deep dive on that if there is any question about my chops."

I feel you here.

With becoming longer of tooth (in the trade) comes an understanding of how to contribute value via the multitude of avenues that are not just grinding out lines at the keyboard.

I am surprised over and over at the incandescently bright young people who can wax lyrical about monad transformers, but to whom it does not occur to model a domain properly before cutting code, or who lack basic schema design and/or SQL knowledge.

I am also in the boat of having vanishingly few technical interviews in recent years, but on a good deal of those occasions it has been obvious that the interviewer is just so not the person I should be talking to.

Modelling a domain is very underrated by companies as well as individuals and it's a shame because we end up with code bases full of mixed purposes language and confused naming that makes it harder to work on legacy.

Monad Transformers FWIW are bread and butter in Haskell. So it a bit like going on about dependency injection. Not necessarily a sign of being stuck up or head in the clouds.

In some circles writing Haskell in the first place is a sign of having one’s head in the clouds.

Feels that way in the c# world sometimes. Ironic given the love for Linq, Rx, Generics, Lambdas etc.

Where do you think these ideas come from? :)

Microsoft has Haskell in R&D pushing ideas to F# which in turn pushes them to C#.

https://aphyr.com/posts/342-typing-the-technical-interview comes to mind about now...

How old is old?

I'm 37 and being working as a coder since 21. I still need to apply to job ads and go through the tests. Not all have whiteboard but most have a puzzle. I don't begrudge 2 hours which is the usual time, but I'd probably reject whole day tests.

I don't tend to stay friends with people for the sake of "having connections" but usually just to be friends. That means I don't have a big network to draw upon. There are so many advertised opportunities I'd miss out on if I said only get jobs through a network.

I'm 40.

Some of my work I get through my network, for sure. But I'm picky about what I work on which means that I will often do business development for myself and actively cold call/hustle to scare up work in the area I prefer to be in. Strange for a dev, I know, but it's definitely been worth it for me.

I also like to take a lot of time off between contracts to give myself time to pursue non-dev activities and finding the right balance is hard without actively developing my clients.

For instance I'm finishing up a contract right now that was a green field build-out of a brand new product using Elixir. The only way to find that stuff (unless you're lucky) is to go out and dig it up.

I like your approach and I'm slowly going to head in that direction. My first step is to blog decent content and interact online in the right places.

I presume with such an approach there is increased $/day meaning the breaks can be taken without any financial sacrifice as compared to the 9-5?

The pay is definitely better, more than makes up for 9-5. Can't recommend it enough :)

Otherwise, fuck off. I'm too old to play "dance monkey".

Good strategy. The "game" has gone on for so long, now -- and become such absurd caricature of itself (apparently without the participants being aware of this fact) -- that it brings to mind the closing line from WarGames:

"Strange game. The only winning move is not to play."

> "Strange game. The only winning move is not to play."

That's demonstrably false. If you're willing to put up with whiteboard tech interviews you have access to companies that enforce them but will pay very highly, regardless of what you consider their merit to be to hiring in general.

If you're willing to put up with whiteboard tech interviews you have access to companies that enforce them but will pay very highly,

Unfortunately one does not, in general, get a job simply by being "willing to put up with" a whiteboarding session or two.

It is a necessary but not sufficient criteria.

criterion

Whether they're necessary (or even useful) or not is one of those things you'll find a variety of viewpoints on, to say the least.

Leaving aside the whole issue of whether actually done properly (or even reasonably).

He didn't say those interviews are necessary. He said that being willing to put up with them is necessary to "play" (by definition, otherwise you won't do them), even if it's not sufficient to "win".

Again, presenting this neutrally: the quote about the only way to win being not to play is clearly false. If you choose to play (choose to go through the whiteboard circus), you might win (get paid a lot of money at a large and stable tech company). You also might not, but that possibility is there for any interview.

OK, thanks for clarifying. I read that line a bit too fast.

As to the core of what you're saying -- between the lines, the value proposition seems to come down to this: "Yeah, everyone knows by know those whiteboard sessions are mostly bullshit. But hey, if you're willing to swallow your pride and suck it up like everyone else, these companies might throw a little bit of money your way. Coz that's the name of the game, yo -- in case you haven't heard by now."

At some point one gets tired of basing one's life on considerations like that.

You do realize it works the same the other way around, right? If I'm forced to pair with an emacs user I will spend half the time flipper-handing the keys and figuring out what weird hotkey I'm supposed to use just to get into edit mode. ;)

It's not a modal editor.

cough C-x cough

But it can be!

Try being one of the few people who actually bothered to learn a keyboard layout other than qwerty.

To make matters worse, my layout isn't installed by default in any OS other than GNU/Linux/BSD (it does come with Xorg now).

Having a keyboard with open firmware so you can carry the layout with you could help with this.

That's a viable workaround most of the time.

Unfortunately, it causes another problem: You can't use a keycode-based (as opposed to keysym) configuration without switching your keyboard back to qwerty.

Reply on news.ycombinator.com