:) this took a bit of thought to get the right words..
I am ALL for this, for a number of reasons:
- will help people 'find the words'
- it's pretty easy to spot someone who doesn't actually know what they are talking about, even if what they are saying is correct and valid
- actual technical capability is only a small part of the job.
:D so, 'find the words', interviews can be stressful as all hell for both sides, as someone who assumes the power of the interviewer that's a heavy stick to wield over someone who is trying to explain why they very much want to be paid by you. Communication is _hard_, even if you gel with someone, actually explaining something to them in a way that both people completely grok can be really hard.
If someone joined and front and centre said 'I'm using AI to help me with my answers because I find interviews hard' I'd sit up straight and be all 'cool! lets do this!'
'Are you sure about that? what did it feel like?', ok so this one is VERY subjective but it's a pretty solid baseline to go on.
Interviews should be a verification that they actually are interested in working with you and that you are interested in working with them.
So to be able to make that judgement you and they have to get to a point where the interview can be concluded, and whilst there's a fair chunk of other stuff to go through, technical understanding is important.
To be clear, lack of it is fine, that's why different levels exist, you want to be a software engineer but you have no experience or skill? Well ok but you will be starting at the bottom.
Now to that, there will sometimes be people who want to 'show a higher level of capability than they have current attained' and that's what my job is, to try and see that when it happens.
It's pretty easy to do to be fair, humans experience deeply, computers do not. So if I want to talk about Entity Framework Linq helpers then I'll be looking for the spark of excitement when it suddenly pinged to them that this is WAY easier! And pretty! It makes the queries dance!
..and yes, that's my experience, but it doesn't take much to guide people on sharing their excitement in this stuff, and frankly if you get to the end of the interview and _haven't_ found that excitement or deep interest then skill level aside, you've probably already got your answer.
Finally is around how relevant is a specific level of technical capability?
As I said, that's what we have graded levels for (junior, senior etc), and besides this whole bag (for me at least) is much more about how you solve problems than what you specifically know.
I've seen people wildly switch careers into software and sure, there's a lot of hand-holding and stuff early on cos it's a proper throw into the deep end, but it's the mind, not the current capability.
> I worked with a developer who would send screenshots of a text error rather than just copy and paste it..
I've worked with one like that. I got fed up so I just took to walking back to my desk and telling them to google it to see what the general consensus is, when they can tell me more about it I'll come back. Did that enough times till they got 'used' to not being lazy and at least tried to understand the issue before yelling for help.
Was harsh at the time but they knew they were being lazy and as devs we are paid to find solutions. I think that's the critical thing in this, we're not only incentivised into naturally and habitually finding solutions to things, but also we are failing when we don't. We're failing for our expectation of our own analytical capability. Also we work with devs, or dev-like people so we get used to talking to people who will either keep up with us when we're rattling down a rabbit hole of thinking, but sometimes will gleefully join us in it to try to find the solutions.
I think that's the crucial thing here. We're applying our expectations of ourselves/peers into personality traits that find solution finding completely alien, who not only don't think 'this is for me to understand', don't even approach the thought that they can potentially do something to fix it, even at a very small level.
The things we do everyday as easily as breathing, to a lot of people is magic, and that's really not a good thing (“Any sufficiently advanced technology is indistinguishable from magic.”).
I'd suggest thinking about this a little deeper... What department would you complain to.
'Human Resources'...
Trying to not sound like I shout at clouds, but we do live in an age where a job (which is a social collective of people that all strive for a common goal) is still using viewpoints where the people that make up a organisation are a literal commodity, treated as such with processes and guarding around doing the best thing for the organisation with the person held second.
It's 'just how it is'. I would say it's getting better, however it's not Starfleet.
Given that, this is an unfortunate series of events. The 'business' won't 'care', yeah sure the people who made the decision here may not feel great about this timing, but the business won't care, and at best will likely be utterly unaffected by it.
:) do remember though that the 'business' is a collective deliberate hallucination, and the excuses that people give for these things are only excused when people within that shared environment allow it, and clearly where you are this is allowed so poke the bear with caution.
Either swallow it, get out or actively try and show how this could have been done differently.
When you make a 'prototype' spend more time filling in the gaps and making it halfway production ready (decoupling, documentation, nice-naming etc). Assume ti's going to be reviewed by a psycho. That way if it suddenly becomes flavour of the month and someone says the fatal line of 'wow! that looks awesome! Let's look to getting that spun up on the cloud layer!' you can breathe a quiet sigh of relief and know that most of the hard refactor is already done. Also your colleagues will buy doughnuts when you tell them you did this.
If you're asked to estimate a task in real terms (days/hours/minutes) and not rough estimates, over estimate ALWAYS. It suggests that the technical understanding isn't there for the project planning so when things go wrong and you say you need more time you'll find real friction.
Similarly if you are estimating in rough times or even better Fibonacci scales then you are likely to be in an environment that will accept delay because of unexpected findings... CHECK THIS THOUGH, if you don't want to ask, ask or listen out for what happens when something goes wrong and timescales slip, cos they will.
Make friends with people that you enjoy spending time with, but if you are working on something complicated, try and find a coding buddy who doesn't think like you (as long as there isn't actual tension). Threshing out ideas with someone 90 degrees to your perspective can lift weird and wonderful rocks.
Never trust your instinct, but listen to it ALL the time. Remember correlation is not causation but something is making you think you should look. The more you look the more you'll feel an understanding for something so follow your instinct, but learn on your own terms.
Many things never get renamed when they should do, so just because something seems sensibly named and it's behaviours are beautifully documented, don't entirely believe it until you've passingly proved it.
Any business that isn't honest about wanting to earn money off your work is lying to you and sometimes worse, themselves. Those that are honest about this are (in my experience) easier to work for, as your expectations on what you need to deliver are so much more obvious (money for the business) rather than some fluffy nonsensical indefinite esoteric concept.
oh and as for advice on good/bad coding behaviours, I'll be honest that should be described for you by the coding standards for that piece of work, or project, or entire company.
If it isn't then that smells in it's own right and for your own sanity go looking for a coding standard to hold yourself to.
If anything this just gives me more reasons to seriously look at linux phone options.