:) 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.
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.
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.
tl:dr; turn off the notifications and proritise your workload so you know that the stuff you are clearing is the important stuff first, tell the company you are doing this to focus on your backlog.
This is going to come across as arrogant, and in a way it is, but in a healthy way.
If your tickets are piling up then you /need/ to ignore distractions. Someone then tries to track you down so you lead with 'is it on fire?' and when it is, ok that does rank highly, but when it's not 'sorry, I've got so much backlog I need to focus on right now, email me and I'll look at it as soon as I can, but fair warning, it might take a while' is not only ok, it's absolutely critical. In a very strange turn of events you'll likely see that somehow these critical problems are being solved at the source.... ;)
This also means that the workload you have and therefore the time you allocate to spending doing it has to be priority driven. Start with the flames and work back to the embers.
Finally, just to reinforce the main point here, if the tooling you've been provided with isn't enabling you to do your job well, then find how it will and tell the company what you plan to do to ensure productivity.
:) remember, they hired you to make them money, if you find a better way of making money faster and for longer only an idiot will find fault with that. This is how good ways of working evolve in environments.
Personally I've never needed to unpick a full blown standalone app like Chromium before, I'll be using repo code or dropped into some hulking spaghetti massive legacy app that needs a bugfix, but there's no-one left at the company that has any idea how it works and the documentation is _lacking_.. but if this helps then good, otherwise, oops, sorry for the pollute.
Breakpoint methodology wins for me simple and true.
I imagine it like pathfinding the minotaurs maze, you stand at the last place you recognise and can get back to (if that's literally the first active line then that's fine), and put something there (breakpoint, print statement, log line), run it and check you still know where you are.
Then put another down as far forward from that point that you can 'see', if that's literally one operation step then fine, spin it and check. Breakpoints are easily put down and just as easily cleared back up again. Keep only as many as you need to see which branch you are on.
Pretty soon you'll have run the damn thing so many of times you'll know it's bootstrapping and foibles and they will be second nature. You'll start seeing how it's generally laid out, you'll know where the main start up branchings are. When they leap into async or hidden 'rooms', log lines are perfect.
When the engine of it starts moving in your head, then is the time to start throwing breakpoints, prints or log lines in places that originally were completely unknown but now you have a feeling for. It's at this point you'll be bloody close to where you want to be.
Oh and do future you a favour, at least jot down something as you're going through this.
I find that this initial torchlighting is remarkably gratifying but if you don't make notes in six months time it'll be completely gone, and you'll have to do between a quarter
to a half of this all over again before the lights start lighting on and you remember how it's laid out.
Learn what you want to learn, and be honest about it. It doesn't sound like you're looking to learn Linux because you want to but feel like you ought to. Well that's not going to inspire you at all! Park that for later, Linux will wait for you.
One thing I will say as someone who habitually has broken install after install learning OS's, Applications, toolchains and the rest of it, keep the important stuff away from the OS, even if it's only backups.
What I mean about that is assume today is the day that you realise that you have to wipe the disks and install your OS from fresh, so that being the case make sure you can get back to work quickly and without massive pain.
If you do that you'll find that your a hell of a lot more comfortable with 'hmn, haven't seen that big red button before, what does that do?' and subsequently nuke the whole OS. That's not a bad thing, that's investigation, analysis and good old fashioned curiosity.
Final thought.... You'd be suprised at what your machine can do. Ok, so right now VM's are off the table, but I'd wager that future you will have a different perspective. I'm not saying 'guh, go do VM, you must learny the machines that is virtual', I'm saying learn at your own pace, go git gud just by doing and see how it all looks afterwards.
..also, break shit, but break shit in an environment where you can laugh about it, not cry.
If anything this just gives me more reasons to seriously look at linux phone options.