What websites/applications have you made? What can you make/do? Employers care much more about that then whats on your resume.

You said your CS degree is post-bachelor, what does that mean? What is the second degree in and long will the 8 courses take to complete? Definitely overkill but if you’re set on funds and you want to do it, sure. I can’t say whether or not a 2nd (or 3rd?) degree will help differentiate you, others can chime in.

Also everyone is an impostor when they first start, so just put that out of your mind. No one hires fresh grads for what they know, only how they think.

Why not get the diploma, get a job, and let your new employer pay for the rest of your degree?

I would only consider taking more math courses if you want to focus on data science. From what I've read, that career path is crazy competitive so much so that I don't think you would even be considered as a candidate without a minimum of a PHD.

There's going to be very little benefit in getting the degree. Financially you'll likely be better off getting into the job market sooner.

Everyone has impostor syndrome to some degree. A degree won't help. You'll face it over and over every time you encounter something new or something is difficult to understand. Better to just accept that you'll be constantly challenged and get in the game.

Having a degree shows you can start what you finish. You already have that. I'd go for the job now.

Yep.

I got my first web dev job by teaching myself react and building some stuff with it after I completed a boot camp.

My lead was a community college dropout and she was absolutely brilliant.

My web dev career started with a trip to the bar at the Elbo Room in SF. I nodded at the dude waiting next to me. W/o saying a word he flashed me his business card.

Me: "Oh you're a web designer? I'm a web developer." I didn't even know HTML was files. I thought it was just magic pipes or something.

That led to me building a 6000 product e-commerce site from scratch in Perl, and 10-years of side income maintaining it. The first pass was the worst spaghetti code you ever saw. But it worked.

Oh yeah - the database? A tab-delimited text file they generated from Excel and uploaded. No caching. 100% stateless server before it was cool. Perl scanned it for every search, TOC and product display - and it was still lightning fast.

Thanks very much for all the replies, guys. This has set my mind at ease.

Aside from course projects, I've done a couple small Django projects on my own. Nothing impressive, but they were good learning experiences and I am continuously learning new stuff in my free time. Currently improving my JS skills and planning to learn a framework (React or Vue) because when I was searching for my last internship I realized that this is what most employers want. I'm taking a light-ish course load for the next couple of semesters so that I can show off some more elaborate web-dev projects when I'm looking for my first real job.

My current program is a CS diploma (a 2-year program) that is reserved for people who already hold a BA/BSc in some other discipline (which I do). It's like an expedited CS degree with all of the same core courses, and without some of the non-essential, non-practical courses. The extra 8 courses would get me a BSc in CS, and would take me roughly 1 additional year to complete.

that's because perl is awesome. I'm working at at fortune 500 now but still use it every chance I get here.

I used perl on my first projects and used flat files to store everything as well. I remember when mysql showed up and thinking where the **** has this been my whole life.

also, I'm on team suzzer as far as meeting software. We have skype here and it's a festering ball of ****. Tons of time wasted trying to get meetings to get going.

Going to be at AWS summit tomorrow in Anaheim if anyone else is going. Registration is free and still open.

I must be a genius then as I dropped out of state college.

I'll be there with my new coworkers. I'll PM you my phone number.

Nobody thinks video conferencing is great everywhere. Team Suzzer is thinking it’s ****ty everywhere. That’s a big difference.

I'm +1 on team Suzzer. The amount of time wasted trying to get meetings started if we were to add it up company wide in the past year would likely amount to a few days. It really is that bad. I think you guys that work at places that have it figured out are really in the minority.

Would someone be kind enough to explain how QA/tester works as a career?

My knowledge of tests are tdd/bdd and unit tests/integration tests.

QA/testers are considered to be lower on the totem pole than the people who write the code?

Why didn't the people writing the code write tests themselves?

Don't you have to understand the goals of the code to write good tests?

QA leads should be embedded in all requirements meetings from day 1. In our case they often knew the requirements better than the developers. We leaned on them to find all our weird edge cases so we didn't have to think about everything. We could develop fast and loose knowing they'd catch anything that slipped through the cracks.

