|
Y'all wanna see some advice that how!! blithely ignored when it was served up on a silver platter 3 years ago?kitten smoothie posted:The upshot here, as I would also say to School of How, is that I didn't learn jack poo poo at that job, and every day I went in there was one more day when my skills were atrophying and I was ultimately screwing myself. Vulture Culture posted:Whether it's appropriate for your current environment or not, with your description of this development workflow I'd be more concerned about being able to land any dev job rather than one that fits the hours you want to work
|
#
?
Aug 8, 2019 01:12
|
|
|
|
| # ? May 18, 2024 11:01 |
|
|
quote:Why can't i just show up and get a job as a senior dev? That's what I did when i worked over the summer stocking shelves at a warehouse and that was cool. Whats the big hassle all about?
|
|
#
?
Aug 8, 2019 01:17
|
|
|
School of How posted:In non-oversaturated labor markets, there is very little competition. The interview is only to check that you have the basic qualifications. An example of this is a fulfillment center. I worked at one of those places as a summer job about 15 years ago. Pretty much everyone that applied was offered a job. The interview consisted of asking the candidate if they can speak and understand english and if they can lift 50 pounds. Anyone who answered "yes" to both questions was offered a job. There was no competition between candidates, because everyone that applied was given a job. There was enough jobs to go around for everyone.  That's nothing to do about saturation, that's called replaceable low-skill labor. You are not paid to think or be creative or be a collaborative colleague, you are paid to lift and move things because we haven't built advanced enough robots yet. How you can even possibly relate this to a high-skill, abstract, specialized field like a 10 year software veteran is boggling.
|
|
#
?
Aug 8, 2019 01:21
|
|
|
Guinness posted:How you can even possibly relate this to a high-skill, abstract, specialized field like a 10 year software veteran is boggling. The point I was trying to make was in regards to basic qualifications. If you can code, you can contribute to a software company. You act like there is some kind of magical rare ability that you must have beyond being able to code in order to hold a position of developer. You might find this hard to believe, but back in 2010, all it took to land a programming job was to demonstrate the ability to complete fizzbuzz.This was because back then the market was not oversaturated, and the only requirement to pass an interview was to demonstrate basic programming skills.
|
|
#
?
Aug 8, 2019 02:04
|
|
|
School of How posted:The point I was trying to make was in regards to basic qualifications. If you can code, you can contribute to a software company. You act like there is some kind of magical rare ability that you must have beyond being able to code in order to hold a position of developer. I'm not sure anyone in the industry is looking for "coders", I'll argue by itself that's not a valuable skill. They are looking for someone that can solve problems their org has. Whether this is "list our product on the interwebs" or "create a sentient AI to make humans redundant" will of course depend on the org. This will practically always involve interacting with other tehnical and non-technical people, understanding them and ultimately working and compromising with them to achieve the goal. School of How posted:You might find this hard to believe, but back in 2010, all it took to land a programming job was to demonstrate the ability to complete fizzbuzz.This was because back then the market was not oversaturated, and the only requirement to pass an interview was to demonstrate basic programming skills. Despite others in the thread dog pilling on you, I don't actually want to be an rear end in a top hat, but have you considered the possibility that when you previously landed a programming job it was actually a fluke and you might need to engage in some self-reflection in order to progress your career?
|
|
#
?
Aug 8, 2019 02:25
|
|
|
I'm not going to be condescending because he's actually responded back without ad hominems, but my point about not agreeing on terminology stands unequivocally now. Interesting enough, it turns out the academic body of economic work on market saturation didn't seem to show up until 2004 at least given the seconds I checked around https://en.m.wikipedia.org/wiki/Market_saturation
|
|
#
?
Aug 8, 2019 02:26
|
|
|
I changed my mind, How is right. How, please go share this revelation with hacker news and reddit. No need to report back, once your insight goes viral we'll hear about it. Good luck!
|
|
#
?
Aug 8, 2019 02:30
|
|
|
You might have gotten in when the market (or your employer specifically) was desperate and thought this was normal.
|
|
#
?
Aug 8, 2019 02:37
|
|
|
my dude has learned none of the right lessons from his ten years of fixing problems in 15 minutes
|
|
#
?
Aug 8, 2019 02:51
|
|
|
School of How posted:You might find this hard to believe, but back in 2010, all it took to land a programming job was to demonstrate the ability to complete fizzbuzz.This was because back then the market was not oversaturated, and the only requirement to pass an interview was to demonstrate basic programming skills. this may have been true for the junior dev role you walked into but I can assure you that it was not the case for senior dev roles in 2010.
|
|
#
?
Aug 8, 2019 02:58
|
|
|
School of How posted:I'm sure there's been some interviews that I've failed completely because I'm not an anime fanatic or something like that. When the market is oversaturated, companies get to choose whoever they want and they can be as picky as they like. If they want their idea candidate to be an asian female with blue hard that enjoys anime, they have the luxury of rejecting anyone that doesn't fit that exact mold until they find an exact match, while ignore everyone else. In an undersaturated market, that wouldn't be possible. what the gently caress are you even talking about cave emperor fucked around with this message at 10:21 on Aug 8, 2019 |
|
#
?
Aug 8, 2019 04:56
|
|
|
School of How posted:The point I was trying to make was in regards to basic qualifications. If you can code, you can contribute to a software company. This has been brought up a few times but I haven't seen you respond to it: what's your take on people who can code but are are either extremely socially abrasive, or write code that works but is unmaintainable? Surely you can see that people like this can easily make your productivity go down (hiring them would be a NET LOSS to your company), so even in an under-saturated market, you wouldn't want to hire them. How would you propose filtering out these people during the interview process? Edit: drat, my bad, you did address this already some posts back: School of How posted:I don't believe this. I think most candidates are perfectly capable of being a programmer at most jobs. Maybe 1% are incompetent. America is the largest economy in the world. It didn't get that way by 99% of it's workforce being completely incompetent. Disregard my question, I think this quote actually tells me everything I need to know about your perception of the dev job market sunaurus fucked around with this message at 11:31 on Aug 8, 2019 |
|
#
?
Aug 8, 2019 10:14
|
|
|
Oh, I get it now: this is an elaborate metaphor! How is so bad at programming that they're effectively unskilled labor and expect to be treated as such.
|
|
#
?
Aug 8, 2019 14:51
|
|
|
sunaurus posted:what's your take on people who can code but are are either extremely socially abrasive, or write code that works but is unmaintainable? Surely you can see that people like this can easily make your productivity go down (hiring them would be a NET LOSS to your company) There are two ways to manage a code repository. One way that can be called "community codebase" is one where everyone owns all the code equally. No one person "owns" any bit of code because everyone owns all the code equally. The other type of code management technique is called "code silos", where the person who wrote the code originally owns that code forever. I much much prefer code silos. I've worked with both types of management techniques. In the community codebase, often what happens is that lovely developers write lovely code that I end up having to fix all the time, and that sucks. There is no accountability to the lovely developers who wrote the broken code. On the other hand, if the codebase is a code silo, then there is accountability. If a coworker writes lovely code that is unmaintainable, that programmer is responsible for maintenance, and it has no effect on me. To answer your question, as long as the company has code silos, then a terrible programmer has no effect on me. Code silos are more common than community codebases, because management people naturally want accountability from the team. People in this thread seem to be under the impression that once a lovely developer gets hired that you are stuck with them for all of eternity. Companies are not going to continue to pay the salary of someone thats not pulling their own weight. If a certain member of the team is not productive, it's not hard for management to figure this out quickly and let that person go. It's not exactly rocket science to tell someone they're fired.
|
|
#
?
Aug 8, 2019 15:14
|
|
|
What is this and why do I see it a lot now?
|
|
#
?
Aug 8, 2019 15:55
|
|
|
Working as a team and sharing knowledge? No! Not for me! Leave me alone! Hey why is nobody willing to bring me on their team in a senior role?!
|
|
#
?
Aug 8, 2019 15:59
|
|
|
The reason you haven't convinced anyone that the market is oversaturated is because the "problems" you're having finding a senior role exist in every industry. Junior roles are one step above unskilled labor, and hiring is often just like you described: just show up and prove you're nice and basically competent. The higher up you go in *any* industry the more competitive the positions become.
|
|
#
?
Aug 8, 2019 16:00
|
|
|
Comradephate posted:I am late to the discussion about take homes, but I recently did one that was extremely reasonable. If I'd have to choose between a 5-8 hour take-home or a 5 hour interview on site I would always choose the take-home. 1-2 interviews 1 hour each on-site in different days would not require me to take a day or half a day PTO (of course, for local companies). When the lovely little company thinks it is Google (or at least on the route of becoming google) and crams 5 interviews that take the most of the day just because they can ... ughh. Just give me the assignment and I'll do it whenever I can. Thank you.
|
|
#
?
Aug 8, 2019 16:11
|
|
|
Pollyanna posted:What is this and why do I see it a lot now? It's an emoticon, if you angle your head to the left it looks like a face that's smiling.
|
|
#
?
Aug 8, 2019 16:13
|
|
|
School of How posted:There are two ways to manage a code repository. One way that can be called "community codebase" is one where everyone owns all the code equally. No one person "owns" any bit of code because everyone owns all the code equally. The other type of code management technique is called "code silos", where the person who wrote the code originally owns that code forever.
|
|
#
?
Aug 8, 2019 16:14
|
|
|
Like, 'breaking down the silos' is a known Thing You Should Do. Silos aren't supposed to be good, it's like saying 'I like the waterfall method of software development!' or 'I prefer unstructured programming!' or 'GOTO considered really nice, actually!'.
|
|
#
?
Aug 8, 2019 16:27
|
|
|
This thread is really amazing and I cannot wait for more wisdom from the school of how 
|
|
#
?
Aug 8, 2019 16:29
|
|
|
lifg posted:the "problems" you're having finding a senior role exist in every industry. Junior roles are one step above unskilled labor, and hiring is often just like you described: just show up and prove you're nice and basically competent. The higher up you go in *any* industry the more competitive the positions become. Not necessarily. In the aviation, for instance, you're pretty much promoted to "senior" by having the most seniority. The way airlines do it is they hire you as a first officer and are given a seniority number. When a captain retires, they find the first officer with the highest seniority number, and then offer them a chance to upgrade to captain. If they pass the training, they become a captain. It's very rare that someone can cut it as a first officer long enough to make it to the point where their seniority number comes up for upgrade, but isn't good enough to finish the training. It probably does happen, but it's very rare. It's only in the software world where this idea exists that only 1% of working programmers are competent enough to be a senior...
|
|
#
?
Aug 8, 2019 16:31
|
|
|
More like School of How To Become That One Person Everybody Complains About After You're Gone
|
|
#
?
Aug 8, 2019 16:31
|
|
|
We've found one of those 10x engineers twitter told us about
|
|
#
?
Aug 8, 2019 16:36
|
|
|
CPColin posted:More like School of How To Become That One Person Everybody Complains About After You're Gone "After" if you're lucky
|
|
#
?
Aug 8, 2019 16:36
|
|
|
TheCog posted:What happens when a developer who's been there 10 years and owns a major production critical silo leaves the company? Then someone else takes over the silo. quote:What happens when 'silos' need to talk to each other? quote:What about systems so large where a single developer can't own the whole system? You split the code into sections, and give each section to different programmers.
|
|
#
?
Aug 8, 2019 16:46
|
|
|
FYI, these are all recipes for disaster and if you're suggesting stuff like this to interviewers, that'll be another reason they've been passing on you.
|
|
#
?
Aug 8, 2019 17:32
|
|
|
I can't believe our professional experiences have been so vastly different that we both feel the exact opposite way about things that I would consider straight up facts at this pointSchool of How posted:I much much prefer code silos. I would never want single individuals to only be responsible of some specific parts of a codebase, this seems horrible to me for so many reasons, including things like: * not being able collectively iterate to reach better implementations * getting stuck in your own bubble and never learning from others * losing perspective on what even is readable code (if nobody else is constantly reading your code, how would you know for sure?) * "oh crap the maintainer is on vacation, guess we're blocked for 3 weeks" School of How posted:On the other hand, if the codebase is a code silo, then there is accountability. If a coworker writes lovely code that is unmaintainable, that programmer is responsible for maintenance, and it has no effect on me. Putting the blame ("accountability") on a single person in a team when something goes wrong seems absolutely awful, what even is the point of a team if it's "every man for himself" anyway? School of How posted:If a certain member of the team is not productive, it's not hard for management to figure this out quickly and let that person go. It's not exactly rocket science to tell someone they're fired. In my experience, gauging an individual's effect on team productivity can be extremely hard, ESPECIALLY for management types who aren't doing actual dev work with the team. There are so many factors at play here. For example, the ability to produce working code can be worthless if your team morale is poo poo (maybe because of an rear end in a top hat in the team? maybe because you're missing a key person who can lift everybody else up with their positivity? etc). Only relying on something like programming productivity (how do you even measure that? "speed of completing tickets"?) misses a lot of important things. My friend, I'm not convinced that you're not just trolling, but if you're really not, then it's pretty cool to hear about such an extremely different experience from my own. sunaurus fucked around with this message at 17:36 on Aug 8, 2019 |
|
#
?
Aug 8, 2019 17:33
|
|
|
I don't necessarily need to know the names of the places where these kinds of practices were Good Ideas but I'm definitely curious about when such scenarios make sense over the ones most of us in industry have developed as gospel. For example, I worked briefly on mainframes as a kid and I can totally understand programmers that demand massive code review and don't have test suites - their entire careers were based around computing infrastructure where you can't do that. But the thing is that modern COBOL isn't like that at all and you can totally run emulators and such locally to do some basic levels of tests. So far what I'm hearing is that How here has re-learned the exact same processes as what companies used to do routinely maybe 30 years ago.
|
|
#
?
Aug 8, 2019 17:42
|
|
|
its like the BeatmasterJ bathroom but for a dudes career
|
|
#
?
Aug 8, 2019 17:44
|
|
|
from his perspective, it's probably a good thing that how!! prefers silos and asks for guarantees of a job if he passes the take-home because the longer you talk with him the more awful his professional opinions seem to be to everyone else.
|
|
#
?
Aug 8, 2019 18:02
|
|
|
So you guys talking about companies falling all over themselves looking for people interested in becoming engineering managers... I seem to have found the 3 companies that don't fall into that category. I guess, that I need to downplay leadership aspirations when applying for IC roles.
|
|
#
?
Aug 8, 2019 18:07
|
|
|
kayakyakr posted:So you guys talking about companies falling all over themselves looking for people interested in becoming engineering managers... I seem to have found the 3 companies that don't fall into that category. I'd say it's situational on both sides? Some places have a full pipeline of eager folks ready to grow into management, some places have a lot of work and need bodies to do it. On the candidate side, I've had good luck saying "I need mgmt growth potential" and "I want technical work" at different points in my career and narrative. And it's not like companies talk. Apply to a startup that wants to "grow the pyramid" under the first few hires and say you really want to be a manager, apply to a FAANG that wants a skilled IC and rave about going back to heads-down IC work without interruption, they're never going to compare notes.
|
|
#
?
Aug 8, 2019 18:12
|
|
|
School of How posted:Not necessarily. In the aviation, for instance, you're pretty much promoted to "senior" by having the most seniority. The way airlines do it is they hire you as a first officer and are given a seniority number. When a captain retires, they find the first officer with the highest seniority number, and then offer them a chance to upgrade to captain. If they pass the training, they become a captain. It's very rare that someone can cut it as a first officer long enough to make it to the point where their seniority number comes up for upgrade, but isn't good enough to finish the training. It probably does happen, but it's very rare. It's only in the software world where this idea exists that only 1% of working programmers are competent enough to be a senior... This seniority system is very much a function of a union job. Most of America is not in union jobs, and have competitive interviews for higher level positions. If you like having a seniority system, I'd recommend looking for a job in government.
|
|
#
?
Aug 8, 2019 18:16
|
|
|
kayakyakr posted:So you guys talking about companies falling all over themselves looking for people interested in becoming engineering managers... I seem to have found the 3 companies that don't fall into that category. Some places are like that and without guidance from someone inside its hard to tell. I usually find it to be the case in places where you get in on the tail-end of a post-funding hiring spree. Basically they have a glut of management and have a "too many generals not enough soldiers" problem.
|
|
#
?
Aug 8, 2019 18:21
|
|
|
JawnV6 posted:I'd say it's situational on both sides? Some places have a full pipeline of eager folks ready to grow into management, some places have a lot of work and need bodies to do it. On the candidate side, I've had good luck saying "I need mgmt growth potential" and "I want technical work" at different points in my career and narrative. Oh, for sure. I just picked out the "provide mentorship" part of their listings and said that I'm looking for a company that's growing and will be willing to give me a shot at a leadership or manager role down the road. One was too flat (3ish managers, 200 senior developers), the other apparently has a bunch of folks already on the team waiting for the same position to open? Hurts that I'm dead-set on staying remote. At least I'm making it to the end of the interview chains pretty easily, even if I've not gotten an offer yet. Anyway... Any of y'all work for remote companies & want a team lead or engineering manager? 
|
|
#
?
Aug 8, 2019 18:27
|
|
|
kayakyakr posted:So you guys talking about companies falling all over themselves looking for people interested in becoming engineering managers... I seem to have found the 3 companies that don't fall into that category. I guess that depends how you perceive the IC role. The way I've grown to perceive it is that a leadership job as an IC still comes with mentorship, training, and soft skills. It's just that rather than defining the next gen architecture alone, you have to be able to do so while keeping lower-ranking individual contributors involved, and knowing how to communicate the questions you ask yourself and why the answers you give are useful. As you grow in seniority, there is less and less work you can do alone on your own in a vacuum that makes sense, and more and more work where your hard-gained experience can be useful to those who have less in ways that is a multiplicator; for most problems, you can do better preventing 5-6 developers who are less proficient or knowledgeable from making mistakes than you would ever accomplish on your own. The same is true of seniority when it comes to domain knowledge rather than just tech stuff; there are few replacements for "knowing the business" and you'll save a lot more time for everyone by communicating that expertise to others so they don't rediscover it through bug reports and hamfisted TDD. You'll still have plenty of opportunities to work on hard interesting problems in many places, but you should expect to make room for more and more time spent complementing and growing the technical strenghts of those around you on top of just honing your own skills. There are better ways to bring people up than "have them suffer through the same yak shaving I've had to go through" as far as systems go, but a lot of tech folks focus on just suffering through poo poo as a rite of passage. Aside from mentorship and experience sharing, more senior ICs are often just expected to take on larger projects with larger scopes; impact is department or company-wide rather than team-wide (often at a senior or tech lead level) or feature-wide, and those larger impacts tend to require better communication and negotiation skills anyway; you'll have to be able to herd cats across the various silos How!! is actively creating, make your points to folks working on product or marketing concerns, and so on, just to get the technical ball rolling the way you want. Eventually CTOs at big orgs do that nearly full time, negotiating budgets and priorities with other departments as a nearly full-time job. This is entirely distinct as a concern from what you'd get through a management track. I wouldn't expect a people manager to be doing technical training for engineers on their own, even though part of their work is likely to focus on career growth. It's just that your more senior technical contributors become a very good way to help that career growth if they are able to.
|
|
#
?
Aug 8, 2019 18:30
|
|
|
MononcQc posted:I guess that depends how you perceive the IC role. The way I've grown to perceive it is that a leadership job as an IC still comes with mentorship, training, and soft skills. It's just that rather than defining the next gen architecture alone, you have to be able to do so while keeping lower-ranking individual contributors involved, and knowing how to communicate the questions you ask yourself and why the answers you give are useful. Well said. I'm already doing that at my current job, but it's well phrased here and I'm going to shamelessly steal some of this when interviewing the next time I'm going for a senior IC role. Most of the EM roles I've been applying to have been 60/40 management/tech type roles, which suits me fine.
|
|
#
?
Aug 8, 2019 18:41
|
|
|
|
| # ? May 18, 2024 11:01 |
|
|
sunaurus posted:* not being able collectively iterate to reach better implementations Silos don't have to be non-collaborative. If I trust one of my co-workers to make sane changes, I can give that coworker commit access to my silo. If that coworker fucks something up, I'm ultimately on the hook to fix it because it's my silo. quote:* getting stuck in your own bubble and never learning from others This doesn't have to happen. By the way, building software is not an infinite process. Construction workers don't spend their entire career on a single construction site. You start building, finish it, then move on to the next site. As a developer, you get assigned a silo, you build the silo, you finish, and then move on to the next silo. You don't have to spend your entire career in a single silo. quote:* losing perspective on what even is readable code (if nobody else is constantly reading your code, how would you know for sure?) It's not like code in your silo has to be closed source. The code can be open for others to read through if they want. quote:Putting the blame ("accountability") on a single person in a team when something goes wrong seems absolutely awful, what even is the point of a team if it's "every man for himself" anyway? Accountability doesn't automatically mean "every man for himself". It just means incompetent people can't hide behind those who carry their own weight. quote:In my experience, gauging an individual's effect on team productivity can be extremely hard, ESPECIALLY for management types who aren't doing actual dev work with the team. quote:There are so many factors at play here. For example, the ability to produce working code can be worthless if your team morale is poo poo (maybe because of an rear end in a top hat in the team? maybe because you're missing a key person who can lift everybody else up with their positivity? etc). Only relying on something like programming productivity (how do you even measure that? "speed of completing tickets"?) misses a lot of important things. I would argue that a programmer's job is not to improve morale. My job as a programmer is to be productive at programming. If morale is low, that's someone else's problem. It's actually HR's problem. If HR had done their job correctly, morale wouldn't be so low. In my opinion, HR people are always the most worthless people within an organization. gently caress HR.
|
|
#
?
Aug 8, 2019 19:32
|
|