It was a lie of omission but I'm not sure if that makes it any better. I was hired to work on a new project but it wasn't disclosed that the project hadn't been started yet and has already been delayed for years
To some extent hiring is always aspirational: a reason a company wants to add more people is to get better at skills it thinks it lacks.
This applies particularly to aspirational projects that a company "wants" to start. It hits a chicken-and-egg problem of that it needs to hire skills for that project, but can't start on that project until it hires those skills, many people don't want to be hired unless that project is already off the ground, and in the meantime existing projects still need to be maintained...
Certainly it would have been better for the interviewers to more accurately describe how aspirational their goals and not imply that things were more off the ground than they were. It's a bad way to start a relationship by selling goals as reality. It's also a sadly common way for companies to start relationships.
If you want to try to contribute change, figure out what the roadblocks are to that aspirational project. See if you can find ways to apply your skills to the aspirational project. Sometimes companies forget the bootstrap step in that chicken/egg problem and forget to check if they've added enough resources to start pitching into the new work. Goals continue to be delayed because the company is uncertain and being deliberately conservative about if it has the resources it needs to meet its goals.
Sometimes an aspirational project is looking for a leader to step up, someone with enough passion about the future to get the work started and get prototypes out the door. There's a possibility that can be you, if want to apply for that pressure/responsibility. There's a possibility that in hiring you your managers hope it might be you.
As much as anything, there's a chance here to introspect and figure out if it can be you. Figure out if you can make that pressure/responsibility work for you, if you can make the work/life balance you need, if you can find a way to balance work's existing responsibilities on you (help maintain current systems) with potential new responsibilities (help lead new project). In some companies you might be very well rewarded if you can strike that balance, if you can lead the company onward to meet its goals while helping it survive with its existing needs. It's up to you to assess if the rewards are worth the risks. Your company might be one of the very many that aren't that loyal to its employees and you would be better off elsewhere, but that's something you probably need to judge for yourself.
I guess I'm rambling, but there are ways to make your situation work, if you are looking for them. It's as much on you to discover if you have that capability as it is for the company to solve its own paths to its goals. Starting that conversation with a lie of omission might be an indication of bad faith and disloyalty from the company immediately off the bat... or it might be a sign from the company that it really wants someone/anyone, and that someone could be you, to step up to bat and try to knock something/anything over the plate. It's rare that a company wants a new hire to strike out. Maybe if you can hit a home run you might be rewarded for it, and it might be worth swinging for the fences. Have the conversations you need to figure out if it's worth the pain of swinging for the fences versus playing it safe and bunting until you get the next job offer.
I wasn't hired to work with old junk. if I would have known I never would have taken the job. I also don't have enough money to walk away or risk standing up to management.
The code isn't just old, it's very badly written and has zero documentation.
And I'll add: strive to never create such code yourself. You are 100% correct that everyone says old code is badly written and has zero documentation. So is the code we're writing today. Once you realize that you'll have become enlightened and will be a better programmer for the rest of your years.
You're getting some really angry and personal responses in this thread telling you to suck it up and clean up the code yourself as if thats the path all programmers have to take. Thats not true at all, many companies provide good opportunities for employees to grow within their role in a more positive manner. Cleaning up the codebase would make you a sucker. They lied to you and as you describe it continuing to work there sounds like career suicide. Don't do them a favor by putting in the extra hours and effort into cleaning up their mess (its not YOUR mess). Your time is valuable! By lying to you they are literally wasting your LIFE. Think about it that way and any guilt/obligations you have towards management goes away.
You make a mistake by taking the job but what is done is done. Now you know what questions to ask in interviews to make sure this never happens again. So, if you are unhappy put in the hours you are paid for and start looking. Thats the only way to get another job and change your situation. When you find an offer you like put in your notice and say thank you for the opportunity and keep it professional. Don't tell your boss that you're going to quit ahead of time, thats a great way to get fired because they wont want to train you anymore.
Relo isn't a problem and I definitely want to stay in this town. I can't really mark it as time off because I already did that a while back, I don't want to end up with a lot of gaps :)
I was thinking I could just apply to other places and be honest with them... But some may also frown upon me saying bad things about my current employer
As a hiring manager, if you tell me the reason you left after such a short time was as you describe in this post, I would have no real issues with it.
I'd be looking for some insinuation that you gave it an honest effort and tried to work with your previous company to make it better, but in the end if you got hired for a certain role or stack and it was clearly not what you were going to be doing there's no fault (in my opinion) in you being dissatisfied.
There are certainly times when people can come across as chasing only the shiny and new tech, which is a bit of a turnoff if I'm trying to build a product, but not a deal breaker either. I don't feel like this is the kind of situation that would make me feel that, you weren't getting what you signed up for.
If a prospective new employer already has concerns about employee retention or that they're also overpromising on their stack, they may pass on you- but I think we'd agree that would be best for everyone in that case.
I would also make it a point to let your manager know, as well as HR during your exit interview, how you felt you got bait and switched. It's entirely possible it was unintentional- in which case they could use it as a way to improve and clarify how they're positioning the role. Or, if they're actually lying about it and already know- they won't really care, but it could put the manager or team on notice with someone who does to get their shit straightened out. It might be a long shot, but it might make it better for the next person.
Not necessarily. If you haven't been there for long (and it's not on your resume) it might not even be necessary to mention them directly. It could take a bit of linguistic technique, but if you frame things in such a way that describes what role you were hired for and what role you were given, I don't think anyone could fault you for being dissatisfied.
What about remote that will work USA time zone hours? (I work serious question. Considering doing remote next year and wondered if people consider that cos I work better at night time anyway.)
Some of it is so obsolete and unique it would probably identify the company :) . The rest is slightly less old, MS webforms.
The webforms stuff isn't much better because the code quality is the worst I've ever seen. Adding features and fixing bugs is a stochastic process because you never know what will break.
Usually fixing a bug will expose an old fix that was done improperly for the original even older bug, forcing you to undo multiple levels of hacks to implement your own. It's nightmarish
Yes. The codebase is best described as a giant pile of hacks.
It's the culture more than the tech that causes this to happen. Every time I offer to refactor I'm told to fix it the fastest way and that's how we've been doing it for 10+years.
Sounds like it's time to get out then. I don't know how hard that would be as you said you moved cross-country, so you could be anywhere (in the US I'm guessing). Remote work is always handy.
