I have an interview later this week. Hit me with some unusual non-technical interview questions, so that I've seen them and can prepare. ;)

"What is your greatest weakness" need not apply.

Work on projects where designs come reliably before development and nobody self-merges their work. Ahhh, agency work...

PSA: If you work on a project where code review is expected and there is a migrations framework set up for you, and you choose to self-merge/commit directly to master and update the prod database in the console instead of writing migrations, your coworkers hate you and you can eat shit. That is all.

OMG people please stop being so fucking lazy... help me help you... RN I have multiple support people asking me to fix a bug that they can't even describe (and honestly I doubt it exists) and a fellow developer who refuses to give me a DB or migration to test his patch but wants me to merge it urgently. FOH and die, y'all.

If I ever get the chance to start my own company or pick out the dev team I work with... I will never, ever, ever work with anyone who doesn't understand how to abstract out a problem. Our prod DB is a mess and our API is a mess because we left it to some dudes who are dumb as shit and doing everything ad-hoc. Now their ad-hoc shit doesn't work anymore and I get to clean it up. 😫😞FML

My most satisfying bug fix?

I found a core concurrency issue in this gnarly homegrown ORM and reported it to the lead devs, who (very defensively, having written the damn thing) argued that it would never pop up in a prod environment and I was stupid for even bringing it up. Theoretically, this bug could cause pretty much every foreign key to be assigned to the wrong parent, but only if multiple instances of the application were open/running at once. They were so certain it would never happen on live that they explicitly instructed me not to fix it. After all, this bug had been active for many years on a previous project and nobody complained.

Problem was, that previous project was something that only a single user had open most of the time (think: a manager). The new project was something that would be used by multiple people at the same time (think: all the employees). Once we released this new-project-with-old-orm, it didn't take long at all for our customers to start complaining.

After that, they let me fix the bug. :)

Trying to use a coworker's new API endpoint and I keep getting an "OAuth2 Bearer Token missing" error, despite triple-checking that I set the Authorization header correctly... finally dig into the source code and I find out that all their endpoints require that the bearer token be put into the request body. The fuck?

So we have this really annoying bug in our system that customers keep complaining about. I've explained in detail, multiple times, why the part they think is a bug is not a bug and the workaround they keep asking me to apply doesn't make sense, won't fix the issue, and won't even stick (the system will notice that the record they want me to delete has been removed and it will repopulate itself, by design).

I've told them what we need to do as an actual workaround (change a field on the record) and what we need to do to properly fix the bug (change the default value on the record and give proper controls to change this value through the UI). We've had this conversation at least three times now over a period of several months. There is a user story in the backlog to apply the actual fix, but it just keeps getting deprioritized because these people don't care about bug fixes, only new features, new projects, new new new, shiny shiny new.

Today another developer received yet another report of this bug, and offered the suggested workaround of deleting the record. The nontechnical manager pings everyone to let them know that the correct workaround is to delete the record and to thank the other developer for his amazing detective work. I ping the developer in a private channel to let him know why this workaround doesn't work, and he brushes it off, saying that it's not an issue in this case because nobody will ever try to access the record (which is what would trigger it being regenerated).

A couple hours later, we get a report from support that one of the deleted records has been regenerated, and people are complaining about it.

🙄🙄🙄🙄🙄🙄🙄🙄🙄🙄🙄

It's hotter than a donkey's balls in my house right now and I'm finding myself absolutely cranky at everything as a result. Time for some wine and bad Netflix, any suggestions?

This is why I use === everywhere...

So how do y'all respond to people on here who take obvious jokes seriously? It seems like there's a couple people on here who wanna win a coding debate so bad that they don't even read your comment to see if you're trying to debate them. Awkward... 😳

Really loving the instant legacy code being added to our new project by devs who think they are too good to follow our peer review process, yum... today I found out that there are two different implementations of an API endpoint that does the same thing running in prod, in two different places, because the guy who wrote the second one wasn't aware that the first one existed and didn't let a second developer look at it before he pushed it to master.

I'm pretty sure my clients would fail the marshmallow test 9/10 times if not 10/10 times. We have a certain time period of the day set aside for me to look into new reported bugs but besides that I'm supposed to work on regular tasks. Of course, they ask me five hours after that time period is done, whether I can look into a new (non-urgent) bug. At the cost of the new thing they want to launch in 2 weeks. 🤔 I would love it if we actually had time to fix every single bug in the codebase but what typically happens is I get about 15 bug reports (most duplicates) and I'm expected to fix all of them in a span of 2 hours.

Don't rebase and force-push a shared feature branch that's still in active development. FFS. A "senior" developer should know better.