That's either a fun or terrible exercise depending on who is administering and how. However, if you said it's a Ruby role and the candidate is good enough to be picky, you may scare them off when they think your description of the role was a lie.
I recently used ChatGPT canvas to improve a friend's resume. I had managed him in the past, and he is great to work with. However, from his resume you would never know it. I did 3 hours worth of editing and improvement in 5 minutes. I gave rambling descriptions of what he had done when working for me and why it was impressive, and GPT translated this into resume speak almost instantly. I then gave some vague suggestions for improvement, made a couple minor edits to buff off the AI veneer, and viola, he had a professional resume that will help him do great work in his next position.
Seriously, a use case where LLMs really shine: bullshit padding. It's quite amazing to be able to turn ramble into coherent text. The less obvious tax is that if you don't put effort you will never be able to learn how to write and that will most likely affect thinking too. Writing will remain a valuable tool for improving thinking though, but likely for a lot fewer people.
I suspect we'll start to see people asking for more raw bullet-points for certain communications, because all the text they used to use to guess engagement/thought/investment/care is debased from easy counterfeiting.
In some cases that'll remove something that was always a questionable waste of time, and in other cases it'll represent a real loss of information.
Did you consider that the AI screeners would have liked the AI veneer? That CV will be "read" more times by a machine than it will be by humans. Someone should publish an RFC for a machine-to-machine resume spec so we can ditch the inconvenience of using human language as the transport
While LINQ does include a library of extension methods for functional programming with .NET collections (which is great), it also includes "Expression Classes". In a nutshell, this allows a user to pass a single expression lambda to a function, and the function implementor receives the abstract syntax tree for the lambda, not the lambda itself. You can then not only receive and analyze these trees, you can also manually build and compile them. This effectively allows a limited set of runtime macros within .NET.
I've been occasionally mentioning this book on HN since I read it. Linked below. The book is about how companies evolve and how teams of people work together. It uses human growth as an analogy and fairly accurately describes how companies fail or thrive at different stages. It's older at this point, but it's about human behavior and group dynamics, which don't change rapidly.
The book doesn't use the phrase founder mode, but it discusses the transition from a founder oriented company to a culture oriented company in detail.
The human analog works well here. Advice for parenting a baby, toddler, child, or teenager is all different. People's needs change over time. At a certain point people become adults and need mentoring more than parenting.
Almost every article on how to run a company fails to qualify the stage of growth that the company is in. Once you start thinking about how companies evolve over time (somewhat predictably), it changes your perspective. PG is right in the correct context. Those advising AirBNB are also correct, in the right context. Following either piece of advice blindly is just living in a cargo cult.
(Like any business book, it's at least 20% BS, but the remaining 80% is quite good. If you do read the book, do not read the first few chapters and assume you've gotten the whole idea. The book has a very good paradigm on worker profiles and what is needed in different stages of growth in its later chapters.)
I grew up working construction on the side with my father, became an appprentice lineman, moved to aftermarket electrical installations in CNC machines, then ended up writing software products for over a decade. I've worked on a wide variety of software: Embedded projects requiring 2000 line assembly ISRs for legacy RS232 protocols, reverse engineering binary network protocols, implementing network server protocols from specifications, writing my own actor and dependency injection frameworks in managed languages, web application backend work, frontend work with JavaScript/TypeScript and frameworks, and so on. I also do a lot of product management, support, customer management, and internal management. Much of my customer support involves teaching external developers from large corporations how to use HTTP and SDKs.
I'm usually one of the smarter people in the room when doing software development and spend a lot of time helping others. In construction, I'm the enthusiastic idiot as the skillset is different. Most tech workers underestimate how high skilled tradework and many other positions outside their experience are, especially management work.
Having said all that, I feel uniquely qualified to offer a rebuttal. The article is describing a clear pattern that I see at large companies that are not focused on software development or lack solid engineering leadership. Ironically, the problem gets worse the more a company tries to outsource IT as they face all the same challenges with less control. It is an organizational health issue however, not some universal truth. If tech workers lack anything, it's experience with organizational growth, change, and group dynamics, not construction experience. Organizations are like people, they grow, change, figure out who they are, have identity crises and need different things in different phases. Ask the highest level/most competent manager you have access to for book recommendations if you're interested in this.
Anyway, back on topic, software "gruntwork" typically implies a department lacks the agency to automate away said gruntwork or lacks the skills to do so. As an example, I work with many organizations using the JVM, but none of them use Scala, Kotlin, Clojure, or any other "nice" JVM language. They use Java. In some cases Java 8. If you're writing Java, there is absolutely stupid gruntwork. I've written example applications for some of these organizations and I had to create code generation tools to stay sane in this environment. In software, you eliminate stupid gruntwork with tools, not people.
We do need average enthusiasts in software development, but it's not the same as construction. In construction the less talented person fetches things and does setup work. In software development, the less talented workers spend most of their time using libraries, plugins, frameworks, compilers, interpreters, databases, and languages while the more talented workers write them.
My experience isn't universal, and I'd be interested in hearing some dissenting opinions on this.
> Most tech workers underestimate how high skilled tradework and many other positions outside their experience are, especially management work.
Absolutely, (in particular) MEP (sheetmetal workers, pipefitters, electricians, plumbers) tradespeople and project managers are highly skilled/knowledgeable and the work requires a lot of coordination. You basically have to understand how an entire building/space is constructed from start to finish to properly plan and schedule a project.
For the record, plenty of other trades are highly skilled, but their trade/craft is more specialized/focused and doesn’t require labor from start to finish.
I think OP has solved some of those issues with this approach. Initially, this is a fun tool that provides value to individuals. The result at scale becomes extremely valuable. The biggest missing piece is verification of skillset. I'm not sure how to solve that. Current employers? Motivated to keep their top performers and little incentive to engage early on. Peers are easy to game and are susceptible to generative AI for automation. You would almost need to integrate some kind of in person meeting for verification. Establish known experts and have them review and verify, then feed that into employer feedback after hiring for a sort of credit system. Employers using the rating system would themselves need to be monitored and policed.
This was a fun one to think about. The secret is in where this link is posted. I was thinking through domain name verification and realized that if employers trust LinkedIn, and you can put this link onto your LinkedIn, it inherits that trust.
So basically, if you link it on your resume/LinkedIn, then the consumer of your AI profile should be able to have the same base level of trust in it.
As for the candidate themselves lying, well, you can always do that. In this case, you can actually verify it better than just having to trust a candidate in the moment in an interview. I see these interactive profiles as a way to actually build more trust and credibility between people by giving everyone more to cross-reference.
The candidate gets to be remembered and have the details of their skills and accomplishments shown, the employers get to select with more precision and make valuable interview time even more value dense by having a better/more informed starting point.
This is a very interesting idea. Given access to long form descriptions of what has been worked on, ideally with some kind of trusted verification, this approach seems like it would operate at scale quite well and could transform the way we network and hire. A technical expert could explain what is needed for a role, and with AI assistance candidates could be sorted through extremely effectively and matched to companies that are a good fit for their experience. Given, this doesn't account for junior developers who have yet to build up their skillset, but for experienced developers this could result in a much more efficient hiring process.
Yeah, there are two angles I'm exploring. LinkedIn is a very recruiter focused breadth first search and not very candidate friendly. I think that's why so many profiles are incomplete, non-existent, old, etc.
So I decided to build something that is useful to a single person first, the person that wants to market themselves. This is the first iteration that seems to be working for me in that regard; as a depth first tool.
This is intended as a 'show and tell and get feedback post', but if any of you want to actually try making one, you can reach out to me at [email protected].
I'm intent on making networking just less painful for everyone, in particular, for the individual. If this gets big enough, then I'll think about breadth first tools.
Men are applying and women are hiring. Half the candidates are lying on their resumes. Many candidates are spamming their resumes indiscriminately. If you've ever had to hire someone for a position that attracts hundreds of candidates (i.e. software engineer with decent pay), you'll encounter the same dynamic. I hate being in that role. I have to reject 199 people and accept 1. Often, there are dozens of qualified candidates. You interview half a dozen, and then you tell 5 out of 6 perfectly qualified people you interviewed they didn't get the job. You feel like a horrible person the whole time. I've discussed this with my wife (we met on Bumble) and she confirmed the scenarios are very similar.
It's often better to be in the hiring position than in the applying position. But it's awful for everyone involved.
The way to avoid this mess when applying for jobs is to build up a network and lean on it for new positions. I wonder if dating may have a similar alternative approach.
I like this metaphor on a few levels; from an employer's perspective, a family is the same as a second job and so naturally they prefer unattached employees.
> The way to avoid this mess when applying for jobs is to build up a network and lean on it for new positions. I wonder if dating may have a similar alternative approach.
The analogue would be court colleagues/coworkers. But today it may be considered harassment.
Comparing a JavaScript ORM to a C# ORM like Entity Framework feels like comparing C macros to Lisp macros.
You can't really have a reasonable conversation about ORMs without defining the feature set your ORM has. If an ORM doesn't apply type safety to SQL queries and translate typed code expressions to equivalent SQL expressions, it's not performing two of the key functions I associate with ORMs. If I didn't take these features for granted, I would probably question how useful ORMs are too!
I think the reason it's so hard to have a conversation about ORMs in general is that we're often lumping radically different systems together and then making a blanket judgement. Again, it's like working with C macros, getting annoyed with them, and then judging all macro systems to be bad.
