Solve real world problems. Doing elegant things is very difficult because the real world is much more convoluted than theory.
Do a few things in depth. Don't jump at the latest thing every few months.
This is THE big difference between S/W dev and IT. For 20 years I worked in the former, and for the past 10 in the latter. No question about it: IT is hell. Theirs is a never-ending mission to reduce the cost of moving data and being "compliant" with often-meaningless ever-excessive corporate standards (and forever meaningless MBA/CIO fads and groupthink).
Worst, in most businesses, IT doesn't have a respected mission. Ii provides an infrastructural service (a cost center) that other C-suiters dis as no more important than HVAC and sewer. IT appears on their radar in only two ways: 1) when something breaks and info clogs up or stops moving, and 2) when the budget is revisited and interest in IT cuts are reinvigorated.
Since nobody else in the corp. respects IT's mission, senior mgt. compels the CIO to adopt meaningless surrogate goals because IT's actual mission isn't sexy enough. So for the next six months IT adopts "Platforms" or trains half the staff in Six Sigma, or outsources, or insources, or promotes of whatever other CIO groupthink initiative is in vogue at the moment.
So yes, work somewhere software is valued, unlike IT.
I fear I'll be hammering out poorly-spec'd features to the beat of another department's Gantt-chart for the rest of my life.
The website provides a decent in-browser editor, or you can write in your own and paste the solution. You get a few data points for expected output, can write up to 10 of your own primitive tests (although I tend to use asserts). Your solution is automatically evaluated afterwards, because it has a bunch of unit and performance tests written for it. When your program fails on small correctness tests, the website says what was the wrong output and what the correct output should be like. VERY nice.
The language used to describe problems is a bit obfuscated and maths-like, but I treat that as extra challenge. You certainly don't have to remember much from your university or high school to get started. It is important to understand and rephrase what they are asking of you.
I interview for backend engineer jobs. I notice a common theme in the interviews: efficiency. They are very concerned with transactional throughput. They optimize everything from the services layer to the database for trimming every microsecond. At a past interview, the people wanted me to talk about the efficiency and implementation of various data structures: nothing exotic, just garden variety queues, stacks, lists, and hashmaps. They quizzed me on threading issues. One guy got into various indexes in a relational database and then jumped into TCP vs. UDP questions. In my most recent interview, the guy started by asking me the difference between optimistic and pessimistic locking. In my IT job, I never deal with locking issues: they are all abstracted away. Two-thirds of the way through the interview, I remembered and circled back to the question. However, the damage was more than likely done. A person who deals with those issues daily would never forget. But, I know what to work on for the next interview.
I understand your predicament. It’s deadening on every level when you’re doing work beneath your capability and interest, but you don’t have the necessary knowledge to get through an interview for more interesting jobs. Hopefully, the observation I made above helps you to target particular areas to successfully navigate an interview.
Companies who base their interviews on CS curricula generally just end up only hiring people who've graduated recently enough to remember it (i.e., their staff ends up being junior because they're selecting for something that's, ironically, an anti-indicator of experience more often than not).
Alternatively, just put yourself out there. You don't need to be great, just find a job a little closer to your goal.
Because I bet you that you could find some if you switched from targeting straight dev roles to something else that is part of a SW org.
Any suggestions on alternate roles to look for? I'd worry that just because it's a software organization, it doesn't mean I wouldn't be filling their own version of cog in a cost-center.
So time spent using X is great, but just saying "I can learn" and giving an example of how you're able to learn is often enough. Then just look at X enough that you know the gist of it, have a small little sample project in your github account, and you'll be good enough that someone will hire you.
These people should focus on improving their credit, cutting expenses, and building up savings so that they can take the salary hit that will get their careers on a better track for the ~20 years until they're eligible for retirement.
Alternatively, these people can go in through a social backdoor. Befriend a powerful person at a company you'd like to work at and demonstrate why he needs you. If he has authority to set salaries, he will likely do everything possible to accommodate your higher-than-market salary, even if he can't get you 100% of the way there.
But beware: overpaying an employee is the best way for a company to trap him/her. Do everything possible to not become dependent on a rate you can't easily command somewhere else.
no pain, no gain.
I work at an SV software vendor which sells to big enterprise IT groups. From what I have seen, firms are starting to take their IT groups more seriously.
[1] http://a16z.com/2016/08/20/why-software-is-eating-the-world/
That describes exactly the IT department in my company.
"Hey aren't you in IT can you help me with my computer issue"
One of the things I dislike the most is being referred to as "The IT Department".
The only place where I've seen IT being highly respected.
I've done both and I can't say one is better than the other. I've worked on software products where marketing couldn't figure out how to sell it and kept changing the core functionality. Or where the CEO kept shoving his ludicrous ideas onto development. I've worked on rewarding IT projects where I worked very closely with the users and was very happy to see my work help them perform their day-to-day jobs. I've also worked on slog IT projects where the users had no idea what they wanted and we kept churning.
After 28 years, I ended up preferring working close to the actual users.
Check and check. There's also my personal favorite: marketing informs the dev team they've just inked a big contract with a tight deadline for features that were never discussed with the dev team. "We kinda told them we already had those features but hadn't released them yet. Can you guys build that real quick like?"
However, recently I read Developer Hegemony[0], which seems to describe a path for IT developers to also have rewarding careers.
My current thinking is that the Agile philosophy definitely contributes both to successful projects and to satisfying careers for IT developers (Agile came primarily from that world of software development) but only when developers and users are equal partners. That generally only happens when the developers are independent consultants who can speak the language of business.
However, I do think that the original signers of the manifesto were onto something. My recommendation for people is, rather than learning an official methodology, that they go and read the writings of the various different signers. Get an understanding of what it meant for them at the time that they signed the manifesto.
Martin Fowler has commented that one of the other names they thought about calling their movement was "conversational software", in the sense that software development process was an ongoing conversation between the developers and the users of the system.
The point I gleaned from the book I mentioned was that (in the general case) the power politics of most IT organizations prevents the development process from every being a real conversation.
As I understand it, many of the signers were independent consultants at the time of signing (or helped lead IT consultancies) and could speak the language of business. It seems to me that perhaps this put them in a more "peer" relationship with the business stakeholders, and allowed the development approach to be more conversational.
This is key.
These are great! I would also add: be certain that the organization shares your values. If you really care about code quality, elegant solutions, etc, you'll have a frustrating time working at a company that doesn't prioritize those things.
Once you have developed the necessary software skills in a "software house", in my experience, the best thing to so is to get stuck into a particular domain, where the company needs software developed (not IT), but is not the main business. These jobs and contracts attract the best $, but also in my experience, highest job satisfaction - you are not just a cog - well, less so, IMO.
Very true, but the company culture also needs to be right in order for this to really take hold. There's also the fact that the work and schedule will likely be more demanding. This can be a positive if you enjoy the work, but a big problem if you dislike unpredictable hours. When the company's primary revenue source is software, you will have to work extended hours at some point or another to solve critical business issues.
So a software company as opposed to working in an IT department - programming and solving problems that really _aren't_ interesting?
That's one of the main things I crave these days (and I think it would make a big day-to-day difference) is to work at a software company as opposed to a company who leverages software.
I don't work at a software company, or even a traditional "tech" company, but I write the software that powers our most profitable product. Since I'm the odd-man-out, and the higher-ups love org charts, they stuck me in the IT department. Net effect: IT just became a profit center and everybody in the company knows it.
Would that be the primary product of your company, or something that empowers other employees to work faster, and push _their_ products more easily?
I've been blessed by having experience in several, very different kinds of applications (web apps to avionics). Over time, I've realized the specifics of the problem at hand are more-or-less irrelevant to my happiness. I'm looking for something that's sufficiently technically challenging, where I can be surrounded by honest, friendly people, and make decent money.
This is very close to my real goal as well - but CRUD apps seem like the norm lately :(
Does this mean that you salary isn't increasing, or that you aren't valued at all?
I'm curious how most people receive or handle (or if raises are even a thing)
It was slightly better, since people understood software's value, and Ops was shared between the devs and IT. However, maintaining that sort of culture always felt like a constant battle. Management often slipped into IT = cost center.
In fact, my job officially became bridging this gap as an IT Business Partner. I don't think I did a very good job.