141–150 of 371 posts
Earlier quoted context omitted.
That guy could perfectly be some tech lead, establishing his rock solid approaches on team of junior 4-10 engineers and delivering rock solid new products.
Not everyone has the disposition to teach and lead.
Earlier quoted context omitted.
My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality. Maybe it's different when you interview at a FAANG company though? I imagine FAANG recruitment is a merciless sausage machine.
> My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality. I'm growing further and further away from this mentality in hiring because the sad truth is most of those folks who come in with "quirks" lack maturity. To me, quirks…
> interrupting me/talking over me, talking down to me, comparing their last junior position to being Steve Jobs, being sing-songy, inappropriate jokes in any way/shape/form, getting in arguments with themselves... etc etc.
Besides being "sing-songy", none of these things are quirks, they're ineffective communication or untruthfulness of their past positions.
As far as dress and "sing-songy" go, I would agree with the above poster: software development tends to be much more inclusive of these sorts of characteristics. Jeans and a T-shirt is perfectly acceptable attire for an interview. Do your software devs wear suits 5 days a week? Why expect a candidate to do so, either? A candidate I interviewed going, "uh-oh sphaghetti-oh!" when they hit a segfault when running their interviewing solution was kind of ridiculous, but ultimately has no impact on their contributions as a developer. Factoring in these kinds of thins into the hiring decisions is ultimately about including people from a culture similar to your own. Different cultures have different definitions of "weirdness" so selecting based on the ability of the candidate to identify what is "weirdness" is ultimately a cultural litmus test. And expecting male candidates to be shaved, as per your other comment, is just blatant cultural discrimination - some demographics like Sikhs could even sue you for illegal discrimination over this. This cuts both ways, both the case where a candidate in a T-shirt and jeans gets rejected for not wearing a suit and when a suited up candidate gets rejected for being too formal. Both ultimately hurt the company by excluding effective workers.
Earlier quoted context omitted.
Over the course of a number of years and a few jobs at IBM starting in the early 90s, I knew 2 people on their "technical track". Their jobs involved huge numbers of airline miles, continual meetings, and essentially no technical work. That was one of the primary reasons I stayed a contractor most of my career.
Interesting that your contractor jobs haven't also filled with non-technical, biz type work? Lack of desire to deal with accounting, client meetings, all the organizational aspects of running a business have kept me away from contracting or consulting. Might be time for me to revisit that, this being the year when I really think I need to start something new. I have no idea how to make that switch though. Are you con…
If you are thinking of contracting/consulting, I'd highly recommend joining a diversified team in the 10-100 range so you can do the parts of the work you love and rely on your team for the rest.
Something that I find interesting is that career advice coming from professionals having many years of experience focuses almost exclusively on the people aspects and not the technology: communication, trust, teamwork, documentation, clarity. The advice is clear, precise and honest. This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, d…
Earlier quoted context omitted.
First real job I had there was this guy who had one specialization. He was in charge of some software that drove tape drives. Every outside new manager would come in and in some form or another look down on this guy in some form due to his age and generally not doing "a lot" of tasks and new products. It took the local VP to come down and regularly high five him after his product git rave reviews from customers (regu…
That guy could perfectly be some tech lead, establishing his rock solid approaches on team of junior 4-10 engineers and delivering rock solid new products.
Very much the high performer type who SHOULD NOT 'progress' to management or supervisor or ... reviewer of any sort.
He was professional, but "prickly". I found the keys to get along with him but a lot of folks didn't have the patience.
Earlier quoted context omitted.
What you're saying is important for everyone to internalize. I'll spin it like this: Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage. If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure y…
Found the manager. This is just more developer hate drivel. Yes, if you think managers are more valuable, then obviously you are going to say engineering work is "incredibly limited" and manager activities are "orders of magnitude more impactful" Listen, no amount of ass kissing and brown nosing is going to solve actual tech problems.
Earlier quoted context omitted.
> As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. So I have to ask: do you or have you worked at a FAANG with these systems? I may be wrong but I suspect you haven't, particularly if you're equating them with more traditional hierarchies. The whole point of a system like this (and I have direct experience at Google and Facebook) is so you can go pretty far as purely a…
> new hires start as a T3 This makes me curious about what T1 and T2 would mean.
What I'd be really interested in is how tech churn is perceived by people older than me. I'm only 30 years in, so I tend to defend my generation's choices such as POSIX, SQL, XML, SOA, Java, and C/C++ before that (plus special-purpose pet peeves of mine such as markup/SGML and logic programming which came before) though I'm also claiming to be proficient in and generally open towards new tech. I consider most of supp…
Maybe I have a older mindset aswell. My training in in Civil Engineering and I have my expectations for standards bodies set pretty high because of it.
The code is so high level now, going through algo and data structures I see the benefit of that fundamental knowledge, but also see that you can be a very valuable engineer to a company without it(thanks to the rich developer ecosystem for that)
If we think about the maturity of software like a biological ecosystem, maybe the zen garden built by past engineers has overgrown into a dense and varietal forrest. Im not sure if its bad or good, maybe there are more niches to move into.
3. Simplicity Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. When you can use fewer technologies, do so. This is the one I appreciate more and more as I age. Because frequently, I'm the next person looking at my own code. And there's no better gift to your future self than well-written, easy-to-understand c…