Yes, looking at big company interview processes, it can give you a huge unfair advantage if you can know what kinds of technical questions would be asked ahead of time. It's kind of ridiculous and counter-productive that employers are obsessed with selecting developers who can solve problems under time pressure.
The kind of developer who writes code quickly may also be the kind of developer who jumps to conclusions too quickly; this attitude is a huge problem in the medium and long term when working on any decent size project. Choosing sub-par solutions can trigger a cascade of negative consequences for the project over time. Often, it's better to have developers who are really thorough and don't move to the next stage until all reasonable possibilities have been considered.
The people who can solve problems quickly are often not the same people who can solve problems optimally.
The current system seems to favor fast-moving code monkeys with zero understanding of architecture or security.
not arguing this but, the assumption here is a certain kind of production web developer and similar things.. not all coder problems are hired this way.. unfortunately, ranks of new company leadership actually do not know themselves about this, dealing with money and personal power relationships daily.. so they copy others in the hiring practices and so do the personnel and low-level managers, who are vulnerable to termination themselves..
an industry expanding into distant lands with telecommute for ever faster results with ever cheaper workers, appears to be embracing the AI interview and AI CoPilot assistant standard, to further reduce the bargaining power and individual contributions of employees for writing ordinary code
What I find weird is that the kind of people that they're hiring are the kinds of people who are easier to replace with AI.
AI is useless at big-picture reasoning when coding. It's only good for short snippets. Yet companies seem to reject developers who are good at big-picture, architectural thinking.
And architects generally know where security gaps are likely to occur. If their livelihoods are threatened, it won't take long to find alternative funding for their skills.
>he kind of developer who writes code quickly may also be the kind of developer who jumps to conclusions too quickly
I'm the opposite of this, but when I wanted a really high paying job, I just practiced a bunch to code quickly. That was actually my biggest hurdle, sometimes I'd understand the problem but I couldn't bang out actual working code fast enough.
Other times I'd get so nervous that I wouldn't have time to code that I'd stumble on the thinking part. Once I deliberately practiced for speed, I was much calmer in interviews.
And now I have a really high paying job. shrug. Now, it's not the best at finding outright geniuses, but making people solve slightly harder than trivial coding questions is a pretty consistent filter for people who can't code.
If you're good at coding and you can't do it, then it's just a matter of practicing a bit.
Yes but what kinds of people have the time to practice puzzle solving? Not everyone. For example I've been coding for 10 years, I used to be good at solving puzzles under time constraints but I'm not as good at it anymore because I prioritized practical architecture and other code design skills. I'm a much better coder today by all relevant metrics. My problem is that I sometimes run out of time during the tech tests. It's arbitrary... Sometimes I get lucky with the questions sometimes not. An unfamiliar problem will take longer to solve.
The kind of developer who writes code quickly may also be the kind of developer who jumps to conclusions too quickly; this attitude is a huge problem in the medium and long term when working on any decent size project. Choosing sub-par solutions can trigger a cascade of negative consequences for the project over time. Often, it's better to have developers who are really thorough and don't move to the next stage until all reasonable possibilities have been considered.
The people who can solve problems quickly are often not the same people who can solve problems optimally.
The current system seems to favor fast-moving code monkeys with zero understanding of architecture or security.