1723
Interviews as seen by HR and the candidate
(lemmy.ml)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Jun 2025
1723 points (99.1% liked)
Programmer Humor
33068 readers
453 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 3 years ago
MODERATORS
That means that the HR account thinks what the employee account wrote is bad, too. Both posts are bad extremes.
As an employee, if i find a prospective colleague who doesn’t ask about what they’re supposed to be doing at all, I’d be wary of them, too.
Not even a new thing either. Barely any jobs are done because people want to do specific types of work, and those jobs tend to be severely underpaid (teaching, social services).
People didn't flock to factories in the 60s and 70s because they wanted to work in a factory, they wanted the pay and benefits. Same for office work today.
Me c:
IMHO, in Software Development it's a good idea for a candidate to ask about the project, if only because any good professional would want to know if they're a good fit or not.
Mind you, that makes sense in the Technical interview rather than with HR - no point in asking about what are the practical professional details of the work you will be doing from a person who doesn't really have a clue (the HR person) when you know you will be facing an actual professional peer in a technical interview who knows the work that needs to be done in your terms and with the level of detail and understanding only domain professionals have.
In my experience doing the Technical Interview side of things (and most of my career I was a Contractor - so a Freelancer - which is hardly a "company man" with a rosy view of my relationship to them or somebody who thinks people work for fun), people who don't ask about the project during the Technical Interview tend to as the interview proceeds end up get revealed as technically weak: an experienced "Engineer" would want to make sure they're well matched to the kind of work they're be doing (as well as, in my experience from the other side of the interviewing table, spot the messy fucked up situations before you take the contract so that if you can avoid ending in such disfunctional environments).
Seriously though. I wouldn’t hire someone with that attitude.
Yeah ok people.
It’s not possible to flourish in my line of work without genuine engagement, and a tenacity beyond curiosity to solve certain problems. A jobsworth will not do.
Neither, on the other hand, will a soulless boss or employer, manage to engage.
So keep up with the downvotes and good luck.
"You can't flourish as a corporate lapdog without a genuine passion for being a corporate lapdog. I should know, im a very successful corporate lapdog. My manager tells me im a good boy almost every week. The managers can tell if your heart isnt in it when you lick their face and their boots, if you dont have tenacity and a go getter attitude you'll never be able to be a successful corporate lapdog like me. Its not easy making money for other people."
Wow. What’s happened to you to make you so cynical?
Life.
Look mate, I've been in Software Development for almost 3 decades, mainly in the Technical careed path (did some Project Management but, frankly, it's not my thing) and all the way to Technical Architect, in 3 different countries and most of it as a contractor, so I worked in quite a number of companies and work environment.
(I'm not trying to pull rank here, just showing that I've seen a lot)
In my experience, things like Enthusiasm are what bright eyed naive junior developers have: they're like me as a teen in the swiming pool having learnt to swim by myself and never having had lessons - intense strokes trowing water all over the place but moving very little for all that effort, or in other words lots of effort with little in the way of results.
Worse, Enthusiasm doesn't last forever and, further, most of the work than needs to be done is not exactly stimulating (if it was fun, people wouldn't have to pay money to others for doing it).
People who get at least some enjoyment of their work are good to have (and I'm lucky that after all these years I still get those moments of great enjoyment when at the end of doing something insanelly complex it all works), but in the real world most work that needs to be done is needed but boring so fun in that kind of task by itself won't be enough, plus such people are actually uncommon beyond the bright eyed young things, so if you want somebody who will actually deliver you results (rather than work a lot to achieve little) and you're not a prestigious company (say, like Google, which leverages their brand recognition to pull in such bright young things by the bucket load and drip them out drained of on the other side) and can't pay well above average, you're highly unlikely to get those kinds of people.
What you really want is people who have things like professional pride: they want to do a good job because they see themselves as professionals and feel a professional responsability to deliver good results in an efficient way that doesn't hinder the work of others.
I've seen over the years people with your perspective heading Startups or teams within small companies, and invariably they end up with unproductive teams filled with inexperienced people making all the mistakes in the book (and inventing new ones), enthusiastically. Maybe the people seeking such workers should've asked themselves what their real objective is in that: is it deliver the results needed by the company so that it prospers and grows or is it the pleasure of being surrounded by people having fun.
I just think it's worth pointing out that that is an example of the work being engaging.
No one is so naive as to think that you work a job for anything other than money. The original post doesn't even seem to convey that it's bad to ask about the pay and benefits. It's saying that if, when directly asked, the candidate has no answer to what seems interesting about the job they might not be a good fit.
You seem to be an experienced software developer. You're easily qualified to do basic manual data entry. Same working environment, same basic activity. Would you be interested in changing roles to do data entry for $1 more salary?
I'm also a software developer, and I can entirely honestly say I would not, even though it would be less responsibility and significantly easier work.
Even the boring parts of my work are vaguely interesting and require some mental engagement.
It seems there's this false dichotomy that either you're a cold mercenary working 9 to 5 and refusing to acknowledge your coworkers during your entitled lunch break, or you're a starry eyed child working for candy and corporate swag. You can ask for fair money, do only the work you're paid for, have a cordial relationship with coworkers, and also find your work some manner of engaging.
It's not unreasonable for an employer to ask how you feel about the work, just like it's not unreasonable for a candidate to ask about the details of the work.
Whilst I agree that it's nice to get people who do get some enjoyment from the work, I think it's unrealistic to expect to actually find it in senior professionals: maybe you'll be lucky, but don't count on it - such people need to have started with a natural knack for that domain, not having had all their enjoyment of that kind of activity totally crushed over the years by the industry (I'm afraid that over time having to do something again and again because it has to be done rather than because one wants to do it, crushes the fun out of any task for even for the most enthusiastic about it person), and not having been accepted or even demanded to get promoted to management as they became more senior because they were so good in the Technical side (were they'll most likely suck, but that's not consolation for you as they won't be available anymore).
It simply is very unlikely to find experienced people combining all those things.
Further, even if you do manage to find such people, don't expect that enjoyment of such tasks to be enough to drive an employee most of the time, since most of the work we have to do is generally something that needs to be done rather than something which is enjoyable to do.
If on the other hand you go for junior people who still retain their enthusiasm, you're going to be "paying" for them doing all the mistakes in the book and then some as they learn, plus if you give them the really advanced complex stuff (say, designing a system to fit into existing business processes) they're going to fuck it up beyond all recognition.
So statistically going for enthusiasm is and experience is like hoping to win the lottery.
If you do need to hire people with actual experience, it's more realistic to aim for professionalism as their driver of doing the work well and in time, rather than enthusiasm.
This is why, IMHO, asking people how they feel about the work is a bit silly unless you have yourself a truckload of recent graduates looking for their first job and you're trying to separate the gifted from the ones who went for it for the money (and there you're competing with the likes of Google and other companies with more brand recognition who will far more easily attract said gifted naive young things than the overwhelming majority of companies out there, so that too is probably not realistic an expectation)
I suppose Lemmy is frequented by older Tech professionals, hence the "you must be joking!" reaction to your idea that asking people how they feel about the work is in any way form or shape a viable way of finding good professionals.
So, I wasn't referring to enjoyment. I spoke of engagement or interest. It's why programming is more appealing than data entry.
You're just doubling down on the false dichotomy I spoke of. It's not at all uncommon to find someone with plenty of experience who can easily and honestly tell you why they think what the company they work for does is interesting.
Asking someone why they think working at the job they're applying for is appealing isn't "hiring for enthusiasm", and it's honestly odd that you keep casting it that way.
I get where you're coming from, and I partly disagree. It doesn't seem like you're parsing what I'm saying because of this "either one or the other" attitude though.
No offense intended, but it makes you come across as burnt out and sad. I don't work for small companies, with inexperienced people, and I'm not constantly shipping broken code that needs rewriting. I've been doing this for roughly 15 years and I can honestly say "working in security in general is interesting because it forces you to think about your solution from a different perspective, the attacker, and working at $AuthenticationVendorYouQuitePossiblyUse in specific is appealing because you get to work on problems that are actually new at a scale where you can see it have an impact".
That's not gushing with enthusiasm: it's why I'm not bored everyday. If you're actually just showing up to work everyday and indifferently waiting to be told what to do because it's all just the same old slog... That's sad, and I'm sorry.
Baby's bottom soft.
😘
I’m curious.
What’s your line of work, if you don’t mind?
R&D, software and embedded systems. Small team, hugely collaborative by its nature and sometimes find ourselves faced with problems / puzzles with no apparent solution or precedent. Hugely rewarding when we can crack them.
I do genuinely feel for other respondents who seem to be bitter or cynical - despite the banter.
Ah, no concreted metrics for efficiency and delivery of results.
Explains why you prioritize employees who have fun on the job rather than efficient professionals who are there to do a job well done - you can't really like to like compare with other teams (much less the broader industry) when it comes to delivering objectives because it's all open ended and unique, so you really don't know for sure which kind of employee is more effective but you do know for sure which kind is more fun to work with, hence you prioritize what you can measure - a fun team - not what is more effective and efficient.
Most work out there in software development is not "cracking interesting problems for fun without a strict timeline", it's "integrate new functionality into an existing massive custom-made system, which has at least 3 different styles of programming and software design because different people have worked on it over the last 8 years and only not a complete mess of spaghetti code if you're lucky" - not really the kind of work were Enthusiasm lasts long, but it still has to be done and sometimes, millions, tens of millions and even hundreds of millions in yearly revenue of some company or other rides in doing that job well and in a timelly fashion.
Don't take this badly, but from where I'm standing you're in the playground sandbox of software engineering. No doubt it's fun and even an environment others would love to be able to work in, it's just not the place for professionals and doesn't really reflect most of the software development being done out there, so not exactly a representative environment for determining what kind of professionals are suitable for the wider industry.
A lot of what you’re saying is spot on and I respect your experience in this and the other comment.
I don’t hire for fun though. I hire for a diversity of perspectives, integrity and authenticity. We teach people how to constructively challenge and go after problems or objectives that may have no off the shelf solution (if they do, we may acquire it).
The problems are usually P&L quantified and prioritised before they get to us - we only have to do that legwork if it’s something we’ve generated.
It does feel like a playground to a degree and I do love the work - perhaps yes it’s less ‘professional’ and structured. We do have experienced devs and architects who I would hope aren’t reproducing problems - but it’s often our job to find a technical solution (if appropriate) to a problem, not to ‘productionise’ it or maintain it. This involves a handoff to others in the business and they ultimately determine how it is rolled out.
I get that this isn’t typical of the market and thanks for your response / take on this. One thing we have to be careful of is being ‘institutionalised’ and that will come across as naive, perhaps it is, but that has been a help.
Sounds to me like you're doing the fun part of the job - "solving challenging problems" - without having to do the vast majority of the work (which is seldom as much fun), such as making it suitable for actual end users, integration with existing systems and/or migration, maintaining it during its entire life-cycle, supporting it (which for devs generally means 3rd level support) and so on.
So not exactly a typical environment from which to derive general conclusions about what are the best characteristics for a professional in software engineering in general.
Mind you, I don't disagree that if what you're doing is basically skunworks, you want enthusiastic people who aren't frozen into a certain set of habits and technologies: try shit out to see if it works kind of people rather than the kind that asks themselves "how do I make this maintainable and safe to extend for the innevitable extra requirements in the future".
Having been on both sides of the fence, in my experience the software that comes from such skunkworks teams tends to be horribly designed, not suitable for production and often requires a total rewrite and similarly looking back at when I had that spirit, the software I made was shit for anything beyond the immediacy of "solving the problem at hand".
(Personally when I had to hire mid-level and above devs, one of my criteria was if they had already been through the full life cycle for a project of theirs - having to maintain and support your own work really is the only way to undrestand and even burn into one's brain the point and importance of otherwise "unexplained" good practices in software development and design).
Mind you, I can get your problem with people who indeed are just jobsworths - I've had to deal with my share of people who should've chosen a different professional occupation - but you might often confuse the demands and concerns of people from the production side as "covering their asses bullshit" when they're in fact just the product of them working on short, mid and long term perspectives in terms of the software life-cycle and in a broader context hence caring about things like extensability, maintenability and systems integration, whilst your team's concerns end up pretty much at the point were you're delivering stuff that "works, now, in laboratory conditions". Certainly, I've seen this dynamic of misunderstandings between "exploratory" and "production" teams, especially the skunkworks team because they tend to be younger people who never did anything else, whilst the production team (if they're any good) is much more likely to have at least a few people who, when they were junior, did the same kind of work as the skunkworks guys.
Then again, sometimes it really is "jobsworths who should never have gone into software development" covering their asses and minimizing their own hassle.
The thing is that that kind of information is usually in the offer. I'd be polite and and for confirmation and clarification but not everyone has that kind of tact and not hiring someone because they didn't ask you to repeat what it's written on the offer is kinda harsh tbh.