Real talk? I'd be concerned that, at a non-tech company, I'd be seen as a IT rather than a software engineer. And the conventional wisdom goes that IT is a cost center.
Some of the best career advice I've ever gleaned is to work on something that visibly makes money for the company. I get to do that every day at my tech company. I don't know that I could say that if I worked in a technical capacity in another industry.
The best "work environment" tech job I ever had was at an investment bank. Didn't disrupt anything (quite the opposite) but got great experience with databases, unix, C, scripting, working with internal clients, determining requirements, managing projects, etc.
9:00 - 4:30 daily hours, no nights, no weekends. Full benefits, good salary, good yearly bonus, quiet office, great people who were there to get a job done and then go home.
Had to wear a shirt and tie but that's not the worst thing in the world.
I'm gonna second this. Started my career as a software dev at a commodities exchange. Pay was excellent for the area I lived in and my experience level, 9-5 was 100% standard and enforced by the team culture, on-call was nonexistent as dedicated support people handled that, bonus was better than the ones I got while working at Microsoft, and got to work with some of the best software engineers I've ever met. Incredible job security, no one got let go or put on any kind of PIP as everyone was pretty self motivated--even if they weren't the best. All in all, I would highly recommend this as a good career path.
I left because it was my first job out of college and I wanted to see what else was out in the world. But it stays a fond memory of a solid job.
There's a very strong correlation "you have to dress like an adult", and "you will be treated like an adult".
Yes, a lot of adults wear sweatshirts and hoodies now. However, if you wore a shirt and tie to a high school, they would make fun of you for dressing up like your dad. We have collectively agreed on a "grown-up" attire.
In other countries, it's very common for boys to wear a shirt and tie to school. Even here it's part of the uniform at many private schools and some charter schools, and it's the norm for children at formal events. It's not 'grown-up' attire, it's 'serious' attire.
I wore a tie to school every day in high school. Then I did it again at a well know startup. In both instances someone pulled me aside to tell me "keep dressing like that and you're going to stand out."
I attended catholic high school in nyc from 1965 to 69 and we wore a sport coat and tie with dress slacks. Hair length inspections were conducted. It didn't kill anyone as far as I know.
The way I've always seen it, if you insist on being able to dress the way you want as a means of self-expression, then you really don't have anything worth expressing.
Dressing for comfort, or to suit the physical demands of your job are valid motivations. I wore a shirt and tie at my first job (back in 1987), but within a few years, I didn't bother any more because no one else did. Nowadays, "business casual" is fine by me.
"If you insist on being able to dress the way you want as a means of self expression then you really dont have anything worth expressing."
My initial reaction was to guffaw at the ridiculousness of such a statement. Expression through fashion and attire is pretty much the entire reason we dont all wear the same thing as each other every day. I feel the exact opposite as you: people who dont dress with the awareness that their appearance is a statement to the world they walk into are missing a massive opportunity to affect their day. How people treat you. How people respond to you. Etc.
But since I'm growing less cynical in my old age, I would care to learn more about your perspective if you care to share.
Well if you think about it in terms of the man-hours that must have been wasted doing "hair length inspections", it's probably equivalent to at least one person dying young :P
The zeitgeist in tech and in culture generally is a moving target. Look at dandyism in the 19th century, no one would argue that is how grown-ups dress today.
I wore a blazer, shirt and tie for every year of school from 11 to 18 years old, everyone did. In fact the last two years we a full tweed jacket that spelt like wet dog when it go wet and was nigh on indestructible.
Which, of course, tech companies don't value at all. From what I've seen, they much prefer to hire a fresh grad over somebody with a long record of proven performance.
So, I agree that one should seek work in tech at a non-tech company.
Apply. I would like nothing more than a flow of applications from smart software engineers with BSs over scientists exiting of postdocing and MCFs.
The skill I look for over all others is an understanding of the standard principles of software design, and principles of testing is a bonus. I want to see that the candidate is honestly interested in our language to the extent that they are familiar with the obvious pitfalls of the standard language features. Candidates who prepared by writing option pricers and passing leetcode challenges won't necessarily understand any of these, because they are simply writing functions.
I assume that anyone who got through a rigorous engineering undergrad has the mathematical preparation to perform as a quantitative developer. This won't be true for all roles, but it's true for all of the QD roles that I have contact with at BB.
If you are interested in a dev role in finance, and see requirements for basic financial knowledge, risk, etc. -- as long as the requirement isn't quite specific, such as experience pricing specific option types, pricing complex products, or with a specific product, I would just ignore it and apply. Many of these concepts are quite simple compared to what SEs are trained to model and implement, and the people on the team who need help know that.
I've seen GPU and C++ skills requested for a Pandas shop. Just apply.
I think hiring managers and HR think they will attract better candidates by adding these things, but it is counterproductive.
From what I can tell from salary surveys, we pay an entry-level dev better than many others. >150 guaranteed all-in first year, and better than that afterwards if you just do your job. Promotion path is good because modern skills are in dire need.
They're large companies recruiting pretty much in all area of technologies. If you have experience in something, you should be able to get an introduction through a recruiter or find an existing employee to reference you.
The only trouble is that finance is only in the NYC area. You can't be there if you are in the valley.
"The only trouble is that finance is only in the NYC area. You can't be there if you are in the valley."
There used to be some in Chicago. Bank of America, Swiss Bank, First Chicago. Swiss Bank is now UBS and I don't know where they do their trading system development. First Chicago got absorbed by JP Morgan Chase. B of A might still do some trading development there, but I have no idea.
Back in the 90s Swiss Bank and First Chicago used NeXT for trading apps, and Swiss Bank had Symbolics machines here and there.
That might be the difference between "investment bank" and "bank" because I've heard stories about near-unhirable people who've been toiling away with Java 1.5 (as late as 2016) at (German) banks. They hated it, wanted to get out, but they'd lost touch with current tech unless they managed to sneak in some off-work hours with non-ancient stuff :/
Working at a (German) investment bank still using Java 6 and Perl 5 extensively in 2018, I can assure you it's not just retail banks. Legacy technology mires are everywhere in the enterprise world and often the premia to work in those places is precisely for dealing with this kind of old technology and decades of technical debt.
In any case the same bank with Blockchain and big data lakes will also be working with mainframes and COBOL, so generalisations about technology aren't particularly useful when it comes to organisations that are so large.
Real talk? There is nothing wrong with being in IT. Imagine if someone said "I would be concerned I'd be seen as a carpenter and not a woodworking artisan".
You're a carpenter. You nail boards together to serve the business interests of the company. Even if the boards are SQL queries or ReactJS or whatever.
Companies need tech. You can bring value by making everyone's jobs better with your technology - sand off those rough edges on everyone's workflows. Demonstrate your value.
> Imagine if someone said "I would be concerned I'd be seen as a carpenter and not a woodworking artisan".
Carpenters build houses, woodworkers build furniture. IT people reinstall operating systems, fix printers and networking issues and software engineers write software. They have a different education, different job description and different pay scales. A woodworker wouldn't make a good carpenter nor a software engineer a good IT person or vice versa.
There is absolutely nothing wrong in being an IT person or a carpenter, they're reputable jobs that put food on the table. But if your trade is being a woodworker or a software engineer you should be slightly worried if you end up being put in a carpentry or IT. Or vice versa.
Disclaimer: I'm biased because I'm a software engineer and a woodworker. I'm good at my job but I can't fix networking issues or build houses.
At any decently sized company, there is no overlap between IT (helpdesk and desktop support) and engineering jobs. I worked at a regional company with six people on the security/compliance team and not once was I ever asked to fix a printer or troubleshoot a laptop. We had dedicated people for that.
It's actually at the smaller companies (like startups) where you'll be expected to do that. I worked at a company with <20 people total in the entire "IT department" (encompassing all computer-related things). Even though my job title was security analyst, I was in Active Directory, I was configuring Cisco gear, I had the on-call phone for the entire department, my phone was in the helpdesk rotation, I'd be dispatched to satellite locations to troubleshoot their wireless.
In my current job as a consultant, I've worked with startups where their engineers are answering support emails and replacing their own hard drives because they don't have a helpdesk or a desktop support team.
'exDM69, I'm not arguing with/against you, just piggybacking off your distinctions to help the conversation. If you're afraid that moving from a tech company to any other enterprise will have you putting on many different hats, it's probably not true. Unless you move to a tiny company, which is true for tech companies as well. Any real enterprise company will have dedicated IT support teams and you will be reprimanded for trying to perform your own IT maintenance since that's not your job.
IT fixes peoples computers. Software Developers don't do that. We aren't Network Admins, we don't know how to set up or fix AD and we don't manage hardware. IT is a different field. I write software to process data and mostly I don't interact with hardware or troubleshooting arbitrary software directly. If I am offering support I am a level above IT. I understand that IT needs to be done but it is a very different job and should be treated that way.
... and that is wrong with the software development today. Our generations of developers started with playing games, using computer, reinstalling, configuring computers, then we started to mess with computers, os, hardware, network, routers, programing came in somewhere in the middle (we wanted to make a game, demo scene, ), cleaning malware, then we started automating the computer tasks, learned multiple programing languages with a clear vision - "I want to learn C, coz then I can do anything" :D, switches multiple computers, security started to become an issue (winnuke (tm) :D), riding the irc splits, taking over irc channels for fun, started to study networks at low level, got first data loss, learned to rescue data, switching controllers on hard disk, studying prolog as it was hilarious, got first job, ... when we started to develop commercial software we had accumulated decade of knowledge from multiple platforms and OSs (I have wrote my first program in simons basic on c64 at age of 11, put together my first 386 from components). We have tinkered with anything coming under our hands, software development was just another skill and we use our knowledge from IT in development and vice versa.
Today? At 20... "what will I be doing for a living? Hm, I did some html and copy pasted js, I WILL BE A DEVELOPER and be RICH". Went to college, learned to develop. But I don't have any foundation, web and sql is all I know, and I am sleeping with Programming patterns book under my pillow and looking at latest programming hype (silently laughing at year of nosql databases and year of blockchain, now AI, and eagerly waiting for the next silver bullet that will solve ALL our problems :D)
IT is not a different field, but the level of today knowledge IS, also the attitude.
A friend of mine is having a successful software company and he said to me once: "If I get a guy with the attitude and background we had, I will hire him even if I wont be hiring at that moment. They became so rare, that it is worth having him on a bench, just to be there when you need him".
Why, I have a good view from here :) And I can take great photos of scenery, now I do understand what the photos are showing is not something that everyone would love but still, those are photos, you can shoot the one making them but the scenery is not going to change by that, or we would just shoot all war journalists and there would be no more wars.
But joke aside, what is the issue, do you disagree?
I started on other peoples computers personally. I poked around and played with linux and some networking and when I went to school for it I realized that it was too late to learn it from the ground up. If you are still trying to figure out how a driver is written in C then you aren't up to date on any current programming paradigm. While I get that 20 years ago you needed to care exactly how memory was handled to properly optimize your code, now I am writing data processing jobs that take 10-15 TB of memory spread across 30 computers. If I fuck up 1 MB of ram per computer it really doesn't matter and it is way more efficient to just add another machine rather than pay me for two months of work to fiddle it down to perfect.
The scales I work at are more about Big O than anything. If I make a mistake that is N^2 vs Log N then I wait a week for a job to finish verses 1 hour. That is an issue. If I add on 10 min because I inefficiently use swap space it doesn't matter. I need to pay attention to the higher abstraction rather than the minute details. Sure I can fix a computer but if I do that rather than stopping a job from doing puts across regions it will cost the company 12000 dollars for each hour I am removing malware.
I would argue that demand has increased dramatically, but the supply of natural-born developers (eg. those tinkering since childhood, not just following the money) has not.
In my experience, Software Developers that can't configure/diagnose/fix hardware/networking issues are usually pretty mediocre at development as well. And vice versa for "IT" guys that can't program. Specialization is for insects.
And, like, literally everyone since Adam Smith and his pins.
Assessing how good people are at skill A by trying to determine how good they are at ever-so-slightly-related skill B is what led google and the rest of the valley down the ridiculous problem solving interview quest of the aughts. Take your manhole covers and suck on them!
Abstraction is a skill, one that’s difficult to assess in an hour-long interview, but one which allows me to say “I’m great at C# but I’ll call someone when the printer is broken” - because there are only so many hours in the day.
Rather, we manage peoples computers, and the environment that allows them to function. The misconception that IT is only there to fix, is because we're invisible to you when everything works as expected.
I worked in a tech startup, where everyone did everything, and where doing everything was considered high-status: it meant you were competent at everything. Or perhaps the other way round: trying to avoid any computer-related task, for whatever reason, was perceived as an admission of incompetence, therefore low-status.
(I didn't agree with that philosophy. I am humble enough to admit that I am not an expert at something, e.g. setting up printers; and lazy enough that I want to avoid such work if I can.)
I also worked in a non-tech company with sufficiently large internal software development department, where as a programmer I focused on developing software; and if any part of the technical infrastructure stopped working, I just called the internal tech support.
> where everyone did everything, and where doing everything was considered high-status: it meant you were competent at everything.
In my current (non-IT/software dev) workplace, the CEO and the manager pride themselves on how all our staff can do everything. We're all sold on it with the line that "..all your future employers will be amazed at how much you can do!" Unfortunately, everything we produce is second rate junk as a result of this, as we are "all responsible for quality control," and the customers pay appropriately.
It's not that it doesn't work, clearly it does for some businesses, it's just that someone has to be responsible for making sure that the product is fit to be presented to the customer, and if everyone's running around doing everything, nobody's really doing anything.
I feel your pain. That is exactly where this kind of reasoning goes.
There is always something you don't know, no matter how "senior full-stack" whatever you are. And when that happens, and the company culture does not allow you to admit it, the only solution is to use google, stack exchange, download a book or two, and perhaps ask a friend -- but neither of that makes you an expert overnight (and sometimes "overnight" is literally as much time as the agile process used in your company will give you; just because someone else, who actually is an expert in that stuff, could do that in a day).
The more I know about the things I specialize at, the more I am aware that you can't reach that depth of knowledge and experience by giving three smart questions to the search engine, and reading the three resulting articles. And by analogy, I assume the same is true about some of the things I don't specialize at.
But I have kids to feed, so sometimes I just bite my tongue and produce whatever is possible within given constraints.
This company culture also leads to playing games where everyone claims to believe that of course anyone can easily do anything -- but there are tasks that everyone is trying very hard to avoid: "It's not that I couldn't do that, I am just very busy now working on some other high-priority stuff that only I can do. Perhaps John would like to take this nice and simple task?" "Uhm, I am also in the middle of, uhm, something. Perhaps Joe could do this?" Joe doesn't have a plausible excuse ready (or is not present at the moment), so he is assigned the task. The meeting ends. If anything goes wrong, it's all Joe's fault.
In long term this reinforces the status ladder within the company, because the high-status guys are in the best position to refuse the tasks outside of their field of competence (by claiming they have more important stuff to do); the low-status guys get stuck with the tasks, produce mediocre results, and that is taken as a proof that they really deserved the low status. (If they are inexperienced 20-somethings, they will quite often buy it, and feel guilty about their incompetence. Then some moment later they change job, and realize it was all actually about the company culture.)
I'm at a "tech" place, but we're very small (8 developers).
Laptops, printers, email, document storage and so on is part of the software development team's responsibility -- so we outsource all of it, and spend a little time on it roughly every 6 months for a new system or similar.
"Hey, I can't print". "Here's the helpdesk number for the people we pay for printers". (Some people were annoyed at first, but understood when they saw the developers' salaries compared to what we paid for the "boring" services.)
I think I've made myself misunderstood. I'm not intending to put down IT work or the people who do it. But from a career perspective, if I want job security and a higher salary, I think it'd be a mistake, in the long term, to be seen as IT. IT is seen as a cost center, which leads to corner-cutting and outsourcing--even when it ends up costing way more in the long run.[0]
Tell that to $250 hr SAP and Salesforce Architects/Developers, or to Baby Boomer COBOL programmers who are given ever increasing incentives to post-pone retirement.
IT is by far more lucrative in the long run. It's just the structure of RSUs and stock options that gives start-ups the illusion of relatively larger comp gains.
No idea what a 'salesforce architect or developer' is, but how would a COBOL programmer be considered IT staff? (In the context of this thread where IT staff == support staff)
Many non-tech employees view IT people as basically “computer janitors with bad attitudes”. Heck, I’ve worked in tech for a decade and I can count the number of people who have a positive view of their IT department in one hand.
To be fair, In my (admittedly limited) experience contracting at BigCorp - the IT department's procedures are often a bottleneck in a workflow or solutions.
We all know they are following business procedure, but there will always be some unconcious tension with departments that hinder a solution (I see marketing and legal butt heads all day).
> Imagine if someone said "I would be concerned I'd be seen as a carpenter and not a woodworking artisan".
It's entirely reasonable for a carpenter not to want a job where they just nail pieces of wood together. Not really building anything, not really using skill. Just nailing a few boards together all day.
Nailing boards together is building something. Carpenters aren't pissed off that they didn't grow the trees themselves and and chop them and haul them and plane them.
Many companies these days make a distinction between IT, digital, and product.
IT runs the network, phones, issues and fixes laptops, maybe provides servers, often is in charge of information security. May own the financial and business intelligence technologies. Unless it's a very enlightened org, this is often the "cost center" team.
Digital talks to the world in a modern way--runs the websites, blogs, social media channels, paid digital ads, etc. Often housed within a larger communications and/or marketing division. Technically a cost center but the visibility makes up for it in the eyes of executives.
Product builds the technology that makes money. This would be like the e-commerce platform, ad network, mobile apps, etc. Executives value things that make money.
Often, all three groups need developers. The tools and roles may differ, but you can be a developer in a major company without feeling "stuck in IT."
This isn’t true any more with software eating the world. I work in movie distribution for instance, which was traditionally sending reels of film, but is now all RSA, certificates, HSMs, remote device management, logistics, Analytics, ticketing, databases and distributed computing. The software team gets pretty much the same treatment as everyone else, but everyone knows it’s the future of the company and sets a pretty high bar.
Speaking of which, our interview process is to ask you to solve a challenge on Github, but you’re free to keep it open source as an indicator of your skills. And it’s not work for us, these are obviously toy / proof of concept problems that we solved ages ago.
The solution to the first point is to go to a place that already has an IT department.
The second (making a bottom-line impact) is probably a non-issue. If it's not a tech company, that means they are likely failing to use tech fully, in places that really could benefit from it. Automate stuff that needs it, and quantify the time saved as:
(time it took before - time it takes now) * number of times each person has to do it per week * number of people * what those people get paid / what you get paid = time T you saved in a week, in terms of your own hours.
Each time you do something, add its T value to a running total. Likely an hour here, an hour there. Eventually it hits 40 and you and the managers can clearly see that your employment is paying for itself. Keep going and you're making them money.
Most larger companies have clearly defined boundaries between IT and software development. And with the push towards automation and security at every layer of the stack, even IT has a growing role for software architecture and development skills.
I've worked at a non-tech company as a software developer. At that place the department (we were rolled in with IT) was viewed as just another cost center. It's not great.
> I'd be concerned that, at a non-tech company, I'd be seen as a IT rather than a software engineer.
Depends on the company. Where I am, IT is in charge of maintaining the computers and networks so that the software developers can develop software in and for other departments.
No, that's nearly every company. But if there's 10 software engineers working with 50 MBA's who drive the business, none of them can tell the difference and treat you as such, which happens more often than not outside of a tech company. They are the ones making the company money, and you are the programmer doing that "easy programming stuff for IT nerds". It's not that rare of a situation
Some of the best career advice I've ever gleaned is to work on something that visibly makes money for the company. I get to do that every day at my tech company. I don't know that I could say that if I worked in a technical capacity in another industry.