ccajas

I'd rather see the increase of job security for developers that are lagging behind, and an increased quantity of accelerator and returnship programs for developers across all sorts of backgrounds and experiences, to get them out of stagnation.

I have worked for less than $25/hr at various web shop LLCs, less than what some tech internships pay. I'm also going through one of my longest unemployment periods ever. Yet, even I don't think unionizing tech jobs is going to prevent these sorts of situations for developers.

  Location: Chicago, IL
  Remote: Preferred
  Willing to relocate: Depends on the opportunity
  Technologies: PHP, Ruby on Rails, MVC frameworks, JavaScript, Node.js, C#/.NET, MySQL, SQLite, MongoDB
  Résumé/CV: Available upon request
  Email: chris.cajas.m at gmail
  LinkedIn: https://www.linkedin.com/in/ccajas/
  Github: https://github.com/ccajas/

I'm a software engineer with over 8 years of experience creating websites and web applications for many clients, and looking to go back to working full-time after taking a break from work. I also have around 5 years of experience working remotely (pre-COVID). Most of my work has been for small business clients, but I'm open to working at larger corporations as well.

It sounds like a sad story. PHP's specialization is in rendering dynamic web pages. It was its ONLY purpose (ignoring niche projects like GTK bindings, etc). And yet even against general purpose languages/VM's (where using it for backend web is a choice, not its only purpose), PHP could not remain competent in its own class.

It's like building a car designed for just one thing, to go very fast on straight roads, then a general-purpose car comes along and somehow beats this car in this category.

How did it lose its grip? Did the PHP Group become too complacent being at the top?

Re: getting your foot in with interviews. Mileage really varies here. I agree with you that getting an interview is very luck-based. I have no contacts in FAANG that would be strong referrals. But from my own experience, I garner more interest from recruiters passively from my job history, than from taking a more active route of applying to FAANG jobs. (And I have no history with any big or "corporate" work environments either)

There's a different "knowledge" problem that must be tackled here.

Someone can form a cognitive bias from only being exposed to a few ways to solve a problem. Maybe it's because they haven’t seen it to larger scale, or that they only worked with monoliths, and thus are limited to only that problem scope.

Throwing more MySQL databases at a problem won’t fix all problems, but for a lot of people, this is all they know. How do discover those unknown unknowns, to learn the applications of tools you haven't yet been made aware of?

They must be willing to eat their own dog food or else the question won't make any sense for the interview.

The department should run the interviews through their own employees first. If some questions cause an "interview anti-loop" (a set of other employees S who would not hire E) it's time to revise those questions.

Revise and rehearse these practice interviews within the department, and do it blind, until all of S are willing to "hire" each other for their respective roles.

>"Take home" questions are heavily biased in favor of the employer because they're not required to put anything on the line.

Not to mention it doesn't test the collaboration aspects of real work. Imagine doing your job but you're not allowed to talk to your teammates in case of a blocker. How are we doing our jobs here?

But when it comes down to actually starting them, I will always pass if they come before any interviewing round. You don't yet have a stake in the process.

> People easily identify that white-boarding interviews suck for more than just the interviewee. And yet any time a solution is proposed that involves doing something other than putting the candidate in a room in front of a whiteboard for an hour, it's shot down.

Most people take issue with the repetition of similar tests and evaluations for multiple companies. If A, B, and C were considered different stages of a technical interview, candidates are repeating A and B too often, whereas applying A and B once would suffice for several companies.

It's a problem that is realized when opportunity cost is compounded when interviewing multiple companies and it's not something that a single company alone can fix. A more "Docker-ish" solution where using one of "A" to lay the foundation for many company interviews (and not just the ones expecting you to practice Leetcode) might curtail the problem of using more time and resources than necessary.

But more than that, there is also a cognitive dissonance with the beliefs of how to reform a broken system. Programmers largely oppose industry-wide regulation while also expecting the vetting process to be more consistent and make more sense. This is a tough nut to crack because we seemingly want to have it both ways.

It's kind of a blessing in disguise that we live in the heaviest terrestrial planet in the solar system. It's like learning how to climb by starting with the most difficult mountain. You don't need as much energy to escape the gravity of the other planets and moons, and therefore can take less outlay of fuel with you for the return trip.