There is no talent shortage except for corporations favoring low effort hiring using low effort puzzles. They see people as cheap so why bother investing in hir

There is no talent shortage except for corporations favoring low effort hiring using low effort puzzles. They see people as cheap so why bother investing in hiring. One person is as good as another, right? That first question in the paper is an indicator that I literally don't want to work there. Their culture is probably toxic, full of bro coders and likely infested with poor time management and politics. That's my rule of thumb and I'm sharp and harsh since I've seen enough to make this assertion and won't even negotiate on it. The reason they showed me a puzzle is they want interviewing cheap. But I'm not cheap. And I'll see right through it and just see a messy company. No thanks. I have too much experience with messy companies and can spot them from a single question. I'd rather work with professionals with real problems and no time for nonsense. Google etc can't hire someone like me because I interpret stupid puzzles as an indicator of poor work environment. I don't write this out of some sense of superiority: I'm just tired of the correlation between puzzles and environments that are just plain bad. The mentality of people who like pointless puzzles is not one I'd like to work with. The irony of my job being based around production issues that involve uncertainty and require novel solutions is not lost. I work with smart people. Do people on the outside really think we would play with wooden or toy puzzles because we"re "technical?" None of us do. I get my contracts through referrals so interviews are mostly now just "hey are you available in a months time and can you also do X" followed by "do you have a github for this kind of work?" Then a quick 15-30 minute interview with no idiot puzzles. Mostly to expand on experience to explore some portfolio piece. Big corporations can't do this kind of interview. Their hiring is broken. That is why they have thousands of candidates and still shout about talent shortages. I've been interviewed a few times and I usually get to a point where I say "sorry but I'm not happy with the environment you are presenting" then I politely cancel. I can't be alone in this experience. I'm a blip in their radar that rapidly fades away. They probably see me as poor fit. Good. Lower your tolerance. Raise your expectations and actually judge them back. They are presenting their corporation in the best light possible. So using puzzles is their best light. Ouch. Any code or project example that an interviewer presents to you are demonstrations of how their best practice development process works. Best or worse or an examination or discussion of why not either way. Evaluate them. If its "from scratch" then they simply do not use libraries and suffer from "not invented here". If its not commented, they hate maintaining code and they want you to fix their mess. Is the time limit too short by your experience? Then they expect miracles and likely won't pay for it either. What about a 8 hour home project as part of the pre-interview that you could probably sell? They expect free labor and no compensation for it. These are assumptions but when firmly applied your opinion will be suitably sharp enough that puzzles no longer seem so reasonable. Judge the interviewer on what they present. That code will be production ready or they will ask why it isn't. Each question is an example of how they specify real problems. Judge them on their method. Is there enough information? Why not? How is that acceptable? The interview process is two way. Anyone who says otherwise is someone you want to avoid. They are likely toxic. Don't work with or for anyone who thinks interviews are one way. If the process is not win-win then avoid because other nasty surprises are hiding in your near future. My personal experience shows genuine horrors await if you stay. Why is that particular technical question so bad? Because it shows the answer will not be production ready and the culture around it accepts that. The design specification is indicative of bad design. They even showed the shape of their preferred answer. Consider the implications: what was missing from the question? Why would I care about what was missing? What is the maximum run of numbers it can search? A million numbers? How often does this code run? Is it part of an interactive flow? I hope the user has coffee and a lot of patience. When does it time out? No answer in the design. It never does because it is not specified. The interviewer likely won't even answer that question. No context and you now seen as incompetent for asking. Instead you can ramp up the assumptions: So the entire system hangs as it searches. You could also say that the company is likely bad at operations and they don't specify their problems clearly or thoroughly enough. They have multiple mysteries in their systems they just can't solve. Systems fail for no reason and asking why is "being difficult". What a painful place to work. No thanks. I can make these assumptions because the question they showed me is seen by me through the lens of a production example. An example of a problem I'd likely see if I accept their contract. This is an inter-view. Two views. I expect them to show me a serious example of how they would frame a problem and how they would specify the preferred shape of a solution. They didn't show me a toy problem because they wouldn't want a toy solution. That would be disrespectful: so what was presented is a serious question to be solved. It is to act as a demonstration of what I would be presented with and then they want to see how I'd meet and solve it. Now look at the question again. Its so simple. Just answer it. Ignore everything. It will be fine. Now clean up our codebase. Have fun with all those puzzles. We need it fixed in 30 minutes, all 200000 lines. Oh well. Back to work. I've got money to make and this system is 1.5ms too slow, and that is costing the business 100k per month in lost opportunity. How would I solve this? Perhaps a bubblesort algorithm I saw in an interview question awhile ago might help? Thats fast and best practice isnt it? Perhaps I could write it from scratch... on a whiteboard. With only 5 minutes. Sounds great doesn't it? Should a company bet their livelihood on that kind of decision making? Interview carefully. You could end up working with these people.