However, from my experience, this is not a popular opinion among developers.
Turnover is a reality that can't be ignored. New people come in and now have to figure out something that reads like a stream of conscience. It isn't well documented, doesn't follow the latest best practices and doesn't support modern paradigms and uses outdated frameworks/libs, but works great.
The apps I build always take into consideration the talent pool my employer intends to pull from. The reality is that they (usually) can't hire general "technologists" that are proficient at all layers of the stack. If the project is something that only you will ever work on, then you can do whatever you want and this whole conversation is moot.
More silliness. Pay developers enough so that they'll stick around. If they stick around, then you don't need to hire for talent in a particular framework or language. You can hire for intelligence, creativity, passion, drive, whatever... and invest in training people when they get there.
Jumping from framework to framework and language to language as the talent pool does is incredibly wasteful.
It's amazing FANG companies have any turnover based on that logic. Turnover happens for a variety of reasons... like global pandemics... you can't make a blanket statement like that and expect to be taken seriously.
In JS land there’s a ton of churn though for sure if that’s what you were thinking about. Not all of it though.
The point I am making is, using the current {shiny} tools might not be the correct answer (it could be though depending on the use case). Just use whatever gets the job done faster and then iterate. Some developers will start solutionising based on technology instead of focusing what is the purpose of the system and how it will help users. AKA: CV driven development :)
It's like you're aware of the issue (sales doesn't give two shits about the capacity of the engineering team) but you want someone that is good at wasting a lot of time efficiently instead of improving communication with the sales team.
If all your hypotheticals revolve around cleaning up the mess of flagrantly incompetent coworkers/leadership I'm going to get the impression that that's what I'm expected to do all the time. You could get the same information with different hypotheticals, so there's no point in making your company sound like a horrible place to work.
Happily, we would come to a mutual decision that I should produce profits for someone else. It sounds like you're one of those managers who wants supplicants, not applicants. Good luck with that.
It sounds like you're one of those managers who wants supplicants, not applicants.
Absolutely not. I want human beings with whom I can have a good relationship with, based in communication. I definitely don't want to hire a robot who is making important assumptions based on questionable (and totally wrong) heuristics, and Not bothering to ask simple questions.
So yeah, someone applying a weird algorithm to the questions I'm asking them isn't going to be a good fit.
That question translates to me as "your sister teams/leadership/communication infrastructure are completely incompetent/lacking and you're on the spot to pull an 18 hour shift to clean up their mess. What do you do?"
Sure occasional unforeseen emergencies/breakdowns in communication are expected even at the best of companies, but I'd replace it with a hypothetical that makes the company sound fundamentally competent. Perhaps something like "The company has promised the customer a To-Do List App, however automated testing failed to catch a mission-critical edge-case. This comes to light the day before it's supposed to be delivered. The flaw is so fundamental that the app will have to be re-written. Everyone else is handling other parts of the delivery, so you're on the spot to do it on your own. The only thing that matters is that it's done fast. What do you use?"
IMO your counterexample is wildly implausible, and is likely to sidetrack the candidate. "Is nothing salvageable? What was the flaw? What automated testing? Do I have to use that testing in my alternative fix? How does that reflect on the rest of my tech stack choice?"
Perhaps a more innocent miscommunication like the customer failed to clearly communicate requirements, and it was just discovered in an email conversation that they were expecting and as-of-yet un-implemented To-Do List App in the current release, which is shipping tomorrow/this week/etc. I've experienced situations like that before, not sure how applicable it is to your business.
My original example is born of a decade of cynicism, and you're right that it could reflect poorly on the company. Thank you for the feedback, though in fact I'm happily unemployed right now.
It would make no sense for an interviewer to provide meaningless context unless they were deliberately attempting to distract from the the question, or are otherwise simply incompetent/unfocused. I don't see how gas-lighting candidates would be a productive mode of interview, particularly given that each party only has the interview from which to judge each others' character. Even if the candidate were to successfully discern the gas-lighting, all it would do is prevent trust from being formed. At that point every interaction would be subject to question.
So with the assumption that gas-lighting is not the intent and that the hiring party is competent, the question is how is the context meant to inform the response?
Given that the interviewer is gauging the candidate's ability to perform a job, it is sensible to assume that realistic-sounding context applied to a question is meant to see how the candidate would perform in what the interviewer deems a "realistic" scenario.
If the scenario is unrealistic but meant to impart other information, then it should be obvious or stated as such, so that the candidate can attempt to parse to the correct information from the scenario to inform their response.
If the point is merely to motivate the candidate to answer the question by placing themselves in a narrative, I'd argue they should be motivated enough by the fact that they're in a job interview, without the need for unrealistic scenarios. If they aren't then they clearly aren't taking the position seriously or likely have other issues that would impact their job performance even if hired.
Take the hypothetical removed from context: "You have make a deployable to-do list app as quickly as possible, speed and basic functionality are the only priorities. What tools do you use?..." That format accomplishes the same goal of revealing the candidate's knowledge of what a quick/dirty workflow looks like. The followup questions mentioned "what problems to you anticipate when scaling the solution? How would you on-board coworkers? How would you shift from rapid development to ongoing maintenance? etc" would then flesh out the candidate's knowledge equally as well.
Good point I think
Yet if I go back to my non-management dev friends and talk about this, they are all like “eeeew, what about X and Y” and I’m just like, but neither the citizens or my IT operations staff gives two shits about any of that.
I’m not going to say what is right technically, because I’m not qualified to do that, but I do know what will happen as it’s my decision, and we’ll be slowly moving all our customs forms to a PHP CMS system and we’re just going to shoot the docket container it comes in directly out into our internal Azure cloud with public access through our national identity system (NemID). My developers aren’t going to be out of work either, but instead of making the same form with small differences 9000 times, they will be building Drupal modules with actual challenges.
That's exactly what I meant. I remember arguing with a colleague who over-engineered a simple ORM table by having 3 classes. One was just an empty class, the other was an empty interface, and the third was the actual class. When I asked why did you make it this way? He said: "What if we decided to use Mongo later?
Technically he was right but practically, he was wrong! I saw this overthinking and over-engineering pattern across many in-house dev teams. But this is just my experience, and I'm not judging what is right and wrong from devs point of view. Every decision has its context, but I saw how these complications affecting the delivery and customer experience badly.
I mean, it's just fun. Developers are biased to do things that make work interesting, even if it's superfluous. We think that coming up with a better framework or tool will save time in the future. I think that often it's just a wash or a net negative since you now have to maintain this tool AND when you first start on creating it, you are sort of naive about what it needs to support, so you open yourself up to a lot of hurt later when clients of your tool come up with more requirements than you envisioned.
Standards matter if you want to show your code to someone else