Hacker News Reader

Comment by JustSomeNobody | Hacker News Reader

The other problem with being senior seems to be that most companies interview the same as if you're junior: you have to study for the interview by doing all the leet code problems you can because that's what they ask.

View on HN

I can usually recognize when that is happening and I turn it around with something like: "Here is how I would do that...". If its critical to code like a junior then I probably won't be a good fit there.

Bottom line up front here is the difference between seniors and juniors:

Seniors want to accomplish the work so they can either move onto the next task or simply zone off into space. The goal is to accomplish all requirements as aggressively as possible with the smallest result possible. Less is more, but more time is less.

Juniors want to play with tools and code style. Frameworks are a huge deal. Seniors don't want to dick with any of this unless it is in place to intentionally police the juniors. Yes, I understand that juniors can be policed by simply having the proper automation in place, but that doesn't make the juniors feel like they are contributing to a cure for cancer.

If you call yourself a senior, you should be able to pass a test designed for a junior.

The idea that the average software engineer job interview is "designed" for anything at all is laughable.

In that case it's not really particularly a problem of senior vs. junior, but one of software jobs in general. My beef is more with the idea that we shouldn't verify whether people that call themselves senior can actually write any code. I've seen candidates with "senior" on their resume who can't even write code at an intern-level proficiency.

When I'm interviewing, I don't mind reversing a linked list doing a binary search. It gives me an indication that the company is actually concerned with whether its employees have some baseline competency. I regard it as a positive signal.

Writing down binary searches and reversing linked lists is one thing, but what people are talking about here are questions of the nature "write down this algorithm that was publication-worthy 30 years ago," or, what I like to call "stupid programmer tricks." Those would include "implement rand10() using rand7()," or "find the closest palindrome to a given integer n."

I absolutely should be tested on when to use a dictionary vs an array vs a tree. But if finding the "acceptable" solution to a problem relies on remembering one particular algorithm from college that I've not had to use in a dozen years, as some LC problems do, then that's reducing a senior level dev interview down to a junior level dev interview. As it stands, all senior level devs have to do a month of Leet Code just to be competitive. The people down voting me can't honestly say they remember every single one of the algorithms that are popular on LC without studying. That's just not being honest.

Generally speaking, yes. But Leet code style problems touch on aspects of CS that a senior doesn't practice day to day as a senior's responsibilities are more system holistic.

Duke Mu of Ch'in said to Po Lo: 'You are now advanced in years. Is there any member of your family whom I could employ to look for horses in your stead?' Po Lo replied: 'A good horse can be picked out by its general build and appearance. But the superlative horse — one that raises no dust and leaves no tracks — is something evanescent and fleeting, elusive as thin air. The talent of my sons lies on a lower plane altogether: they can tell a good horse when they see one, but they cannot tell a superlative horse. I have a friend, however, one Chiu-fang Kao, a hawker of fuel and vegetables, who in things appertaining to horses is nowise my inferior. Pray see him.'

Duke Mu did so, and subsequently despatched him on the quest for a steed. Three months later, he returned with the news that he had found one. 'It is now in Sha-ch'iu,' he added. 'What kind of a horse is it?' asked the Duke. 'Oh, it is a dun-coloured mare,' was the reply. However, on some one being sent to fetch it, the animal turned out to be a coal-black stallion! Much displeased, the Duke sent for Po Lo. 'That friend of yours,' he said, 'whom I commissioned to look for a horse, has made a nice mess of it. Why, he cannot even distinguish a beast's colour or sex! What on earth can he know about horses?'

Po Lo heaved a sigh of satisfaction. 'Has he really got as far as that?' he cried. 'Ah, then he is worth a thousand of me put together. There is no comparison between us. What Kao keeps in view is the spiritual mechanism. In making sure of the essential, he forgets the homely details; intent on the inward qualities, he loses sight of the external. He sees what he wants to see, and not what he does not want to see. He looks at the things he ought to look at, and neglects those that need not be looked at. So clever a judge of horses is Kao, that he has it in him to judge something better than horses.'

When the horse arrived, it turned out indeed to be a superlative horse.

- Liezi

And this is why having code reviews devolve into stylistic nit-picking by supposed "seniors" while structure and glaring bugs go unmentioned is one of the must infuriating things in the world. The color of the horse is all they see.

The kind of "tests" that most interviews use (and leetcode etc) are more riddles than anything else. Either you know the answer already and are able to recall it and pass the interview, or you don't know the answer and you'll fall flat on your face.

Hopefully, the job they are hiring for isn't "master code riddle solver", making the whole process irrelevant whether you're junior or senior. In any case, the interview checks whether you know this problem and its solution or not. That's not a junior/senior distinction.

Reply on news.ycombinator.com