|
Just going by what I was told at the time. I can only assume those young men were experts on the topic.
|
#
?
Mar 16, 2016 15:47
|
|
|
|
| # ? Apr 26, 2024 15:22 |
|
|
What are hiring managers first reactions to the title "Build Engineer"? A company wants to hire me to help set up their build and deployment pipeline for a new project; sounds interesting to me but not so much that I want to be pigeonholed into this area for the rest of my career. I'm coming in with four years of experience at a huge software shop, where I was working on internal build, test, deploy tooling but my title was still Software Engineer. This new job probably would involve less traditional development since it'll be reusing existing tech like Jenkins, but will still involve some plugin writing. Anyways, just wondering if I did this for a few years, it is it likely to limit me when looking for traditional development roles down the line?
|
|
#
?
Apr 5, 2016 16:43
|
|
|
You could always ask for a different title.
|
|
#
?
Apr 5, 2016 16:53
|
|
|
Eggnogium posted:What are hiring managers first reactions to the title "Build Engineer"? A company wants to hire me to help set up their build and deployment pipeline for a new project; sounds interesting to me but not so much that I want to be pigeonholed into this area for the rest of my career. I'm coming in with four years of experience at a huge software shop, where I was working on internal build, test, deploy tooling but my title was still Software Engineer. This new job probably would involve less traditional development since it'll be reusing existing tech like Jenkins, but will still involve some plugin writing. Anyways, just wondering if I did this for a few years, it is it likely to limit me when looking for traditional development roles down the line?
|
|
#
?
Apr 5, 2016 16:59
|
|
|
Eggnogium posted:What are hiring managers first reactions to the title "Build Engineer"? A company wants to hire me to help set up their build and deployment pipeline for a new project; sounds interesting to me but not so much that I want to be pigeonholed into this area for the rest of my career. I'm coming in with four years of experience at a huge software shop, where I was working on internal build, test, deploy tooling but my title was still Software Engineer. This new job probably would involve less traditional development since it'll be reusing existing tech like Jenkins, but will still involve some plugin writing. Anyways, just wondering if I did this for a few years, it is it likely to limit me when looking for traditional development roles down the line? this title is career death unless you want to get pigeonholed as the guy who knows how jenkins works
|
|
#
?
Apr 5, 2016 17:01
|
|
|
the talent deficit posted:this title is career death unless you want to get pigeonholed as the guy who knows how jenkins works And then get a billion recruiters after you. I've had a spot open for 6 months for Build/Infrastructure Engineer. The quality of candidates suck and are highly sought.
|
|
#
?
Apr 5, 2016 20:23
|
|
|
Hughlander posted:And then get a billion recruiters after you. Probably because being 'the build guy' is super boring and unfun, in my experience...
|
|
#
?
Apr 5, 2016 21:01
|
|
|
At my last job I hired a guy that was the build engineer and molded him into my team's software engineer because I couldn't find anyone decent that could tolerate our low compensation, ultra-mega corporate bullshit, and allow himself to be stuck with a worse title than even build engineer - Support Engineer. One of my best hires because he was so desperate to get out of that rut and really work on serious software, and I think he's probably better off for a real software job than myself now because he's got more buzzwords on his resume than me with some actual production experience. Most decent companies / opportunities' hiring managers would probably pass on any title like that because they have dozens to hundreds of resumes available at a time from great looking candidates. Also, the issue is that a lot of people with "Build Engineer" or "Release Engineer" titles are basically the deadweights from software teams and have gotten a negative connotation. The other thing I've noticed is that a lot of "devops" engineers are basically these same people just shifting forms.
|
|
#
?
Apr 5, 2016 22:03
|
|
|
feedmegin posted:Probably because being 'the build guy' is super boring and unfun, in my experience... We have a dev ops crisis in the industry. Build/dev ops is super high in demand because it sucks. But, to do it really well, you need as much experience as any lead development engineer. But, salaries are as of yet lagging for the position, and the position is generally tightly coupled with knowledge of specific technologies as opposed to general practices, and most people who end up in the position are sub-par as developers and are taking it as a back-up position.
|
|
#
?
Apr 5, 2016 22:29
|
|
|
baquerd posted:We have a dev ops crisis in the industry. Build/dev ops is super high in demand because it sucks. But, to do it really well, you need as much experience as any lead development engineer. But, salaries are as of yet lagging for the position, and the position is generally tightly coupled with knowledge of specific technologies as opposed to general practices, and most people who end up in the position are sub-par as developers and are taking it as a back-up position. Not in Seattle. Dev ops are so highly paid because of that. Higher than most of the leads.
|
|
#
?
Apr 5, 2016 22:45
|
|
|
Good companies know devops engineers worth anything are basically lead-capable software engineers in many respects and compensate them somewhat similarly until lead engineers become political figureheads in their own right or are so essential to the company they'll pay easily 2x the rest of the engineering staff. It's the bad (typically non-software) companies that treat devops engineers like they're basically sysadmin++ with similar comp structures. Those places are so far behind the curve of decent places in ways beyond technology I'd say that they owe you more simply on the basis that you'll be damaged goods after that job. If you have a "devops" engineer as build bitch, you're probably doing it wrong and should go kill yourself.
|
|
#
?
Apr 6, 2016 00:19
|
|
|
Yeah I don't live in a fancy town with sky-high salaries but at every job I've been, the only programmers (we don't call them engineer here as it's a protected title) that could setup a decent build/deployment automation were the most qualified programmers. If a candidate has setup a build and deployment automation system in the past it's a big plus in my eyes. Why is there an obsession of sticking engineer to every role ? Build engineer / Sales Engineer / Support Engineer etc ? Is it simply a hierarchy thing (technician versus engineer) or is it the normal title ? Do you guys have programmers anymore or only software engineer ?
|
|
#
?
Apr 6, 2016 01:18
|
|
|
AskYourself posted:Why is there an obsession of sticking engineer to every role ? Build engineer / Sales Engineer / Support Engineer etc ? Is it simply a hierarchy thing (technician versus engineer) or is it the normal title ? Do you guys have programmers anymore or only software engineer ? "Software developer" or "developer" is typically used these days from what I'm seeing.
|
|
#
?
Apr 6, 2016 01:49
|
|
|
Thanks, some of you voiced exactly what I feared but it sounds like there is at least some respect for the position so that's good. I had an on-site at the company this afternoon including being interviewed by current build engineers and they seemed happy. They admitted that the most programming experience they get most days is writing Python scripts but it's enough to keep them on their toes, as well as there being some upcoming projects that will have to be developed in-house. At this point if an offer comes in and the salary is close to a "normal" Software Engineer's, I'll probably accept.
|
|
#
?
Apr 6, 2016 02:13
|
|
|
Engineer to me sounds more like solving problems and less like being a code janitor.
|
|
#
?
Apr 6, 2016 02:14
|
|
|
AskYourself posted:Yeah I don't live in a fancy town with sky-high salaries but at every job I've been, the only programmers (we don't call them engineer here as it's a protected title) that could setup a decent build/deployment automation were the most qualified programmers. If a candidate has setup a build and deployment automation system in the past it's a big plus in my eyes. The role I'm looking for is officially 'Software Engineer - Build & Test Infrastructure' and is about optimizing our CI/CD pipeline across 150 (Growing to 250 this year) developers working on 3 (5 soon) major products across 5 platforms. It's completely a senior role and not a 'build monkey' since it's about the interaction of a complex distributed system.
|
|
#
?
Apr 6, 2016 13:52
|
|
|
Hughlander posted:The role I'm looking for is officially 'Software Engineer - Build & Test Infrastructure' and is about optimizing our CI/CD pipeline across 150 (Growing to 250 this year) developers working on 3 (5 soon) major products across 5 platforms. It's completely a senior role and not a 'build monkey' since it's about the interaction of a complex distributed system. The misconception I spend a lot of time fighting is that "CI" == "builds". CI is so much more than that and it's actually very difficult to do well.
|
|
#
?
Apr 6, 2016 14:18
|
|
|
AskYourself posted:Why is there an obsession of sticking engineer to every role ? Build engineer / Sales Engineer / Support Engineer etc ? Is it simply a hierarchy thing (technician versus engineer) or is it the normal title ? Do you guys have programmers anymore or only software engineer ? If you have "Engineer" in your title you do tend to make more
|
|
#
?
Apr 6, 2016 15:45
|
|
|
As an outsider who works with programmers and have pretty close relationships with a decent number of engineers/managers, when I hear programmer I think, someone who just codes what I specify or tell them to do. When I hear software engineer, I see someone who has control over the design, direction, and development. They are given a lofty/general goal to achieve (build an IDE to support X language), but they figure out all the goals of what that means and they figure it out how they want to get there.
|
|
#
?
Apr 6, 2016 15:50
|
|
|
Ithaqua posted:The misconception I spend a lot of time fighting is that "CI" == "builds". CI is so much more than that and it's actually very difficult to do well.
|
|
#
?
Apr 6, 2016 15:53
|
|
|
Ithaqua posted:The misconception I spend a lot of time fighting is that "CI" == "builds". CI is so much more than that and it's actually very difficult to do well. I've got pre and post-submit bitch Single mainlining the code to scratch that itch Code review mandatory PAT and SAT telling the story Forking data flow and Chaos Monkey CD with versioned service discovery Check that poo poo in, it's going to PROD Don't look at me like that's loving odd
|
|
#
?
Apr 6, 2016 16:48
|
|
|
Computer Engineering, in both hardware and software/systems variants, is a legitimate engineering discipline. It shares a lot of fundamental skills (problem scoping, modeling, risk/defect analysis, etc.) with traditional disciplines (mechanical, electrical, etc.), but significant portions of the traditional curriculum (physics, mechanics) don't really apply. For example, I have a Computer Engineering degree from an engineering department of an accredited institution, but I haven't taken the PE exam and there's not really a point in doing so. Calling oneself an engineer gets muddied up if it's a protected title, since that focuses on the PE and traditional disciplines, but what we do is very much engineering. Programming is one task that a computer engineer does, but it's not the only task, and there's also people who program for a living, but don't have an Engineering degree. Whether those programmers consider themselves to be engineers is something of an identity thing (especially since computer systems is a field that's feasibly self taught, albeit rarely), but might also depend on exactly what they do when programming. If they're architecting or scoping a system they're probably engaged in engineering. If they're just taking already-scoped tasks to implement minor features, that might be "just programming". However, because there is not licensing or an exam for computer engineers I hesitate to make opinionated distinctions over whether an individual worker (aside from those I hire) should be title as "Computer Engineer" or just "Programmer". As for why there's so many "Engineer" titles, a simple reason is that those personnel may (legitimately) work within an engineering department, and so having an Engineer title is not unexpected even if their actual work is on the fringe of what we'd call "engineering".
|
|
#
?
Apr 6, 2016 18:14
|
|
|
Ithaqua posted:The misconception I spend a lot of time fighting is that "CI" == "builds". CI is so much more than that and it's actually very difficult to do well. Vulture Culture posted:A lot of people got into this whole thing having never done any QA work before everything was focused on automated tools and green check marks, and we're still feeling this across the whole industry. My company had a super painful manual build and deploy process. One of our guys created a very 1998-looking tool that automates a portion of that by letting us manually push a button and have it do some build, source control and bit-moving steps. Now my company has a slightly less super painful manual build and deploy process. Our manager (who, don't get me wrong, is a great guy whom I have very few complaints about) called this tool "an improvement to our continuous integration." No, it's not. We don't have continuous integration or continuous anything. We have scripts and batch files that are all triggered manually and all together do not even cover 100% of our build or deployment processes. The tool is great; it takes a lot of pain out of the deployment process, and everyone who's ever done a deploy appreciates the improvement, but every time bossman says "continuous integration" I want to snarkily send him 40 links to articles and blogs about CI to teach him what it really means. I'm not going to, as I said he's pretty cool and is open to improvement, there are just a lot of obstacles.
|
|
#
?
Apr 6, 2016 18:31
|
|
|
Che Delilas posted:My company had a super painful manual build and deploy process. One of our guys created a very 1998-looking tool that automates a portion of that by letting us manually push a button and have it do some build, source control and bit-moving steps. Now my company has a slightly less super painful manual build and deploy process. Our manager (who, don't get me wrong, is a great guy whom I have very few complaints about) called this tool "an improvement to our continuous integration."
|
|
#
?
Apr 6, 2016 18:33
|
|
|
The mere term engineer is one that riles people up since it can have legal ramifications if you're not accredited. I'm not one to care too much about ABET accreditation as a barometer of competency, but from a legal standpoint it does matter very much. It's what's kept me from hiring some folks I knew were probably better than kids from random state schools but their lack of degree kept me from moving forward. It's not like you need to understand the differences between an open and closed system to build an effective CI pipeline. Heck, in practice most engineers in other disciplines just wind up being paper pushers. The difference is that in tech we don't have a massive army of menial coder laborers that will write code near minimum wage to do the designs of the paper pusher bureaucracy. I'm fine with having a diverse industry but something's gotta give when someone's a great coder but terrible engineer or vice versa - most companies want the unicorns that are both when I've seen there's a far more abundant supply of people that fill one but not the other. Only thing that makes sense is that (good) tech is avoiding the incredibly high costs of hiring more and more bodies and avoid greater levels of division of labor. Organizations that struggle to keep costs under control seem to also demand more and more jobs for increasingly specialized (really, redundant if you have decent people) roles. Places that require degrees, as a result, are typically of the old hat business models that value external validation like degrees and certificates over demonstrable output by all employees. Aside from places that are already highly selective like much of Wall Street, they'll get what's coming to them eventually. It is in all of interests as technical people to not work for them. However, the number of people without degrees and certificates that are trying to swindle big companies in contracts for incredibly underqualified workers is a definite reality. However, tech companies seem to do just fine filtering out bad contractors while I really can't say the same for defense and government work where they've tried the hardest to keep out bad eggs but somehow manage to hire the worst technical people I can ever think of (alongside some of the best).
|
|
#
?
Apr 6, 2016 18:34
|
|
|
Che Delilas posted:No, it's not. We don't have continuous integration or continuous anything. We have scripts and batch files that are all triggered manually and all together do not even cover 100% of our build or deployment processes. The tool is great; it takes a lot of pain out of the deployment process, and everyone who's ever done a deploy appreciates the improvement, but every time bossman says "continuous integration" I want to snarkily send him 40 links to articles and blogs about CI to teach him what it really means. I'm not going to, as I said he's pretty cool and is open to improvement, there are just a lot of obstacles.
|
|
#
?
Apr 6, 2016 18:42
|
|
|
necrobobsledder posted:I'm not one to care too much about ABET accreditation as a barometer of competency, but from a legal standpoint it does matter very much. It's what's kept me from hiring some folks I knew were probably better than kids from random state schools but their lack of degree kept me from moving forward. For example, what matters in much of the US for traditional engineering is having a license, and even that's to sign off on engineeing work--junior engineers are often not-yet-licensed. And there, it's the responsibility of the licensing authority to ensure that the applicant is meets the required qualifications for a license, it's not something the employer has to independently vet. Then, in the software world, there is no license. Maybe a software firm could be found negligent if something happened in a safety critical system and it came out that the "engineers" of said system were woefully underqualified, but the majority of software isn't safety critical.
|
|
#
?
Apr 6, 2016 20:51
|
|
|
ExcessBLarg! posted:Where are you located such that there's legal ramifications? Also, ABET accreditation of programs is required for many scholarship programs sponsored by the federal government, I know that my particular program was required for computer engineering students but not computer science (never mind that MIT CSEE students all get ABET, the program didn't count CS students to be an engineering program and so I wound up getting more pay out of school than an MIT CSEE grad despite coming from a random state school). There's many other similar scholarship programs with similar guidelines for compensation / promotion that bleeds over into contracting. This was before the rise of for-profit schools being so popular so it wasn't a response to that kind of rubbish diploma mills but because classically in the US software engineers / developers in federal sector came from engineering disciplines including electrical, mechanical, materials, etc. I'm not sure how the hell it happened but ITT Tech managed to get an ABET accreditation years ago so I think it's complete bullshit, but my point is mostly that "engineering" is far from a meaningless designation when it comes to massive organizations that are stuck with labor division ideas from the 1940s. I think licenses can only help so much when much of the problems in software can probably be attributable to the same problems that we have in medicine and construction. Legal defense of the medical profession kinda sucks hard resulting in huge costs for independent practices (but really, the insurance companies are the assholes given their profits are at record highs) and we're all familiar with construction projects both public and private sector that are constantly going over-budget by orders of magnitude. But I suppose the difference is that that is normal in software while they're somewhat anomalies in construction at least.
|
|
#
?
Apr 6, 2016 21:09
|
|
|
necrobobsledder posted:I think licenses can only help so much when much of the problems in software can probably be attributable to the same problems that we have in medicine and construction. There's no way you could win over users making something like Snapchat or Android or whatever by making something with fewer features/less flexibility/worse performance but higher stability. That's the cause of software instability, not programmers being generally huge dolts (which is why you will usually have more stability in cases where it does count, like health care equipment, motor vehicle firmware, etc.).
|
|
#
?
Apr 6, 2016 23:36
|
|
|
Consumer = unstable and expensive business software = incentivized to be stable is a completely false dichotomy in my experience. Medical devices have incredibly terrible reliability and security despite so much emphasis upon stability, compliance, and stability. Meanwhile, WhatsApp has basically zero regulatory problems and has stupid high reliability typically. The general availability of consumer software is probably higher than most enterprise-grade systems that are routinely down for maintenance to the point they're hardly usable outside 9-to-5 office workers. People like to talk about military grade stuff... but I don't want military-grade software anywhere near my house or life. Even though Amazon doesn't emphasize availability of its site as a huge priority doesn't mean that it'll be down frequently. Meanwhile, every other place I've seen with SLAs in enterprise space has struggled to avoid downtime shorter than 10 days / year for various reasons - almost none of those reasons actually are related to technology or oftentimes even quality of engineers.
|
|
#
?
Apr 6, 2016 23:55
|
|
|
necrobobsledder posted:Consumer = unstable and expensive business software = incentivized to be stable is a completely false dichotomy in my experience. Medical devices have incredibly terrible reliability and security despite so much emphasis upon stability, compliance, and stability. Meanwhile, WhatsApp has basically zero regulatory problems and has stupid high reliability typically. The general availability of consumer software is probably higher than most enterprise-grade systems that are routinely down for maintenance to the point they're hardly usable outside 9-to-5 office workers. People like to talk about military grade stuff... but I don't want military-grade software anywhere near my house or life. Businesses are so lethargic, slow to switch products due to cost, and generally just  that business software can get away with all sorts of poo poo that would never fly in the consumer space.
|
|
#
?
Apr 7, 2016 00:14
|
|
|
apseudonym posted:Businesses are so lethargic, slow to switch products due to cost, and generally just It's not so much that as that for every minute Amazon is down, they lose millions of dollars in revenue. Similarly, WhatsApp has huge financial pressure to be available so that their users can use the system. Meanwhile, a lot of B2B/government/military software is written to spec with few incentives to ensure that the system works as a system instead of "working as designed". Once you get paid for your contract, you want to be done and dusted ASAP so you can move to the next contract.
|
|
#
?
Apr 7, 2016 00:33
|
|
|
I'm pretty much on board with the economists who think licensing is mostly useless. Or rather, not exactly useless to everyone, but certainly not generally beneficial to the public. The economist Tyler Cowen talks about the problems with licensing occasionally on his blog.
|
|
#
?
Apr 7, 2016 15:14
|
|
|
So I've been a C# app developer for about four years now. I've had four different positions at four companies during that time. Honestly I hated every single one of them by the time they ended. The reasons weren't always the same by after the first several months I grew to dread going to work each day. I enjoy solving problems with code and computers, but something about the enterprise-level software development process seems to make me miserable. It might be easier for me to just describe each one quickly: #1: I worked on a tiny internal team in a huge non-tech company. Looking back this one was probably the most enjoyable when it came to the actual work. We were a really small team and we got to design and build our apps from the ground up, from DB all the way to front end, and they were small, internal apps so they weren't all that complicated. However we also had to do our own testing since the QA person quit and the company never bothered getting a new one. The company also had a soul-crushing Dilbert-esque atmosphere that really drained me over time. #2: Medium sized non-tech company, great coworkers, but we actually technically worked for, and reported to, marketing. Need I say more? No real design or planning allowed, just slapping together whatever the crazy, floundering marketing head wanted that week. Did not take long for me to burn out on this one. #3: Medium sized tech-based non-profit. Good company with a good mission but the information domain of their product/field was very complex and the company as a whole couldn't agree on how to name/organize it so trying to develop software reflecting that domain was a drat nightmare. Also my team was too large and I was basically just handed tasks rather than getting to do any real design or planning. #4: Small recently purchased tech startup. I had some nice coworkers but the whole thing was a big mess. The CTO would basically do whatever each evangelical dev would want him to do so our tech stack was waaaaaaaaaay more complicated than it needed to be and was very fragile and frustrating to work with as a result. Project management was awful, they tried to make a group of 20+ devs work together as a single team across the entire app. Again I never got to do real design or planning, just code monkeying. High pressure, high speed, just augh. So like, have I just gotten really unlucky with jobs, or am I not cut out to be an app developer? I enjoy working with computers and solving problems with technology and code, designing systems, and I've been told by several bosses that I have a good mind for engineering in general, but I can't seem to find a developer job I like and that I'm good at. Should I try yet another dev job or should I move on? If I should go, what are some types of jobs I could use my coding experience to shift to? Has anyone else dealt with this kind of situation before? What worked for you?
|
|
#
?
Apr 8, 2016 10:20
|
|
|
To me it just sounds like a bad streak, it happens. Seems like you enjoy the actual development work though so I'd vote for trying to find another gig but maybe take more time to research the structure and management if you can of the places you're interviewing. Try to focus on companies that are tech companies first if you can, or at least companies where the technology department is not just viewed as a cost center. Where are you located by the way?
|
|
#
?
Apr 8, 2016 14:42
|
|
|
Every job has pros and cons. Bottom line is when you work for a company you are there to provide a return on investment somehow. There are various way to accomplish this across a huge range of sector of activity. The most important aspect for me personally is my direct co-workers and direct supervisor, if they are nice I generally have a good time even if the rest of the company are less than ideal. Great bosses are not necessarily great technically, however, they need to be good listener and people problem solvers. As for your colleague, ideally you want people than can teach you something and people to whom you can teach stuff. But yeah some of the worst work environment is place where there is no planning, no requirement gathering, design phase and where non-technical staff don't respect technical staff.
|
|
#
?
Apr 8, 2016 18:18
|
|
|
Less Fat Luke posted:To me it just sounds like a bad streak, it happens. Seems like you enjoy the actual development work though so I'd vote for trying to find another gig but maybe take more time to research the structure and management if you can of the places you're interviewing. Try to focus on companies that are tech companies first if you can, or at least companies where the technology department is not just viewed as a cost center. Where are you located by the way? I was in Portland, OR, now I'm in Seattle. Hopefully that'll make it easier to find something good? AskYourself posted:Every job has pros and cons. Bottom line is when you work for a company you are there to provide a return on investment somehow. There are various way to accomplish this across a huge range of sector of activity. Yeah totally. Having a good boss is vital. I won't say the team lead at my first job was a nice guy or anything but he did do a good job of shielding the rest of the team from management bullshit. He was the one that somehow convinced management to let us do agile development instead of waterfall, do TDD, etc. and kept management off our backs when timelines slipped. And he was a good teacher on top of that. Job #3 had a fairly good boss although he was stretched way too thin of course. Thanks, that helps a little. I just wanted to make sure I wasn't crazy, or that this kind of stuff wasn't part of every developer job. Hopefully being in a big tech-heavy city like Seattle now will help me find something that's actually a decent fit.
|
|
#
?
Apr 8, 2016 19:08
|
|
|
It's also a great market to change jobs right now, so that's going to help you. I was/felt stuck in a lovely job in a lovely company for years because of a combination of the 2007-8 meltdown and lack of experience.
|
|
#
?
Apr 8, 2016 19:57
|
|
|
I'd look for a more established software company. Look at the reviews on glassdoor too. I have found that they are pretty spot-on.
|
|
#
?
Apr 8, 2016 20:43
|
|
|
|
| # ? Apr 26, 2024 15:22 |
|
|
The recession really put a damper on a lot of people's careers, mine included definitely. Being nowhere near a major metro area while looking for a job during a recession didn't help either. My general advice is more of a "don't do" list than a "to-do" list. The truth of a lot of tech jobs, contrary to popular belief, is that most are actually pretty crappy that follow corporate tropes and make career advancement nearly impossible. 1. Avoid corporate IT jobs. They are cost centers and typically staffed with the least competent technical people in a company barring some rare exceptional companies. I'd rather work at a so-so software company than work in Google or Facebook IT. 2. Avoid non-software companies - no, most ISPs are not software companies. Maybe Linode and Digital Ocean are software companies though. It's not like janitors are paid well by tech companies, right? In most companies, tech is a means to an end that's auxiliary to the primary revenue model and will be funded / defunded accordingly. Tech is just expensive janitorial or facility services to them and you (or rather your managers) will be treated accordingly. 3. Avoid sales-driven culture companies. Sometimes this is disguised as a "customer-focused" company. Sales driven companies drive engineers nuts and tend to be really short-sighted without much technical vision and lack of attention to technical debt. 4. Avoid companies that do not give you an adequately difficult technical screen. It is usually a sign of desperation by a company, low skill bar (read: your coworkers just may not know wtf git, svn, or cvs is!), or a complete lack of ability to understand what they're looking for. Good companies usually have a number of candidates always interviewing there and tend to be very selective and want to actually test people instead of simply asking for a minimum qualification level. 5. Avoid places with lots of contractors. This is usually a sign of being unable to retain people sufficiently well on top of being very cost-conscious rather than outcome-oriented (that is, they'd rather get 20% worse quality for 15% cost savings or want to limit hiring of FTEs for many jobs in the first place because their employees are so expensive). One of my worst jobs I didn't realize that literally the entire QA team was all contractors as well as 75% of the software engineering team and 50% of the infrastructure engineers. It followed a labor model eerily close to how government tries to work now with core employees = all managers, do-ers / warm bodies = contractors. Last I remember, something like 60%+ of the engineers at the CIA were green badgers - I've never heard of a good experience from an engineer there. The good news is that Seattle has tons of great software companies, although I'm wondering if your language bias may be what's keeping you from some of the hotter companies with more compelling products. Off the top of my head, Portland has Puppetlabs and they're pretty alright. They're mostly a Ruby and Clojure shop last I saw when it comes to backend. Even Chef is Ruby and Erlang, but some C# may be viable given the relationship with Microsoft now. Heck, I'd give Microsoft these days a fair shake.
|
|
#
?
Apr 8, 2016 22:18
|
|