290 karma · joined March 26, 2022
Covering their ears helps block the low frequency sounds. Yeah, they're not describing tinnitus at all, just some ambient noise that annoys them at night.
Have you tried asking them? Just because you're supposed to have more experience than them, doesn't mean the flow of information should all be one way. Have regular chats with them about what they think their strengths and weaknesses are. Use these chats as a way to get feedback about your mentoring style, and make sure to take this feedback on board.
- distraction (I am excited to mentor, hence my brain keep coming back to that (providing resources, reviewing their work, etc.) while I am supposed to do my work)
This one's squarely on you and nothing to do with mentoring. Get better at setting the mentoring aside until it's time to do it. If an idea pops into your head while you're working on something else, note it down and go back to what you were doing. If there's prep work you need to do for a mentoring session, block out the time for it. You know, the things you'd do with any other aspect of your role.
- how detailed/nitpicking should I be in reviewing, how to explain the right concept at the right time
If you're talking about code reviews, you'll still be reviewing everything that you would for any other member of your team - you want to maintain the same code quality, after all. In terms of the concepts you spend time discussing in detail, probably just stick to one at a time - pick whichever seems most important for that review, have a short discussion about it, then decide whether it's something you need to revisit later or just watch out for in future reviews. If a short discussion isn't enough, book something more structured in and deliver more of a training session.
The important thing to remember is that everyone is different. We all have different experiences and learn at different rates. Be humble about mentoring. You'll find that when it comes to explaining what you think you know, you'll identify gaps in your own knowledge and probably learn as much as your mentee does. Use it as an opportunity for both of you to grow, and be receptive of feedback, even from a 'subordinate'.
> Also, the entry barrier is very low in tech. Anyone could learn any technology.
So that explains why there's an eternal shortage of software developers and why we're paid such high salaries to get us to stay.
The next best way is to reflect upon what you felt went well and what didn't. I usually have a good idea which questions I didn't give adequate answers to, and my instincts have usually lined up pretty well with the feedback that recruiters give.
Your reductio ad absurdum that follows doesn't do your argument any favours either.
As businesses get better at measuring the productivity of remote workers by means other than time spent visibly in their seats, these middle managers won't have a role anymore.
I'm not sure if the landscape is different in the US. Here in the UK, start-ups will snap your hand off to get you through the door. When I last went through a round of interviews, I was getting from my initial chat with a recruiter to the final interview in a matter of days, and most of the offers would have allowed an immediate start had I been available.
The corporation I work for is almost anal about locking down machines to the point where you can't even install a browser yourself. I had admin access on day one as a developer and have no idea how I'd work without it.
Their safety net is that they'll almost definitely have monitoring tools installed. If you install something that triggers an alarm or they detect suspicious usage patterns, they'll be in touch. Otherwise, you're good.
Perhaps companies should better look after their employees and give them a reason not to leave. Many of us are fed up of being underpaid and undervalued. Add to that the increasing demands to return to an office and it's not hard to see why we're jumping ship to work for businesses that pay better and offer remote working arrangements.
I changed jobs almost a year ago and have zero regrets. I had a long tenure too. What did it get me? Maybe a 2-4% raise a year if I was lucky (which we all know is a pay cut in disguise when you consider inflation). None of us should feel that we have to be loyal to a business. That same business would lay you off in a heartbeat if it would save them money.
100%. I changed roles recently. If a recruiter described such a lengthy process, I simply told them I neither had the time nor the desire to take part. The worst interview process I actually went through with was originally supposed to be 4 1-hour sessions across multiple days, which the recruiter arranged to have compressed to 4 30-minute sessions back to back. I agreed and ended up accepting an offer.
More of us need to push back on the inconsiderate demands on our time. There's a shortage of developers and we have plenty of other options if they want to make the hiring process so unpleasant.
We'd open the interview with the same kind of 'what have you been working on' ice breaker to get started and to give the candidate something to refer back to. Then we had a core set of thematic questions to talk around (topics like DB design, API design, OO programming). Nothing was designed to catch anyone out, but it was a great chance to see how much detail a candidate could go into and how comfortable they were in their knowledge.
Having sat on both sides of the process, there's nothing I hate more than trick questions and technical tests. It's not representative of how we work, so it shouldn't be how we decide who gets the job either.
If it's not showing up for you, you'd need to contact their support team to find out why.