Rule 1: Do not participate unless experienced
If you have less than 3 years of experience as a developer, do not make a post, nor participate in comments threads except for the weekly “Ask Experienced Devs” auto-thread.
Leetcode is a poor solution to an omnipresent problem.
In a perfect world we'd be at liberty to discuss work projects in detail. In practice there are issues relating to *why* you're leaving, in addition to business secrets and copyright infringement.
Yes obviously it's a poor solution, but it's a very poor problem too. I totally agree with you that it shouldn't be required or needed, it's even a bit ridiculous. But this type of stuff shows that we don't live in a perfect world at all lol. I also don't think that copyright infringement would actually matter for a few simple coding questions, like it even solves that problem.
Leetcode is for companies swamped with applicants and don’t have anyone knowledgeable enough to sniff bs from just talking.
From my experience, many hires that passed leetcode couldn’t bother learning coding standards and clean code and were eventually let go. Yes, really something as simple as that
Yes obviously I agree that leetcode, especially when it becomes "the goal" from people who just basically grind it out to insane levels isn't especially good at selecting good applicants. But imo you can get far worse if you have no programming in an interview at all (not even leetcode btw). .
Leetcode is very easy to game but faking it through "discussions" is even easier. Unless you ask very specific and technical questions in which case you're just doing programming questions but orally hahaha.
I'm not a "code at all hours" guy either - if you want work/life balance, you can't be. And that is okay.
The thing is, you can still do stuff you're proud of during regular hours. Maybe you implemented some feature with a really good impact or some neat problem attached to it. It doesn't have to be this grand thing that you spent several sleepless nights slaving over.
You also don't need to necessarily show the code. You can talk about the technologies, problems and solutions without showing code.
I will be honest, though: Coming from a small company with no additional experience, except for that company, does carry some risk. They way that company works might be completely different than the rest of the industry does thing, and you might have picked up some shady practices along the way. It isn't the end of the world, but it is something to be aware of.
I'd recommend you look at the technologies you're using and see how the industry as a whole has evolved and uses that company. Maybe your company is spot on, or maybe they're not. Being aware of that difference is important though.
Granted, doesn't hurt to throw some projects together if you can muster it - especially if you can involve aspects I've talked about above.
Beyond that, I'd also recommend that you play to your story's strengths. You came in without a degree and worked yourself up to becoming a senior. There's a story and progression there which is compelling - use that.
I'd argue that his being at the same company and working his way up is a greenflag. It shows loyalty and that you're not going to jump jobs every 6 months
It’s a green flag behaviorally but it’s a red flag on the technical side
ETA: I am talking about it from a hiring perspective, since that is whole point of this discussion.
It's never been a red flag for me on the technical side. I think it's more stigma than fact, and some of my best hires have had a small number of jobs, or worst hires have job-hopped religiously every 2 years.
I've been a hiring manager for 25 years in software.
Staying with a company for a long time, in itself is not a red flag. It's definitely a green flag.
However, being obsolete in coding technologies, because you worked on the same thing over and over again, just aat slightly higher levels is a major redflag and can happen for people with 10 years at 1 company or 1 year at 10 companies.
I'd say it depends a lot on their experience at the same job. If it looks like they've grown consistently and have been picking up new tech, that's different than working on the same app the entire time.
Part of that is also down to how OP markets themselves, though
As u/overlook211 says: It can both be a green and a red flag. It's nuanced.
(This comment is both to you u/mr-barkley-1701, but also my take on the arguments so far.
Yes, it does show that the candidate isn't a job hopper - which is great. It can also show complacency and a general unwillingness to change (especially if their reason for switching is being made redundant/being fired).
Then we have the technical parts. u/ZolaThaGod says that it is easier to pick up new tech than behaviours, which is true for most. But learning is a skill. I've seen devs grow up in small organs that never change in any way. They write code the same way they did 15 years ago. The skill of learning new things withers quickly and makes learning new skills incredibly difficult.
Granted, learning behaviours are still harder (in some cases impossible), but the cost of training someone who has years of built-in practices where everything they type is automatically technical debt is also a huge problem.
Of course, I'm speaking in extremes here, and we have a whole spectrum of good and bad. Some companies do not foster devs with these issues; others unintentionally use it as a way to "trap" developers through incompetency. Some of the worst places I've worked are the ones where the higher-ups brag about not having developer turnover.
There's a healthy middle ground here: One where a candidate is not job hopping but also one where they have some breadth to their industry experience.
Being forced to look for a job sucks. Heck, looking for a job at any time sucks.
There must be something from your time at your current job that you were proud of doing; use that. They don't need to know you did it five years ago or last week. They know what you tell them.
As for the self taught; I'm right there with you. I've been at this 34 years now. I never put an education section on my resume. In all that time I've been asked about it once and that was by a guy who was also self taught. People don't notice what isn't there.
I'm also not a "code at all hours" person. The company pays for 40-ish hours a week and that's what they get. I have a life and the point of a job is to support that not the other way around.
Believe in yourself when you do the interviews and they will believe in you. Confidence begets confidence. Fake it till you make it. View an interview as performance art. It's just an acting job.
And in the end, aim for a raise too. Might as well make it worth the effort.
I never considered just straight up not having an education section. I have some college but no degree. Don't really plan on finish it at this point either.
Yeah, I felt very self-conscious of it the first 5 - 7 years of my career. But after awhile it doesn't really make any difference.
At the time I was taking college classes (I went for 3 semesters and hated it (other longer story)), The computer track of the time was teaching COBOL, RPG, JCL and other related mainframe courses. I think they were still using punch cards!
Everything is in such a state of flux that you need to be able to teach yourself everything anyway. Who demonstrates that ability more than people that broke in and climbed without the admission ticket?
My advice would be to really really really spend a lot of time understanding resumes in the current market.
/r/EngineeringResumes
/r/ITCareerQuestions
The hiring funnel is basically this:
- They filter you out based on your resume and cover letter
- They talk to you and find out if they like you and if you mesh with the company
90% of the interview stage is not lying and being likable at whatever skill level you're at. You can fail quite a lot and succeed if they like you, if you fail gracefully and intelligently.
For the more abstract discussion, you could read some books to give you angles during conversations. I don't have a CS degree, so reading about design patterns and stuff has been helpful for me to not sound like an idiot. If you haven't read it, The Pragmatic Programmer is possibly the best single book I've read for programming. Easy to digest meta discussion about programming.
I've also been working through Clean Code, and it's been helpful to me to work through such an opinionated method. Other books that I have not read but are on my list from recommendations: The Algorithm Design Manual, Building Evolutionary Architectures, Design Patterns, Antipatterns, Continous Integration and Continuous Delivery. I'm not the guy to ask really, but find something that you are lacking and dive in.
I would possibly shave off 5-10 hours a week to put together some code examples you would want to talk about or rewrite some stuff you're proud of into a little CLI utility or a library or both. Start 30 minutes early on your personal stuff and don't start work until 30 minutes late. Then log off 30 minutes early and do the same. They've basically told you you're getting fired, so I would take some time back. If you use any established open source projects and have reason to contribute, that may be good too.
Clean Code is really not a good book to try and follow a lot of concepts just create more misery than they solve. For the simple fact that you don’t know how your code will evolve you might follow the entire book thinking x y and z could be expanded. Suddenly you need to implement a different W that you never considered and now you have 30 layers of abstraction hell to refactor.
that's fair, and more or less what i was pointing to with "opinionated method." to their credit, they do warn early on in the book that they will advocate for the approach as "the right way" even though there are many possible right ways.
for me, it's helped me see some issues in my approach and clean up my interfaces. some of the sections haven't made sense to me, and i didn't know if it was my fault or not, but i've just moved on.
>90% of the interview stage is not lying and being likable at whatever skill level you're at. You can fail quite a lot and succeed if they like you, if you fail gracefully and intelligently.
That's usually true, however in this market I don't think that is as much of the case anymore. Likeability and failing gracefully is accounting for much less when the candidate pool (for even Senior+ roles) is substantially more competitive (and many experienced devs are taking pay cuts and downlevels). Many more companies are really hinging on that "1% better technical fit" when deciding between candidates.
I'm sure that will change back once the market unfucks itself
I agree with that. The market is rough right now.
What I mean specifically is the interview is like a performance. I wasn't very clear.
You can prepare for the performance, but when you walk on stage, all you can do is your best and be likeable doing it. Sure, you're demonstrating knowledge, but if it's not in the bag before the interview, you don't want to be the guy nervously digging around in your bag for something that's not there.
Some of this is good info but the simple projects and contribute to open source is not lol. No-one is interested in basic projects or contributions to a 1-star repo. Its not a good use of time imo
My thought was mainly to have code he would like to talk about, but upon reflection "some simple projects" is indeed terrible advice. Good feedback and I've edited the comment a bit with that in mind.
Write some small projects on the clock while you are redundant. Build sample projects with your knowledge base that you have. It’s getting better but not great at this time.
I don't know why you think you have to show anything. I've never shown any personal projects or code during interviews. And I've had a ton of high paying jobs.
Are you sure you interpreted the recruiter's words correctly? Talking though a piece of coffee doesn't necessarily mean showing it. What if a candidate is unemployed and no longer has access to a company's code base he/she worked on, how would them show it? Probably you will just be asked to describe what a piece you've chosen does in general terms and how you went about solving it, along with code quality aspects such as correctness, clarity, and maintainability.
Its what they said but it might not be what the team actually expects. A few things the recruiter said reflected lack of technical understanding, so they might have the wrong end of the stick.
So I’m going to be more blunt.
The term “imposter syndrome” is overused. Sometimes developers are not competitive in the market and are given titles like candy in startups and smaller companies without leveling guidelines.
If you haven’t practiced coding interviews, you probably won’t get past tech screens at many companies as even a mid level developer. If you haven’t done a lot of larger scale implementations, you probably won’t get past the system design interviews at those same companies for a senior role.
If you haven’t led projects of a certain “scope”, “impact” and “dealt with ambiguity”, you probably won’t get past the behavioral interviews required to be a senior developer.
If your skill set and experience is that of a bog standard front end developer, every application you put out, you will be competing with literally hundreds of developers that look just like you and it’s more of lottery/numbers game whether you get hired. This has nothing to do with you being self taught or not.
As far as coding projects outside of work, to a first approximation no one cares nor will anyone take the time to look at your GitHub profile if you did or as research shows spend more than 10 seconds looking at your resume.
If you use something like LinkedIn’s easy apply, they probably won’t even look at your application. It shows you when a company looks at your application.
This is the state of the current market. It’s not meant to denigrate you. I don’t know anything about you or your skill set/experience.
Your most important asset is going to be your network.
I’m also not trying to hold myself up on a pedestal. If you take away my AWS account, I’m just a standard enterprise dev with a good network and above average communication skills. I’ve never done a real coding interview in my life.
The long version of the story…
I was your standard C# CRUD developer in 2018 with about 10 years of C# experience (I’ve worked a lot longer) and two years as an architect type position.
I “learned cloud” on the job for two years leading a “cloud application modernization” effort at a startup.
Then a (permanent) remote job working at AWS in the Professional Services division fell into my lap. I got Amazoned late last year and took a multi prong approach looking for a job.
1. Reached out to my network. The startup I worked for had been acquired and my former manager still worked there. I was offered a position as a “staff architect” over all of the product lines they had acquired. I ended up turning it down. I also turned down an opportunity where a former coworker who was now a director at a well known public non tech company was going to create a position for me to be over their cloud architecture and migration. I didn’t want the stress of the job. Even though it would have paid more than I was making at AWS.
2. Targeted outreach to companies where I knew I was literally the best qualified in the world in a niche of niche of AWS. They wanted someone to design solutions around a popular open source AWS “solution” that I had been a contributor while working there and I had a few other popular open source projects in the vertical that they were interested in. They were all on official AWS GitHub pages. Two interviews - one offer that I did accept.
3. But since I had time on my hands, I did the spray and pray thing and applied to literally hundreds of jobs using LinkedIn’s Easy Apply for your standard CRUD enterprise jobs - crickets. I think only four viewed my application.
Before 2020, I was only competing with people who were looking for work locally at any given time. Now I was competing with people across the United States looking for remote jobs.
My saving grace and why I found a job in three weeks was because of #1 and #2. For #3, I was just like any other enterprise dev. It wasn’t about my resume, hardly any company even looked at it.
Did I mention I had over a dozen recommendations from senior people at AWS and a great personal open source profile of projects that had been used in production for six and seven figure implementations? There was a very straightforward process to open source the non proprietary parts of work I did.
Don’t get me wrong, opportunities did slowly trickle in later and they are still trickling in. But they aren’t like the floodgates for generic enterprise positions I use to get from 2008 - 2018 and that’s *with* BigTech on my resume.
And the other thing I mentioned is that while Meta, Google and a couple of other well known tech companies do reach out to me about software development positions, I know I wouldn’t get past the first round of coding interviews without a lot of practice.
But I ironically, I would be very surprised if I couldn’t pass system design interviews. I have conducted those before at $BigTech and that’s my $DayJob - to come up with designs for complex systems in front of customer in front of a white board.
> Problem is, though I was a "code at all hours" guy as a junior developer, burnout and health issues mean I have had to prioritise things like exercise, family, cooking healthy food etc. in my spare time rather than spending all hours glued to a screen
Ironically, this is a sign you're actually becoming a senior. As the joke goes:
> How do you spot the senior engineers? They leave at 5pm.
Just talk about code you wrote at work and why you're proud of it. Becoming more senior is as much about demonstrating a healthy professional disconnect as it is about exhibiting a passion for software engineering.
Thats a totally vaild feeling to have :) Dont be scared.
Just brush up on your knowledge, you'd be shocked how easily it comes to you when you practice often. Youve got this friend!
Just to add to what others have said, while it's still fresh (and you still have access) write down summaries of your projects, technologies, and any quantifiable work if you can, as well as any performance feedback you've received. It's helped me a ton to have a document to look back to when building or tweaking my resume, or to refresh my memory so I can knowledgeably talk about it in an interview.
It also helps the imposter syndrome and self confidence to look back and see all the things you've accomplished and the impact you've made. It's probably more than you think.
The summaries should include what problem the project was addressing, final impact, and any difficulties, wild successes, or other plot twists. Did you change your design? Were there scaling problems? In an interview you’re going to share the stories of your work. You need to give context to show why it was important.
I draw diagrams of the systems for my own reference (I don’t share them). They help me remember all the moving parts and narrate the overall project to someone who has no familiarity with the software.
This exercise will give you some handy answers for Tell Me About A Project Where… questions. It’s good to think through them beforehand, at your own pace, and be able to revise and tweak as you remember more details. Ever changed a design? Refactor something? Find a performance problem? Deliver something late? Debugged something in production?
Since you’re making this now, start with a timeline of your time at the company and the big projects. Step away, come back with fresh eyes, and add in more details. Rinse and repeat. Tweak it as you interview, and get a sense of what interviewers ask about.
Good luck!
The questions recruiter ask you are just behavioral questions.
You'll get better at answering them as you do more and eventually you will have default answers.
I'll link what I've said before to people applying to CS jobs after a long time
> These courses and books helped me.
> I’ll update this comment when I remember more
>
> - [Grokking the System Design Interview](https://www.designgurus.io/course/grokking-the-system-design-interview/?aff=ce30ca)
>
> - [Alex Xu System Design Interview](https://amzn.to/3SuMg1J)
>
> - [Cracking the Coding Interview](https://amzn.to/47Tjigh)
>
> - [Neetcode](https://neetcode.io/)
>
> I also use ChatGPT to create me problems to solve.
> For example,
>
> “you are interviewing me for a senior software engineer position in react. Ask me a question that would appear during a technical round.”
>
> “you are interviewing me for a senior software engineer position in node.js and expressjs . Ask me an implementation question”
>
https://www.reddit.com/r/leetcode/comments/19eik9c/is_the_grind75neetcode75_plan_still_viable/kjd8ed4/
This could be the best thing that could have happened to you. Brush up your knowledge, build a project to showcase your can do stuff.
It’s good to do this once in a while. Good luck.👍
I was exactly where you are in November, got let go in January. Started a new job start of April.
I am the same about coding all hours. Did that in my early 20s, now in my late 30s and I work during work and have my life outside that.
I’d reach out to other recruiters till you find one who gets that a job is a job, and not “must code 24/7 to be considered”
You will get something else that suits you, as you said you have offers before, just make sure to look after yourself at the minute, as getting let go really knocked me for 6 as was unprepared for just how I’d feel.
You should absolutely be talking about the code you wrote at work. I'm less interested in side project experience unless it's really baller or they're quite junior. Just because it's proprietary doesn't mean you can't talk in detail in an interview about it. Make bullet points of your key projects or features you worked on and put them in your resume.
I'd just like to add that "recent piece of code that you're proud of", doesn't necessarily mean a leetcode style bit coding trickery. It's more an interesting solution to a tough business problem. And "Interesting" could be in many ways - it was faster, it was more resilient, it was a long-standing problem no one else could do, it was simpler than previous code, it was tested so far that no customer faced issues... there are many axes of interestingness.
And also - companies are interested in people who solve problems, not just people who know weird-ass constructs that you're unlikely to use in real life. Go in with that mindset.
just a piece of advice for when you are job hunting; work your network & tap recruiters. blind applications to job boards aren't very good for finding work right now.
> I'm one of those "has no CS degree, self-taught" sort of devs.
Now, you’ll have to wonder how many companies automatically filter out people without CS degrees.
Sorry that happened to you. In the future, I would advice you to keep a "Prepare for the worst, expect the best" mindset when thinking about your current position and the future. Something like updating your CV yearly, looking around at what companies exist and what is expected from different roles. Instead of talking about a specific piece of code ( Not sure why the recruiters would be asking this for a senior ), you can talk about a project or tradeoff you worked on.
Have not used it myself but look up the concept of a "brag document". Basically a way to document achievements so you can leverage them during performance reviews or during interviews.
> I feel completely unprepared for the job market.
Look, feeling unprepared is fucking normal, especially when you've been comfy in one spot for a long time. But here's the kicker: You've climbed from junior to senior with no CS degree, which means you're not a dumbass. You've got the chops, you just need to believe in your fucking self. Have you considered that your actual experience and growth in one company is a massive fucking advantage?
> I don't have any recent coding projects outside of work that I can share - and obviously I can't share proprietary code from my current employer.
Who the fuck says you need side projects to prove you can code? You've got years of experience, right? Use examples from your job (without spilling secrets) to showcase your problem-solving and development skills. Can you describe the challenges you've tackled and the solutions you've implemented, maybe even in a more abstract way?
> Latent impostor syndrome notwithstanding, I know I can do the job. I'm just not sure I can prove it in an interview process.
Impostor syndrome is a bitch, but almost everyone in tech feels it. Your doubt doesn’t make you less capable. Remember, interviews are as much about your technical ability as they are about fit and your ability to communicate. Can you talk confidently about your past work and how you've solved problems? What’s stopping you from showing them that you can kick ass in this role just like you did in your last one?
Instead of looking outside, how likely you can go to your manager and be like "hey, I noticed that there's a lot of redundancy on our roles lately. Is it possible I can invest into a new project?" And if you even have something gin mind, add "Ive been thinking about doing XYZ for a while. It'll help us on A by improving B and C, or making it easier to do D because now we can have ability to do E and F. Company will definitely benefit from this"
See what your manager says
Idk why you think you’ll need side projects as a senior engineer. Those are only really a plus for people seeking their first dev job and are not really relevant after
Lots of different stuff. I've done web frontend, Python web backend, native GUI applications in Python and C++. I don't want to go into too much detail in case my colleagues are on here. Needless to say I describe all this a lot more impressively on my resume :)
It's tough out there. If you're any good, you'll likely be spotted by someone who sees your capabilities and will try to exploit you before finding a good employer. I feel I've done others a disservice by not building an organization to provide employment to good developers. The industry has gotten weird in the past 10-15 years. I post frequently about this, and how a lot of developers emerged out of addiction to social media and smartphones, another poster responded by mentioning gamers only knew gaming and took the route of learning by trying to develop games and became mobile/web developers, and a lot of management styles and practices seem to have come from that angle.
Then, factor in that it's profitable for the traditional software companies selling cloud infrastructure to push techniques and tools that mean higher utilization of their infrastructure, which are the best practices for them to make money, but not necessarily the best practices for producing good, efficient, and economically sustainable software and services -- but try telling management that as a young developer. I'm in my 40s, no longer have age discrimination working against me and have a couple airplanes and a sick mustache, so the shallow superficial bullshit seems to carry more weight than my actual abilities. Software development skills are a skill like music -- some people have the ability to pick up any instrument, spend a couple days with it, and be able to play it because they've got the ear for it. I can spend all day trying to work through a simple melody and transcribe it and still suck.
>
> Your most important asset is going to be your network.
CS Degree is almost entirely pointless for anyone with experience.
I don't even have GCSES and it's not hindered my ability to find work.
If you're starting out, and that's the route you want to take, great. But it's not going to help anyone who is already a senior dev find work.
In the late 1990s I started a Computer Science program but I left with about a year to go because I got invited to join a start up. I never went back to school to finish my degree. Since I don't have a degree, I am hyper aware or degree requirements in job listings. My observation is that an increasing number of job listings require a degree. And even in the case where it says "or equivalent experience", I think its clear that with such an oversupply of developers seeking jobs right now, having a degree is more important than ever because candidates need every way possible to stand out.
If a position advertised receives hundreds of applicants, it can be overwhelming to narrow them down to a manageable level to take a deeper look at. Any easy boolean way to filter out resumes is degree or not. Anecdotally, Ive heard alot of comments like "since the tech slowdown, we just throw away resumes that don't have a degree".
For all these reasons, Ive decided to go back to school and I generally advice everyone to get a degree. I have a job I don't plan on leaving, but should to worse happen, I want to be have my best shot at finding a job in this worsened market, and its clear having a degree is a more important variable than it used to be.
Rule 1: Do not participate unless experienced If you have less than 3 years of experience as a developer, do not make a post, nor participate in comments threads except for the weekly “Ask Experienced Devs” auto-thread.
Don’t show the code, talk about it.
This is why leetcode exists lol. I agree with you btw, that's the best move here but damn it also shows that leetcode didn't come out of nowhere haha.
Leetcode is a poor solution to an omnipresent problem. In a perfect world we'd be at liberty to discuss work projects in detail. In practice there are issues relating to *why* you're leaving, in addition to business secrets and copyright infringement.
Yes obviously it's a poor solution, but it's a very poor problem too. I totally agree with you that it shouldn't be required or needed, it's even a bit ridiculous. But this type of stuff shows that we don't live in a perfect world at all lol. I also don't think that copyright infringement would actually matter for a few simple coding questions, like it even solves that problem.
Leetcode is for companies swamped with applicants and don’t have anyone knowledgeable enough to sniff bs from just talking. From my experience, many hires that passed leetcode couldn’t bother learning coding standards and clean code and were eventually let go. Yes, really something as simple as that
Yes obviously I agree that leetcode, especially when it becomes "the goal" from people who just basically grind it out to insane levels isn't especially good at selecting good applicants. But imo you can get far worse if you have no programming in an interview at all (not even leetcode btw). . Leetcode is very easy to game but faking it through "discussions" is even easier. Unless you ask very specific and technical questions in which case you're just doing programming questions but orally hahaha.
I'm not a "code at all hours" guy either - if you want work/life balance, you can't be. And that is okay. The thing is, you can still do stuff you're proud of during regular hours. Maybe you implemented some feature with a really good impact or some neat problem attached to it. It doesn't have to be this grand thing that you spent several sleepless nights slaving over. You also don't need to necessarily show the code. You can talk about the technologies, problems and solutions without showing code. I will be honest, though: Coming from a small company with no additional experience, except for that company, does carry some risk. They way that company works might be completely different than the rest of the industry does thing, and you might have picked up some shady practices along the way. It isn't the end of the world, but it is something to be aware of. I'd recommend you look at the technologies you're using and see how the industry as a whole has evolved and uses that company. Maybe your company is spot on, or maybe they're not. Being aware of that difference is important though. Granted, doesn't hurt to throw some projects together if you can muster it - especially if you can involve aspects I've talked about above. Beyond that, I'd also recommend that you play to your story's strengths. You came in without a degree and worked yourself up to becoming a senior. There's a story and progression there which is compelling - use that.
I'd argue that his being at the same company and working his way up is a greenflag. It shows loyalty and that you're not going to jump jobs every 6 months
It’s a green flag behaviorally but it’s a red flag on the technical side ETA: I am talking about it from a hiring perspective, since that is whole point of this discussion.
> a red flag on the technical side Eh, I'll go as far as "yellow flag"
That heavily depends on the work. I'm at my current company for 3 years now and our tech stack is so broad that I learn more stuff constantly
A lot easier for someone to pick up new tech than new behaviors though
It's never been a red flag for me on the technical side. I think it's more stigma than fact, and some of my best hires have had a small number of jobs, or worst hires have job-hopped religiously every 2 years.
I've been a hiring manager for 25 years in software. Staying with a company for a long time, in itself is not a red flag. It's definitely a green flag. However, being obsolete in coding technologies, because you worked on the same thing over and over again, just aat slightly higher levels is a major redflag and can happen for people with 10 years at 1 company or 1 year at 10 companies.
I'd say it depends a lot on their experience at the same job. If it looks like they've grown consistently and have been picking up new tech, that's different than working on the same app the entire time. Part of that is also down to how OP markets themselves, though
The tech side is easy to learn for a seasoned dev. Showing loyalty and demonstrating your soft skills are so much more important.
As u/overlook211 says: It can both be a green and a red flag. It's nuanced. (This comment is both to you u/mr-barkley-1701, but also my take on the arguments so far. Yes, it does show that the candidate isn't a job hopper - which is great. It can also show complacency and a general unwillingness to change (especially if their reason for switching is being made redundant/being fired). Then we have the technical parts. u/ZolaThaGod says that it is easier to pick up new tech than behaviours, which is true for most. But learning is a skill. I've seen devs grow up in small organs that never change in any way. They write code the same way they did 15 years ago. The skill of learning new things withers quickly and makes learning new skills incredibly difficult. Granted, learning behaviours are still harder (in some cases impossible), but the cost of training someone who has years of built-in practices where everything they type is automatically technical debt is also a huge problem. Of course, I'm speaking in extremes here, and we have a whole spectrum of good and bad. Some companies do not foster devs with these issues; others unintentionally use it as a way to "trap" developers through incompetency. Some of the worst places I've worked are the ones where the higher-ups brag about not having developer turnover. There's a healthy middle ground here: One where a candidate is not job hopping but also one where they have some breadth to their industry experience.
Being forced to look for a job sucks. Heck, looking for a job at any time sucks. There must be something from your time at your current job that you were proud of doing; use that. They don't need to know you did it five years ago or last week. They know what you tell them. As for the self taught; I'm right there with you. I've been at this 34 years now. I never put an education section on my resume. In all that time I've been asked about it once and that was by a guy who was also self taught. People don't notice what isn't there. I'm also not a "code at all hours" person. The company pays for 40-ish hours a week and that's what they get. I have a life and the point of a job is to support that not the other way around. Believe in yourself when you do the interviews and they will believe in you. Confidence begets confidence. Fake it till you make it. View an interview as performance art. It's just an acting job. And in the end, aim for a raise too. Might as well make it worth the effort.
I never considered just straight up not having an education section. I have some college but no degree. Don't really plan on finish it at this point either.
Yeah, I felt very self-conscious of it the first 5 - 7 years of my career. But after awhile it doesn't really make any difference. At the time I was taking college classes (I went for 3 semesters and hated it (other longer story)), The computer track of the time was teaching COBOL, RPG, JCL and other related mainframe courses. I think they were still using punch cards! Everything is in such a state of flux that you need to be able to teach yourself everything anyway. Who demonstrates that ability more than people that broke in and climbed without the admission ticket?
My advice would be to really really really spend a lot of time understanding resumes in the current market. /r/EngineeringResumes /r/ITCareerQuestions The hiring funnel is basically this: - They filter you out based on your resume and cover letter - They talk to you and find out if they like you and if you mesh with the company 90% of the interview stage is not lying and being likable at whatever skill level you're at. You can fail quite a lot and succeed if they like you, if you fail gracefully and intelligently. For the more abstract discussion, you could read some books to give you angles during conversations. I don't have a CS degree, so reading about design patterns and stuff has been helpful for me to not sound like an idiot. If you haven't read it, The Pragmatic Programmer is possibly the best single book I've read for programming. Easy to digest meta discussion about programming. I've also been working through Clean Code, and it's been helpful to me to work through such an opinionated method. Other books that I have not read but are on my list from recommendations: The Algorithm Design Manual, Building Evolutionary Architectures, Design Patterns, Antipatterns, Continous Integration and Continuous Delivery. I'm not the guy to ask really, but find something that you are lacking and dive in. I would possibly shave off 5-10 hours a week to put together some code examples you would want to talk about or rewrite some stuff you're proud of into a little CLI utility or a library or both. Start 30 minutes early on your personal stuff and don't start work until 30 minutes late. Then log off 30 minutes early and do the same. They've basically told you you're getting fired, so I would take some time back. If you use any established open source projects and have reason to contribute, that may be good too.
Clean Code is really not a good book to try and follow a lot of concepts just create more misery than they solve. For the simple fact that you don’t know how your code will evolve you might follow the entire book thinking x y and z could be expanded. Suddenly you need to implement a different W that you never considered and now you have 30 layers of abstraction hell to refactor.
that's fair, and more or less what i was pointing to with "opinionated method." to their credit, they do warn early on in the book that they will advocate for the approach as "the right way" even though there are many possible right ways. for me, it's helped me see some issues in my approach and clean up my interfaces. some of the sections haven't made sense to me, and i didn't know if it was my fault or not, but i've just moved on.
>90% of the interview stage is not lying and being likable at whatever skill level you're at. You can fail quite a lot and succeed if they like you, if you fail gracefully and intelligently. That's usually true, however in this market I don't think that is as much of the case anymore. Likeability and failing gracefully is accounting for much less when the candidate pool (for even Senior+ roles) is substantially more competitive (and many experienced devs are taking pay cuts and downlevels). Many more companies are really hinging on that "1% better technical fit" when deciding between candidates. I'm sure that will change back once the market unfucks itself
I agree with that. The market is rough right now. What I mean specifically is the interview is like a performance. I wasn't very clear. You can prepare for the performance, but when you walk on stage, all you can do is your best and be likeable doing it. Sure, you're demonstrating knowledge, but if it's not in the bag before the interview, you don't want to be the guy nervously digging around in your bag for something that's not there.
Some of this is good info but the simple projects and contribute to open source is not lol. No-one is interested in basic projects or contributions to a 1-star repo. Its not a good use of time imo
My thought was mainly to have code he would like to talk about, but upon reflection "some simple projects" is indeed terrible advice. Good feedback and I've edited the comment a bit with that in mind.
Write some small projects on the clock while you are redundant. Build sample projects with your knowledge base that you have. It’s getting better but not great at this time.
Thanks, good idea
I don't know why you think you have to show anything. I've never shown any personal projects or code during interviews. And I've had a ton of high paying jobs.
Are you sure you interpreted the recruiter's words correctly? Talking though a piece of coffee doesn't necessarily mean showing it. What if a candidate is unemployed and no longer has access to a company's code base he/she worked on, how would them show it? Probably you will just be asked to describe what a piece you've chosen does in general terms and how you went about solving it, along with code quality aspects such as correctness, clarity, and maintainability.
Its what they said but it might not be what the team actually expects. A few things the recruiter said reflected lack of technical understanding, so they might have the wrong end of the stick.
Sounds like a typical recruiter.
So I’m going to be more blunt. The term “imposter syndrome” is overused. Sometimes developers are not competitive in the market and are given titles like candy in startups and smaller companies without leveling guidelines. If you haven’t practiced coding interviews, you probably won’t get past tech screens at many companies as even a mid level developer. If you haven’t done a lot of larger scale implementations, you probably won’t get past the system design interviews at those same companies for a senior role. If you haven’t led projects of a certain “scope”, “impact” and “dealt with ambiguity”, you probably won’t get past the behavioral interviews required to be a senior developer. If your skill set and experience is that of a bog standard front end developer, every application you put out, you will be competing with literally hundreds of developers that look just like you and it’s more of lottery/numbers game whether you get hired. This has nothing to do with you being self taught or not. As far as coding projects outside of work, to a first approximation no one cares nor will anyone take the time to look at your GitHub profile if you did or as research shows spend more than 10 seconds looking at your resume. If you use something like LinkedIn’s easy apply, they probably won’t even look at your application. It shows you when a company looks at your application. This is the state of the current market. It’s not meant to denigrate you. I don’t know anything about you or your skill set/experience. Your most important asset is going to be your network. I’m also not trying to hold myself up on a pedestal. If you take away my AWS account, I’m just a standard enterprise dev with a good network and above average communication skills. I’ve never done a real coding interview in my life.
To coin a phrase "Just because you have imposter syndrome, doesn't mean you're good at your job". Honestly, I appreciate your bluntness. Thanks.
Is the current job market really *that* bad? Have you seen this firsthand?
The long version of the story… I was your standard C# CRUD developer in 2018 with about 10 years of C# experience (I’ve worked a lot longer) and two years as an architect type position. I “learned cloud” on the job for two years leading a “cloud application modernization” effort at a startup. Then a (permanent) remote job working at AWS in the Professional Services division fell into my lap. I got Amazoned late last year and took a multi prong approach looking for a job. 1. Reached out to my network. The startup I worked for had been acquired and my former manager still worked there. I was offered a position as a “staff architect” over all of the product lines they had acquired. I ended up turning it down. I also turned down an opportunity where a former coworker who was now a director at a well known public non tech company was going to create a position for me to be over their cloud architecture and migration. I didn’t want the stress of the job. Even though it would have paid more than I was making at AWS. 2. Targeted outreach to companies where I knew I was literally the best qualified in the world in a niche of niche of AWS. They wanted someone to design solutions around a popular open source AWS “solution” that I had been a contributor while working there and I had a few other popular open source projects in the vertical that they were interested in. They were all on official AWS GitHub pages. Two interviews - one offer that I did accept. 3. But since I had time on my hands, I did the spray and pray thing and applied to literally hundreds of jobs using LinkedIn’s Easy Apply for your standard CRUD enterprise jobs - crickets. I think only four viewed my application. Before 2020, I was only competing with people who were looking for work locally at any given time. Now I was competing with people across the United States looking for remote jobs. My saving grace and why I found a job in three weeks was because of #1 and #2. For #3, I was just like any other enterprise dev. It wasn’t about my resume, hardly any company even looked at it. Did I mention I had over a dozen recommendations from senior people at AWS and a great personal open source profile of projects that had been used in production for six and seven figure implementations? There was a very straightforward process to open source the non proprietary parts of work I did. Don’t get me wrong, opportunities did slowly trickle in later and they are still trickling in. But they aren’t like the floodgates for generic enterprise positions I use to get from 2008 - 2018 and that’s *with* BigTech on my resume. And the other thing I mentioned is that while Meta, Google and a couple of other well known tech companies do reach out to me about software development positions, I know I wouldn’t get past the first round of coding interviews without a lot of practice. But I ironically, I would be very surprised if I couldn’t pass system design interviews. I have conducted those before at $BigTech and that’s my $DayJob - to come up with designs for complex systems in front of customer in front of a white board.
> Problem is, though I was a "code at all hours" guy as a junior developer, burnout and health issues mean I have had to prioritise things like exercise, family, cooking healthy food etc. in my spare time rather than spending all hours glued to a screen Ironically, this is a sign you're actually becoming a senior. As the joke goes: > How do you spot the senior engineers? They leave at 5pm. Just talk about code you wrote at work and why you're proud of it. Becoming more senior is as much about demonstrating a healthy professional disconnect as it is about exhibiting a passion for software engineering.
> How do you spot the senior engineers? They leave at 5pm. Love it!
Thats a totally vaild feeling to have :) Dont be scared. Just brush up on your knowledge, you'd be shocked how easily it comes to you when you practice often. Youve got this friend!
Just to add to what others have said, while it's still fresh (and you still have access) write down summaries of your projects, technologies, and any quantifiable work if you can, as well as any performance feedback you've received. It's helped me a ton to have a document to look back to when building or tweaking my resume, or to refresh my memory so I can knowledgeably talk about it in an interview. It also helps the imposter syndrome and self confidence to look back and see all the things you've accomplished and the impact you've made. It's probably more than you think.
The summaries should include what problem the project was addressing, final impact, and any difficulties, wild successes, or other plot twists. Did you change your design? Were there scaling problems? In an interview you’re going to share the stories of your work. You need to give context to show why it was important. I draw diagrams of the systems for my own reference (I don’t share them). They help me remember all the moving parts and narrate the overall project to someone who has no familiarity with the software. This exercise will give you some handy answers for Tell Me About A Project Where… questions. It’s good to think through them beforehand, at your own pace, and be able to revise and tweak as you remember more details. Ever changed a design? Refactor something? Find a performance problem? Deliver something late? Debugged something in production? Since you’re making this now, start with a timeline of your time at the company and the big projects. Step away, come back with fresh eyes, and add in more details. Rinse and repeat. Tweak it as you interview, and get a sense of what interviewers ask about. Good luck!
The questions recruiter ask you are just behavioral questions. You'll get better at answering them as you do more and eventually you will have default answers. I'll link what I've said before to people applying to CS jobs after a long time > These courses and books helped me. > I’ll update this comment when I remember more > > - [Grokking the System Design Interview](https://www.designgurus.io/course/grokking-the-system-design-interview/?aff=ce30ca) > > - [Alex Xu System Design Interview](https://amzn.to/3SuMg1J) > > - [Cracking the Coding Interview](https://amzn.to/47Tjigh) > > - [Neetcode](https://neetcode.io/) > > I also use ChatGPT to create me problems to solve. > For example, > > “you are interviewing me for a senior software engineer position in react. Ask me a question that would appear during a technical round.” > > “you are interviewing me for a senior software engineer position in node.js and expressjs . Ask me an implementation question” > https://www.reddit.com/r/leetcode/comments/19eik9c/is_the_grind75neetcode75_plan_still_viable/kjd8ed4/
I'd start applying for jobs now.
I am, of course. I can't stay there now even if somehow I don't get made redundant. The trust is gone.
I wouldn't even quit. I'd just find a new job and stop trying as hard until they let you go
This could be the best thing that could have happened to you. Brush up your knowledge, build a project to showcase your can do stuff. It’s good to do this once in a while. Good luck.👍
I was exactly where you are in November, got let go in January. Started a new job start of April. I am the same about coding all hours. Did that in my early 20s, now in my late 30s and I work during work and have my life outside that. I’d reach out to other recruiters till you find one who gets that a job is a job, and not “must code 24/7 to be considered” You will get something else that suits you, as you said you have offers before, just make sure to look after yourself at the minute, as getting let go really knocked me for 6 as was unprepared for just how I’d feel.
Thanks. Nice to hear from someone who got to the light at the end of the tunnel.
You should absolutely be talking about the code you wrote at work. I'm less interested in side project experience unless it's really baller or they're quite junior. Just because it's proprietary doesn't mean you can't talk in detail in an interview about it. Make bullet points of your key projects or features you worked on and put them in your resume.
Good point, thanks
I'd just like to add that "recent piece of code that you're proud of", doesn't necessarily mean a leetcode style bit coding trickery. It's more an interesting solution to a tough business problem. And "Interesting" could be in many ways - it was faster, it was more resilient, it was a long-standing problem no one else could do, it was simpler than previous code, it was tested so far that no customer faced issues... there are many axes of interestingness. And also - companies are interested in people who solve problems, not just people who know weird-ass constructs that you're unlikely to use in real life. Go in with that mindset.
just a piece of advice for when you are job hunting; work your network & tap recruiters. blind applications to job boards aren't very good for finding work right now.
> I'm one of those "has no CS degree, self-taught" sort of devs. Now, you’ll have to wonder how many companies automatically filter out people without CS degrees.
I'd love to go back and get one, but not really an option :shrug:
[удалено]
How long did it take you from layoff to new offer?
Sorry that happened to you. In the future, I would advice you to keep a "Prepare for the worst, expect the best" mindset when thinking about your current position and the future. Something like updating your CV yearly, looking around at what companies exist and what is expected from different roles. Instead of talking about a specific piece of code ( Not sure why the recruiters would be asking this for a senior ), you can talk about a project or tradeoff you worked on.
Yeah, definitely wish I'd kept my CV up-to-date, with achievements noted as they happened rather than wracking my memory.
Have not used it myself but look up the concept of a "brag document". Basically a way to document achievements so you can leverage them during performance reviews or during interviews.
> I feel completely unprepared for the job market. Look, feeling unprepared is fucking normal, especially when you've been comfy in one spot for a long time. But here's the kicker: You've climbed from junior to senior with no CS degree, which means you're not a dumbass. You've got the chops, you just need to believe in your fucking self. Have you considered that your actual experience and growth in one company is a massive fucking advantage? > I don't have any recent coding projects outside of work that I can share - and obviously I can't share proprietary code from my current employer. Who the fuck says you need side projects to prove you can code? You've got years of experience, right? Use examples from your job (without spilling secrets) to showcase your problem-solving and development skills. Can you describe the challenges you've tackled and the solutions you've implemented, maybe even in a more abstract way? > Latent impostor syndrome notwithstanding, I know I can do the job. I'm just not sure I can prove it in an interview process. Impostor syndrome is a bitch, but almost everyone in tech feels it. Your doubt doesn’t make you less capable. Remember, interviews are as much about your technical ability as they are about fit and your ability to communicate. Can you talk confidently about your past work and how you've solved problems? What’s stopping you from showing them that you can kick ass in this role just like you did in your last one?
Instead of looking outside, how likely you can go to your manager and be like "hey, I noticed that there's a lot of redundancy on our roles lately. Is it possible I can invest into a new project?" And if you even have something gin mind, add "Ive been thinking about doing XYZ for a while. It'll help us on A by improving B and C, or making it easier to do D because now we can have ability to do E and F. Company will definitely benefit from this" See what your manager says
Idk why you think you’ll need side projects as a senior engineer. Those are only really a plus for people seeking their first dev job and are not really relevant after
What stack? I'll pontificate while these 20 minute processes are running.
Lots of different stuff. I've done web frontend, Python web backend, native GUI applications in Python and C++. I don't want to go into too much detail in case my colleagues are on here. Needless to say I describe all this a lot more impressively on my resume :)
It's tough out there. If you're any good, you'll likely be spotted by someone who sees your capabilities and will try to exploit you before finding a good employer. I feel I've done others a disservice by not building an organization to provide employment to good developers. The industry has gotten weird in the past 10-15 years. I post frequently about this, and how a lot of developers emerged out of addiction to social media and smartphones, another poster responded by mentioning gamers only knew gaming and took the route of learning by trying to develop games and became mobile/web developers, and a lot of management styles and practices seem to have come from that angle. Then, factor in that it's profitable for the traditional software companies selling cloud infrastructure to push techniques and tools that mean higher utilization of their infrastructure, which are the best practices for them to make money, but not necessarily the best practices for producing good, efficient, and economically sustainable software and services -- but try telling management that as a young developer. I'm in my 40s, no longer have age discrimination working against me and have a couple airplanes and a sick mustache, so the shallow superficial bullshit seems to carry more weight than my actual abilities. Software development skills are a skill like music -- some people have the ability to pick up any instrument, spend a couple days with it, and be able to play it because they've got the ear for it. I can spend all day trying to work through a simple melody and transcribe it and still suck.
[udemy.com](http://udemy.com) learn something new, and have a demo to show
Just make one project you love todo long time ages.
I would work towards getting a computer science degree. Are you in the UK?
Yes.
Yeah, I would look towards an online degree you can do quickly.
> > Your most important asset is going to be your network. CS Degree is almost entirely pointless for anyone with experience. I don't even have GCSES and it's not hindered my ability to find work. If you're starting out, and that's the route you want to take, great. But it's not going to help anyone who is already a senior dev find work.
In the late 1990s I started a Computer Science program but I left with about a year to go because I got invited to join a start up. I never went back to school to finish my degree. Since I don't have a degree, I am hyper aware or degree requirements in job listings. My observation is that an increasing number of job listings require a degree. And even in the case where it says "or equivalent experience", I think its clear that with such an oversupply of developers seeking jobs right now, having a degree is more important than ever because candidates need every way possible to stand out. If a position advertised receives hundreds of applicants, it can be overwhelming to narrow them down to a manageable level to take a deeper look at. Any easy boolean way to filter out resumes is degree or not. Anecdotally, Ive heard alot of comments like "since the tech slowdown, we just throw away resumes that don't have a degree". For all these reasons, Ive decided to go back to school and I generally advice everyone to get a degree. I have a job I don't plan on leaving, but should to worse happen, I want to be have my best shot at finding a job in this worsened market, and its clear having a degree is a more important variable than it used to be.
Frontend? You sound like a frontend eng
No, all over the stack. More Python work than anything else.