This is a standard playbook at large organizations with finance departments. CFO 2 companies ago used to literally coach people on extending payments and delaying. Best case scenario for them, you never get aggressive enough to actually collect. Repeat that at scale across many vendors and suddenly their entire P&L looks substantially better.
Quite disagree. Early mistakes cost me a lot of heartache later on. But you don't have to figure anything out by yourself. People like us get hired because we're experts in software development; we can absorb requirements, understand the business, and apply technology to get an optimal outcome. There are professionals in the accounting and legal fields who specialize in things we don't have experience in and they are worth it.
Even just for personal life, having a little knowledge of law and tax is really helpful and helps not getting screwed by various actors (companies, landlords). Then yes, once the requirements are bigger and more money is involved, delegating is a good idea.
I'm not sure your conclusion is a fair take. In the app I work on, GIL acquisition would easily take 2-3x longer than the postgres queries which would subsequently be issued.
There are people who literally say this and then you hire them -- they turn out to be complete duds. I'm genuinely curious because I'm hiring right now: by what mechanism would I discover that you have these skillsets and are good at what you do?
I was somehow reminded of this guy who once wowed me in an interview by coding up a small graphics demo rather quickly. Turns out later that that was the exact one program he could code without being hand-held EVERY SINGLE MOMENT. I laugh whenever I remember that incident (from early on in my career, in my defense).
You have to build a repertoire of questions that defeat rote memorization, prove real experience, and show genuine ability to solve unseen problems...
There's an interesting bit in "surely you're joking, mr Feynmann" where he is amazed how primary school kids are learning physics. Only, as it turns out, nearly noone in the entire country has any actual understanding of physics, because from elementary school upwards all they do is memorize the material.
I've had a lot of success asking about fuckups, worst thing they've had to debug, and general "fuzzy" questions that specifically do not have a single answer, or the answer is so relatable/specific to a person's experience. Then you have to watch them as they answer.
What's so bad about getting a feel for someone and hiring them on a probationary basis? See how they go on discrete - but real - tasks for a week or two, and then make the call on going forward or not. It's how most hiring has always worked (and continues to work) in almost all other fields.
Also, re technical questions, I don't think anyone is saying that you can't ask any technical questions whatsoever, I think the concern is about giving people abstract, theoretical CS problems that will never actually come up on the job, on the very iffy assumption that their performance while being asked to dance for a committee in high-pressure job interview situation is going to be reflective of their actual skills. (And more broadly, that a good programmer must be quick on their feet with schoolboy-style CS puzzles that are basically irrelevant to most roles.)
I have no idea if this is accurate or not, but there is this general stigma from both sides that "no decent programmer worth hiring fulltime in hotter markets/companies would/should agree to a contract/temp/trial job".
I think de-facto fulltime jobs i've seen end up kind of like that - if you don't work out in X months, nobody will shed a tear about kicking you out - but this is still perceived as a more expensive operation that should be avoided by having a "proper" interview process. On which nobody can ever agree, but that's the sentiment.
IMO this is where a comprehensive System Design interview weeds out the hopeless. Minimum 2 hours, don't just use a "design facebook/twitter/insta" scenario because anyone can memorise those, dig into the weeds as and when it feels appropriate, and keep the candidate talking through trade offs, thought process etc so you can really peak inside their head. The catch is that you also need to be very competent and know the design and all permutations of it inside and out.
Leetcode et al. are just testing rote memory, there's no need to have candidates actually type out solutions its a waste of time. So long as they can articulate what solution they would use, why, and what other solutions they considered that's all you really need to be concerned with.
So to preface, I'm not looking for a job (trying to build my own company)
When I do interviews (probably limited compared to you but some) I do it like I wish someone would interview me.
I focused purely on curiosity. how many things disparate things are they interested in, the things that overlap with my knowledge I probe deep. I believe in Einsteins quote.
"I have no special talents. I am only passionately curious."
If someone knows about how RDMA and GPU MIGS work they are probably pretty damn interested in how HPC clusters function. More importantly can they compress this information and explain it so that a non technical person could understand?
There are so many endless number of questions I could ask someone to prob their knowledge of a technical field it kind of upsets me that most of the time people ask the most shallow of questions.
I believe this is because most people actually study their fields a very limited amount, because most people are honestly not truly interested in what they do.
The biggest implication of this is that I may be able to tell if someone has this trait but I understand that the majority of people could not as they literally don't know the things they could ask.
Asking system designs of me if you aren't knowledgable of the field would probably be the easiest to see the complexity of systems I can build.
It depends on the role. In web development, for example, there are lots of non technical things people can be good / great at that a coder might not be. Things like CSS, HTML, accessibility, semantics, things like that. Lots of JavaScript people have no idea how to leverage CSS and over engineer things or find it impossible to implement certain features or if they do, it's 1000s of lines of code when it's really just a few lines of CSS.
You can pay them to demonstrate it with a take-home problem. I'm not saying this is a great solution, I'm just saying at least you'll figure out what's wrong with your interview process once the indignity of paying an incompetent person sets in.
Chat gpt can solve any take home problem. You need to be on video making interactive feedback and demands to see that someone can actually write code and understands programming even a little bit.
I suspect that parent comment is not referring to the same kinds of people you are. I can relate because I know several people who flippantly dismissed family formation as not for them and now that it's too late they admit it consumes them like a fire on a daily basis.
Without removing the functionality as it currently exists, I don't see a way to prevent this attack. Seems like the only real way is to have the user not specify websites to scrape for info but to copy paste that content themselves where they at least stand a greater than zero percent chance of noticing a crafted prompt.
Writer.com could make this a lot less harmful by closing the exfiltration vulnerability it's using: they should disallow rendering of Markdown images, or, if they're allowed, make sure that they can only be rendered on domains directly controlled by Writer.com - so not a CSP header for *.cloudfront.net.
There's no current reliable solution to the threat of extra malicious instructions sneaking in via web page summarization etc, so the key thing is to limit the damage that those instructions can do - which means avoiding exposing harmful actions that the language model can carry out and cutting off exfiltration vectors.
Just prompt the user every time an image needs to be rendered and show the call details. The users will see the full url with all their text in it and they can report it.
This works for images and any other output call, like normal http REST calls.
I would think that a fairly reliable fix would be "only render markdown links that appear verbatim in the retrieved HTML", perhaps with an additional whitelist for known safe image hosts. The signifiant majority of legitimate images would meet one or both of these criteria, meaning the feature would be mostly unaffected.
This way, the maximum theoretical amount of information exfiltrated would be log2(number of images on page) bits, making it much less dangerous.