Also in our case it took forever to do stuff like creating or modifying test users, clicking through long flows to get to certain scenarios, finding pieces of content with some weird rare attribute, etc. That stuff was a gigantic time sink (10 year old monster website - integrated with dozens of back-end systems we don't control). So it worked out better for them to do it.

Obviously this is all pre-automation. The goal was to get automated and wean off SQA. But of course how do you get to full automation of test users when everything is integrated with a user system you have no control over - while maintaining a monster site with your budget constantly slashed? You don't. But your bosses like to spin powerpoint fantasies to their bosses.

Also they're not really lower on the totem pole - and they get time and a half overtime in California. So in crunch time they made tons more than me.

Ya, agree with suzzer on the responsibilities of a QA role. Wanted to add that not all tests are automated.

Have to push back against this part:

Explain this in more detail. I haven't lived in CA, but I have lived in many other states and overtime pay has always been 1.5x for hourly folk that work >40 hours in a work week. My dad even got 2x pay if he worked Sundays (praise jebus)! Even if they edge your salary out over a short period during crunch time, you crush them all other times because the pay range for QA/tester is generally much lower than software developer or engineer.

It does seem like a decent way to get into tech or a launching pad to those higher paying roles though.

I can give you an idea of where a QA person would reside in the workflow at my company. Some members of dev (backend) team claim they have tests in place. That's certainly questionable based on what I've seen. My team has said they wanted to write tests. I created a test framework over a year ago that just needed people to start writing tests. Nobody ever did. We are now working in Vue and again "they" (meaning the members in my team that say they want to write tests but didn't before) say they want to write tests again (still have yet to write even one).

Given all of that, how do you fit in? You could say we have 3 distinct workflows.
1) Dev escalation workflow
2) Regression testing workflow (moving legacy code into Vue for example)
3) New feature workflow

Dev escalation workflow is as follows:

Someone, whether it be a customer or an internal employee, creates an escalation (a bug). They list details about how to recreate it, the url, etc. Depending on whether it is UI related (faulty UI logic) or data related (corrupted, incomplete, or invalid data), it then gets assigned out to a member of my team (UI) or dev team (backend team). They work on it, fix the issue, then assign it out to the person who originally created the task and someone in QA. A stage branch is created so QA/original escalator can test to see if the change fixed their issue. If its fixed its included in the next production push. If it's not, rinse and repeat.

Regression testing really just makes sure that everything is functioning as it currently does when moving code into new world (vue). The ironic part that is often overlooked in this process is that the way some stuff currently works is so ****ing stupid yet, instead of fixing it, they want to keep the same ******ed workflow. This should very clearly be covered by actual tests not some monkey in a desk randomly clicking through the UI but there you go. I argued with my team today to get them to actually validate input before they passed it off to our api. Naturally, they refused. Why make sure input is valid when someone else [dev team] (might) validate it for us!

New feature is basically the same as a dev escalation except its testing a new feature instead of making sure a bug is resolved.

In the end, I think a company will likely only have QA roles when there is little (or none) automated testing. And that is a really ****ty position to be in when no one can even be sure that their updates actually had the desired effect.

At my company we write our own unit tests.

The QA role definitely has less perceived prestige than development. I think that is because the skill-floor is lower.

We have QAs in my company that don't have a CS background and have never developed software. They are basically expert users of our systems and have enough training to use dev tools like sql explorer to view the db, log trackers etc.

Then you have the power-QAs, which is now fashonable to call software reliability engineers. Those are the people that could be devs but chose a different path.

Still, a good QA, regardless of background, is worth their weight in gold. They have a different mindset than the developer and approach the software in another way.

QA manually test the app or software with real or test data.

STE write automates tests that test the app with a framework and code.

For us at least.

Our QA guy is also our infra guy and he maintains our whole jenkins server. But we all write tests/automation scripts.

I go in there occasionally and wreak havoc, this week I found out one of our old automation scripts has been silently failing for like two weeks. That was fun.

Right - they get 1.5x for every hour worked over 40. I get zero, since I'm a "professional".

They also made about 80% of what we do. And we had a lot of crunch time

Yeah sometimes it means a lot to have a tester that's not embedded in the code.

The developer often has a specific set of use cases in their mind, since they just developed against them. So they only smoke test exactly those. Whereas a user with a different mindset will come at it a different way and find new edge cases.

At one company we'd have devs act as QA for other devs for this reason. Not sure if this is standard.

Bingo!