|
I'll add that if you have the capacity / ability to get a job with one of the major software companies (MS, Google, Amazon, etc.) you shouldn't even consider government if pay is a primary consideration. If you've got a bunch of degrees under your belt and have been turned down by a bunch of these companies, then you probably have a good shot there. Also, most actual coding work (in defense) is done through contractors really, and the pay (and oftentimes benefits) are better as contractors than as a government employee. Contrary to popular belief, government is not quite the holy grail of benefits it used to be anymore. Compared to general private sector, it's surely better, but for most highly skilled technical workers (aside from academicians actually - academia is loving hard, period) you're better off going to a contractor rather than full-on government. Almost every talented technical person I know that was in government is now a contractor. Also, the recent federal salary freeze that went into effect is probably a grim thing to hear.
|
#
¿
Dec 29, 2010 22:06
|
|
|
|
| # ¿ May 2, 2024 03:28 |
|
|
There's a large managed services provider in St. Louis (or nearby, rather) that I know is hiring plenty for IT folks.
|
|
#
¿
Jan 7, 2011 02:13
|
|
|
The enjoyability of the finance sector varies considerably though. Let's not forget that investment bankers, after all, continuously report among the lowest rate of job satisfaction. Most software engineers aren't as concerned about their salary as their general job satisfaction, which is mostly achieved by writing decent software that makes a meaningful impact to folks. I don't do software engineering anymore exactly (I do a mix of writing software and IT admin and architecture), but given what I've heard from my peers I should be able to top out at $200k without having to be stuck at one company forever nor hopping jobs every other year like I have been forced to due to many large companies treating even top-performing employees like utter crap. I'm pretty happy with the flexibility I get with my job now and the opportunities it gives me both personally and professionally, so I'm fine with sticking this out for once. Also, being in finance (especially on the trading side) almost guarantees you'll be in NYC (or another metropolitan area with  costs of living like say London, Luxembourg, Tokyo), and $200k in NYC isn't quite the same as NYC in, say, Silicon Valley. On second thought, I'm here in the Valley and I think NYC is arguably cheaper to live in than here.FinkieMcGee posted:And yeah, if they use the term "Rockstar" developer, run. Things are probably terrible there and they need a messiah to pull their poo poo together. You probably don't want to be the underpaid bastard that has to do that. The right spot I feel anyone should be on a team is to be somewhere near the middle in terms of an aggregate combo of skill / talent and experience along with similar work ethic and general attitude. This doesn't mean that you should just try to blend in (far from it) but that you should be able to both mentor someone and learn something from someone else. I've found my job most enjoyable in this sort of general cycle (ok, and with a product I think is kind of neat and meaningful somehow). I've learned to separate the parts of software engineering I really enjoy from the parts I do and made it so I have the freedom to do heads down development while at the least having the satisfaction of billing people extra for wasting your time or forcing you to do stupid crap you disagree with.
|
|
#
¿
Jan 9, 2011 08:34
|
|
|
Plorkyeran posted:having certs means that you're a bad developer because a good developer wouldn't need to get them
|
|
#
¿
Jul 30, 2011 02:46
|
|
|
I have a suspicion that's the guy that gave me my interview with Amazon so long ago. They have a weird hiring process I've heard though, so whatever.tef posted:business logic is not really amenable to algorithmic analysis, it shouldn't be that surprising This is all part of why I had to laugh at Y Combinator's Big Ideas suggestion on improving enterprise software - the solution to improving the technical quality of enterprise software is no more of a technical issue than world hunger is about producing enough food for the planet. We should remember, after all, that most software did come from the enterprise so long ago. On the other hand, I've certainly met some drat smart guys still in enterprise software. The other hypothesis I have is that the resulting software from these cultures is due to the chilling implications of the Milgram experiment. tef posted:We focus on writing and constructing new code over learning how to maintain and make code more maintainable. dazjw posted:Interviewing for programmers, not CJs.
|
|
#
¿
Sep 12, 2011 00:56
|
|
|
I think repeating the experiences of your forefathers in the form of programmer is a form of hazing and even as great of a problem as reinventing the wheel, but I think there's many reasons why new programmers continue to repeat a lot of fundamental mistakes regardless of platform and we should try to separate what should be learned through trial by fire because there's just no better way to learn it and what should be imparted through indirect knowledge. I'm not about to expect today's software geniuses to be like Mel but I'd hope they understand the spirit of what being good in this field means... and also how Mel is probably not the right guy to hire in most of today's software projects.tef posted:When you build a project towards sales criteria instead of designing it, it is easier to sell. Once software had been adopted by the enterprise it is almost a guarantee that it will stagnate. People would rather use broken software they've learned how to use over trying software that works The consistent process in the past 15 years or so of enterprise software is this: 1. Start-up hires a bunch of smart people to address a business problem 2. Start-up gets 3/4 of the way there 3. Big company notices start-up and buys them out 4. Big company's policies suck and a mass exodus occurs 5. New developers hired to maintain the code I've seen this happen with almost every acquisition done by a Fortune 500 company that's not a software-oriented company (there's maybe a handful that are). kitten smoothie posted:Then the client buys a license to a product that does none of that stuff out of the box, and signs off on a contract to have the vendor's consultants develop some custom bolt-on to address all the stuff the salesman promised. That consultant does not want to have to maintain that code he had little wiggle room for design, he wants it to work well enough, document it, and make sure it becomes someone else's problem. I'll just summarize the state of enterprise software with a single image. If you think there's a technical means to change this state of idiocy, you're loving delusional.
|
|
#
¿
Sep 12, 2011 16:20
|
|
|
shrike82 posted:Seriously, I'm just having a hard time even imagining a coding job which doesn't require some level of knowledge of algorithms or data structures. What would software they write even look like?
|
|
#
¿
Mar 20, 2012 03:13
|
|
|
I think a lot of the reason people ask for whiteboarding problems when they know of the downsides is that they'd rather have candidates that are so good even when handicapped and under pressure and all that they can still come up with working code and decent designs for problems. This unfortunately gets into the adverse selection problem we tend to have in hiring and well... if not all of us can make $370k+ / yr, not all of us can randomly recall different ways to do variations of the knapsack problem off the cuff, but we should be able to frame it properly and give some basic analysis that you'd expect someone to figure out in the time of the interview. Side projects indicate a level of passion that goes beyond your day to day job oftentimes. Writing projects is one thing (some great guys I know went home and took care of a stressful family situation and did just as well as those that spent all day and night in front of a computer), but I think it's totally fair to ask what they read about. I'm a bit slightly wary of anyone that doesn't at least browse for new stuff outside their job and can tell me about what "those cool people" are doing. This is a bit more relevant for folks in the DC area where most coders are employed in defense and their skills & experience are oftentimes irrelevant or incommunicable to industry (say, you worked on Stuxnet doing the PLA exploit - who the heck in industry would care about that work?). Ithaqua posted:That means "someone else accepted, you didn't get the job". If a company wants you, they'll let you know.
|
|
#
¿
Apr 1, 2012 16:17
|
|
|
I need to make it very clear that development is literally pumping out (reliable, stable, "good") code - you build poo poo, plain and simple. Systems integration on the surface seems to have a lot to do with development, but they share maybe 20% of everyday tasks. Integration is oriented around gluing stuff together. The closest experience most developers get into the everyday mundane crap of systems integration is sitting in meetings with 3+ other teams talking about how to pass variables between services and what sort of common APIs and services to use. For system integrators... well that's 50%+ of your job. Horrifying, isn't it? Welcome to my life for the past 3 years. As for "integration" there's bazillions of definitions of how that works so it's helpful to know what the actual tasks and additional functionality is. It can be anything from making some REST calls and feeding that back into a text output file (I poo poo you not, there's guys I know that do this at $200+ / hr - welcome to enterprise!) all the way to ripping apart existing code and building new app modules / plugins consisting of new code entirely. Most "integrations" tend to be on the former side of difficulty in technicals and almost everything that's difficult is the politics or dealing with broken software built by sub-par developers that exist in large companies. I've found out the long and painful way that it's really.... not development and that it can make you pretty dumb at actual development. For a construction analogy, developers are the ones doing the hard, necessary work of actually building software, and system integrators are responsible for getting multiple sets of teams to agree on building plans and to iron out differences whether they're political or technical in nature. This tends to almost only matter in huge gently caress-off companies because they're the only ones that acquire companies often enough that it's a big concern. Otherwise, most developers do stuff like supporting some vendor's OAuth service, 2-factor authentication, or merely accessing some API as everyday stuff that's somewhat tangential to their primary task of building a product or service. With that said, if you're doing HCI and IS sort of stuff, you're going to be headed closer to what they want for MLIS degrees (more about information architecture)... what they want librarians to have today. Otherwise, you may be able to wing it in UX / UI design but because almost everyone will want you to be a good prototyper, you'll be typically tasked with development as a primary duty rather than writing about what makes one kind of color better than the other for some text output. You will not be staring at a text editor for more than half a day with the former track - you'll be in meetings more, trust me. I say all this as a recovering systems integration "developer." It really isn't about writing software and I had the distinct impression for the longest time that I'd be led to opportunities to do it because software systems and IT systems from a general systems perspective are hardly different, but the reality is that development actually mandates knowledge of data structures and algorithms to do anything more than trivial stuff while you can go very, very far doing integrations without having the faintest clue why quicksort could ever be faster than an insertion / selection sort. The actually somewhat interesting integration gigs I've done were always when I was a pure developer, absolutely never when I was a consultant. In that road it's always been about "we bought software x, y, z... they don't do what the sales guys told us they'd do together... fix it." Do you know what I'm doing to go back to being a developer? Writing crap I'm going to put on github or online, that's what. Old sites I wrote 7+ year ago that never really took off might be back on the table for me, hell. I suggest anyone else trying to get anywhere close to development to do the same. Just loving code, it's the only way to prove you can do anything in the end and it'll go further along in terms of networking opportunities and interviews than a degree would. Even for large companies degrees are just a form of barebones gating in hiring to avoid systematically hiring that really awful neckbearded guy that really doesn't do anything which is fairly common among smaller companies.
|
|
#
¿
Apr 11, 2012 05:11
|
|
|
pigdog posted:That's why I got interested in that field, because as a dev I got so sick of wasting time doing rework, guesswork and debugging of systems that aren't even under my control, or finding out that the customer wanted something different entirely. psydude posted:Believe it or not, I actually wouldn't mind all of that (it's one of the reasons why I was looking into integration type stuff in the first place). My second job involves a lot of coordination of teams and resources from different backgrounds, so I'm used to playing the politics game and actually kind of enjoy the dynamic workload that it provides.
|
|
#
¿
Apr 11, 2012 15:28
|
|
|
The funny thing is that there's a crapload of horrible lol enterprise and defense work to be had in Silicon Valley as well (Lockheed, Northrop, etc. all have a sizable presence in south bay). I was slinging lol enterprise code when I was there (but it was way easier for me to find a gig doing something actually interesting with offers flying at me all the time). I had the damnedest time looking for a commercial software company in the DC area that wasn't something started by an MBA-toting sales exec that wanted to dip into tech and all marketing and advertising centric. The pay winds up being pretty freakin' mediocre too (mid-level dev for most commercial places here is maybe $5k / yr higher than what an entry level grad would get at a defense contractor). Most of the stuff here from the traditionally-acceptable companies like Amazon or even Google are in IT operations essentially because of the Ashburn datacenter, which is mostly about hitting up the government dollars crackpipe as far as I'm concerned. Even for the IT guys if you're not minding doing just EMC SANs, have done it for maybe 5 years, and you have a TS clearance, you'll get $160k+ / yr no sweat. The area had a bit of a fall-out with AOL / Time Warner having lay-offs recently and the last mega-huge private sector company here being Enron... well I kinda don't blame people for hating on private companies in the area. DC area is incredibly awesome as a sales and customer-facing managerial / executive professional if you're in the commercial sector aside from niche companies like aforementioned Bethesda and Mythic. But sales is like the opposite of this subforum and generally not considered a first-pick. het posted:I think there's just a dearth of unemployed talent and a lot of the employed programmers aren't looking to jump ship in light of how the economy's been in the last 10 years.
|
|
#
¿
May 18, 2012 21:25
|
|
|
|
| # ¿ May 2, 2024 03:28 |
|
|
One thing that always bothered me about the code you write in interviews is that it doesn't tell you anything about what the person necessarily knows about what they think is shippable production code. We could get into the minutiae of standards and crap that plague programmer conversations around the world, but I think throwing some code in front of a guy and asking him to critique it would quickly tell you things that actually matter faster than testing whether he can produce clever code on the spot. Things like: 1. He can spot buffer overflow vulnerabilities instantly 2. He can see a deadlock / race condition situation 3. He knows not to nitpick non-functional stuff like bracing standards for Java or C during a fuckin' code reading interview (but if it's for Python he should know the standard) It's one thing to try to impress programmers that you're basically a code junkie hacker, but it's another to prove that you're able to do the daily bullshit work of most programming jobs in the world competently. Perhaps if you're interviewing for one of those 1%er jobs you'll have to prove it all, but that's why you're just so drat good and you can pass every single interview you ever get called in for, right?
|
|
#
¿
Jul 10, 2012 16:03
|
|