Ask HN: As a junior to mid level engineer what advice do you have for seniors?
What would you want to give as an advice to senior engineers / management?
Since I was in both positions my advice or request to seniors would be to try to take your time to explain things to your junior colleagues. From personal experience this pays off in the long run and reduces dumb questions you receive later on. Some seniors just respond with "rtfm" or "Yeah I got to figure that myself too, won't hurt if you try that too..." to every single question. The fact that someone is younger or less experienced in some area does not mean they have to be treated like piece a of s* *t.
You have to realize that new person is not asking only to get technical knowledge but to also crate connection and relationships. Sure, one can be busy not have time to babysit fresh members, but in that case you can just say it.
It's also very common that different companies use the same technologies very differently so explaining how you use it is of big help to newbies. I thought that after 4 years I will quite well versed in some technologies, only to learn that the way they were used in my old job was quite obscure. So sometimes senior needs to help new colleagues to re-learn things in the right way. That can also be difficult.
Extra tip for juniors: Some people are good in explaining things some are not. Some very sharp technical minds might not be very good in interpersonal areas. So don't feel bad if you look stupid or someone is a bit nasty. It does not have to be personal. And if you think it is, find someone else you trust you can talk to and ask for their opinion or help.
This is lousy behavior not only from a senior, but from anyone. If someone on the team spoke like that, I'd pull them aside. Granted, if the frustration had grounds because the other person wasn't pulling their weight, I'd pull that person aside, too.
One of the things I test for in interviews is behavior towards vulnerability. In the early days, I would meet the candidate not necessarily communicating on my role. I would then ask a silly question as if I did not know the answer and observe the reaction of the candidate. Some take the opportunity to explain to me how things work. Others bounce on that opportunity to do two things:
- Give me bullshit: they imagine I am not technical if I'm asking this question, so they think they can get away with it.
- Shift towards a condescending tone: it is amazing how you can see that shift as in "Oh... you don't know this". Some become discourteous: "Do I have to explain this to you?", roll their eyes.
Another test is, in a technical capacity, say something you know is wrong. How the person will handle this situation? How do they debate? Will they be insufferable when they think they're right? (you want to hire people who are right more often than they're wrong, but not necessarily be douchebags about it as the goal is to solve the problem, not to prove others wrong and do a victory lap on every small matter). Will they just agree with you? Do they aree with you because they didn't know you were wrong, or because they knew and preferred to let it go (which you can't afford because you want people to check your thinking and tell you when you're wrong)?
Another test is say something you know for a fact is right, but say it with a lot of self doubt. Do they make their decisions based on what they perceived your degree of confidence is, or based on facts? You don't want people to debate technical matters and "go for the kill" because you don't seem sure. You want people who'll take that pertinent remark said with doubt, and actually do some thinking about it. Those who don't tend to have a cargo cult mentality and arguments of authority work too well on them.
These behaviors disqualify candidates for several reasons:
- Unless you're doing something trivial, you're pushing your comfort zone and are in the "ignorance zone" while trying to figure out solutions to a problem. We spend a lot of time in this zone, which means we ask each other a lot of questions, sometimes basic questions to check we're going at it from the same hypotheses. A person like the above would become intolerable in this situation as it is clear they have this attitude mostly because they haven't worked on problems non-trivial enough to become humble, ask questions, and risk being silly systematically to get to the bottom of things.
- We must be able to explain things for people with different sets of skills. For example, when a team has several people with different skillsets, each one person should be able to safely ask questions to another person with skills they don't possess.
- That disdain for "non technical" people does no good. From what I have seen, it tends to be a sign of low general intelligence. Talking down to someone smart because they can't code is plain dumb.
>Some very sharp technical minds might not be very good in interpersonal areas. So don't feel bad if you look stupid or someone is a bit nasty.
In my experience, sharp minds tend to value effort and interest of the person they're explaining things to. It is an investment and they're more than willing to explain things to someone again when the person shows they took what was said last time, thought about it, researched things more, came back with more subtle questions that show a deeper understanding than they had before because they're struggling with more nuanced problems.
We often write emails to everyone on the team, going through the rationale of things, point by point. The expectation is to receive a "pull request on our thinking" to fix a bug or add a feature. These are extremely valuable because time and time again, one or more persons on the team would say: I thought we were doing X because of Y, but it appears it's because of Z.
Of course, this gets easier when you have a way of work with colleagues who, when you solve a problem, will stop you and say: "How did you go through it?", "How did you know you had to look at that process?", "How did you know it was time to make that decision?". We tend to talk about everything: product, business, marketing, ecosystem, the whys and hows, and "junior" people are there so they learn the process behind this. They learn what is a priority and what is not and why it is that way, so when something changes, they can update and make decisions on their own to optimize for what we're going for.
As you said, anyone ought to be adding leverage. People tend to think you can't do that in an individual contributor role, but you can. Drafting good issue templates to lower the barrier to writing good issues that are easily parsed adds leverage. Taking meeting notes and sending them to everyone so people can have a written record to track progress, or spot discrepancy between what was said and what was understood and correct it upstream before people work on the wrong thing adds leverage. Factoring out what is "taught" or "told" to newly hired people and putting it into an onboarding document that can be improved by everyone adds leverage. These are all things that can free up considerable time and reduce the frequency of "the senior having to do something".
If I were in an interview, presumably with my technical superior, I would not be as interested in the job. I want to work with knowledgeable people so that we can work together efficiently and teach each other stuff. If the person above me doesnt know the answer to simple things, then I might question the strength of the team. The interviewee typically doesn't have a lot of power, but they are evaluating you too.
I once had a tech lead who did not make good leadership decisions and lacked a broad technical knowledge. He did not like me (maybe he felt threatened). I did not like working for him. Part of that was because his decisions seemed like we were not taking the smart approach or factoring in longterm concerns. If I get this sort of vibe in an interview, then I'm probably not taking the job.
Something related happened in an interview once. The tech lead had her laptop with her and she was glued to it the whole time. It's understandable if there was a prod issue, but there wasn't. At one point the manager asked her if she had any questions for me, so she asked one. As soon as she asked it, she went back to her laptop. When I was finished giving my answer, she didn't even acknowledge it. There were a few awkward seconds of silence and the manager picked it back up. They offered me the job and I declined. The manager was dumbfounded and and made lots of excuses. Then he called my current manager (same company) trying to get him to grill me on why I turned down the job, even though I gave him my reasons already. I absolutely hated my current position at the time, yet I knew this one would have been worse based on that interview. If I couldn't get the tech lead's time in an interview, there's no way she would have the time to develop me as a resource.
>If I were in an interview, presumably with my technical superior, I would not be as interested in the job. I want to work with knowledgeable people so that we can work together efficiently and teach each other stuff. If the person above me doesnt know the answer to simple things, then I might question the strength of the team. The interviewee typically doesn't have a lot of power, but they are evaluating you too.
Yes, and I'm interested to see that evaluation and how they act on it. The whole thing is what you do with vulnerability: does the person correct me and consider it a problem to fix? How does the person do it? Does the person rejoyce that I got something wrong/don't know something? (which is the case of people who don't know much who do not believe when they "get to correct someone" and make it a big deal). Will the person let it slide and be secretly disappointed and talk about it (which is characteristic of bad, toxic, organizations)?
Delivery is key. This reveals a lot by incurring a small "reputation"/"perception" debt repaid quickly afterwards.
That and you other points are all valid concerns.
If you're telling them it was a test and providing feedback, then I could see that eliminating my concern. I think I wrongly assumed (based on my past experiences) that it was done in secrecy without telling them it was a test or how they did.
Even though my organization requires interview feedback for internal candidates, it's rarely helpful or insightful.
As a senior I often find myself needing to say this and I hate saying it. I’ll do my best to solve the problem and sit with them look through the code etc. first.
Sometimes code has been written by ex employees and it complex and not well documented. I don’t always have all the answers to hand.
I do my bet to set them up for a win and if I have time will try to solve the problem in parallel so next time they ask I might know more.
That said wading through undocumented spaghetti is a good skill to learn!
Often problems that less experienced devs have come to me with are gnarly and it's more of a consultation than me handing answers to them.