‘Your Hiring Policy DOESN’T WORK!’ | Allen Holub Talks About Terrible Hiring Practices In Software
Allen Holub talks to Dave Farley about how hiring practices within the software industry NEED TO CHANGE! Including telling a story about how he was once asked a question in an interview that he has invented for his students.
You can watch Allen's full Engineering Room episode HERE ➡️ • Agile & Scrum Don't Wo...
--------------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE ➡️ bit.ly/ContinuousDeliveryPatreon
_____________________________________________________
LINKS:
Allen Holub's Website ➡️ holub.com
Allen Holub's Heuristics ➡️ holub.com/heuristics/
The Agile Manifesto ➡️ agilemanifesto.org
Westrum Model of Organizational Culture ➡️ bit.ly/3QaK8bE
Mike Rother Describing the Toyota Kata ➡️ • Introduction to Toyota...
-------------------------------------------------------------------------------------
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
In my first job, I worked with an outstanding engineer and (later) a great friend who was put on a PIP (Performance Improvement Program) because his "attitude sucked". It didn't, he cared more than everybody else. What Allen says about how this situation is managed is vital.
The idea that slackers and idiots don’t exist is nonsense. Maybe I am from eastern Europe, but these guys haven’t seen a typical software development team. Companies that hire consultants like Dave Farley are already in top 10%.
And most people have periods of slacking, which is not always a bad thing as it can save the worker from burnout, but can result in suboptimal solutions which can be useful to be reviewed
Yeah they live in a bubble, the outsourcing shops have really low average skill levels and you have to babysit the developers otherwise they will just wreak a codebase in no time at all.
@@emyrulz Even supervised they wreck a codebase in no time at all. When I was a consultant, I got to rescue many "off-shored" projects.
The company I work at does not have a skill-test when hiring people. We bring in people and have one or two chats with them with some superficial questions about the area they would be working with and generally figure out if they would make a good fit with everyone else at the company. Generally we filter out people who have big knowledge gaps in general concept, who doesn't seem motivated or interested, or whom it seems like their personality would not make a good fit with their colleagues. So far this strategy has worked out pretty well.
I hate skill tests
Better interviewers are able to get the knowledge without many tests. I agree with what you put here and experienced it from giving and receiving test etc.. that’s said, I did work in a place where I needed people to be semi productive by 4-6 weeks otherwise I had to get rid of them so needed a test to screen out the vast number of applicants.
This approach requires managers and leadership with both technical skill and time on their hands. Sadly most corporations have leadership that's lacking in one or both of those
incredibly based
At my last two jobs I changed the interview process for hiring devs. Just because people can answer SOLID and OOP questions doesn't mean they can put it into practice. It's easy to memorize the definitions. Previously, we'd ask them SOLID and OOP, be satisfied, then ask them these horribly complex, or never-gonna-use-it LeetCode problems. For the tech screen, we now have them review bad code and identify why it's bad (poor variable names, long switch statements, DRY violations, not using interfaces, etc.). If they pass that, they move on to a coding challenge interview where we give them a fairly simple problem to solve. It involves creating classes, using interfaces, hopefully avoiding a lengthy switch statement, etc. You'd be surprised how often the candidate can talk a good game, but then their code violates SOLID and OOP in horrible ways. IMO, it's not a good indication of coding experience to ask the candidate to work with jagged arrays, or things they rarely ever do. We want to see them create multiple classes, call them appropriately, create unit tests, write short methods, write code that's easy to understand, etc.
As a just-getting-out-of-college junior dev, that's a hell of a usefull comment. Thanks!
Have you seen any changes after you changed your hiring policy? For example, do you spend less time helping pairs to write well-engineered code? Does your codebase have better quality metrics and more unit test coverage? Do you get fewer bug reports?
@@jimmyhirr5773 Yes to all of that. If you hire better devs, you have less hand-holding, better code, and they also have a desire to help others as well. The benefits are exponential.
@@rhornjr Yes I am suspicious to those who know exact definitions. I want them to explain the principles by their own words and I also like to ask them about disadvantages. Usually when they know disadvantages they have a lot of experience. So what are disadvantages of doing TDD? LOL!
Any company that hires on the basis of trivia doesn't understand what the job really is about and values the wrong skillsets
Loooong ago I went to a job interview and spoke to a group selected for my interview: The HR person, plus a junior dev and also a senior dev. I impressed the HR and junior dev very much. Their eyes were wide open. I really knew my stuff, and I could show it. But the senior dev didn't like me. He gave me a series of weirdly-worded and badly contrived hypotheticals, and I did my honest best with trying to answer them. One of these questions - the 2nd last one - I just didn't understand the contrivance he had described because he said that: "for a reason I can't tell you, the obvious answer is not allowed. You have to think of another way to solve the problem." And I admitted that I couldn't see any alternative to the very obvious solution, and I gave up. _The senior dev was very happy!_ Then he moved onto his last question - a complex OOP problem with a weird inheritance hierarchy. I stood up and walked to the whiteboard where he had drawn his question, and after a few seconds I drew a class hierarchy that seemed to me to solve his problem. The senior dev was pissed. _Really_ pissed. I asked him if he thought my solution would work. The only thing he said as he turned his back was: "Next time I ask this question I'm going to disallow your solution." I didn't get the job. _But I also knew I didn't want the job._ If this dude had such a fragile ego that he was genuinely pissed at me for seeing a solution to a complex problem that he didn't see himself ... then I knew he was going to be a nightmare to work with. I kept a straight face at the time, but when I realised what the senior dev's actual problem was - his own ego - my inside voice said: _Fkn wanker!_ 🙄
Lordy! Bullet dodged! Company shouldn't have him in the hiring process
@@KeenAesthetic1 Probably the reason they needed a new Dev any way really!
@@KeenAesthetic1 The company shouldn't have him, full stop
It’s good you figure that out, I think the more people that view interviews as a two-way street the less tolerance those fkn wankers will get.
@@cod3r1337 - sadly, the dude was clearly gatekeeping the hiring process. Not a good sign for the company. Everybody has come across wankers like that, it's not a big deal, but when they get to veto the hiring process based on their ego being hurt, that's a different story. And I forgot to mention that when the senior dev introduced himself, he chose to call himself 'a LISP programmer'. He did seem to like that fact that I knew what LISP was, but had never coded in LISP. And he was at pains to point out that he didn't like to get his hands dirty with Java programming. Even though they used Java for their production code. Sure, Java can be a right pain-in-the-arse at times, but ... *LISP???* 🙄 There were no LISP development positions anywhere at the time (early 2000's), so I was a bit worried that he made a point at the outset of telling me he preferred LISP.
If there are drunks in the workplace, the workplace needs to make sure that it is not the reason why they are drunk. If the workplace is the problem, it needs to fix itself.
Exactly. Once I worked in a company that paid me a low rate from the start with a promise that after 6 months they will pay me competitive rate if I will fulfill their expectations in the first 6 months. After 6 months they were satisfied with me so they hired me for indefinitely and they raised my salary just for about 4% so it was still far from what I could get elsewhere. This made me "drunk" so I didn't want to work hard anymore and eventually I left the company on bad terms. LOL!
I consider HR feedback in interviews purely from the perspective of personality and cultural fit. Sometimes HR members pick up on warning signs that I don’t see. I’ve never seen a situation where HR people were asking technical questions during the interviewing process.
For the last 15 years I've been fighting against the stupid habit of asking questions about algorithms. In our job, the bulk of our challenges has to do with design and architecture. In my experience, the people who are best at algorithms are also the worst at making code clean and reusable.
It depends on what you are engineering. In some cases the algorithms will be the meat and potatoes. But that depends on the requirements. Arguing about it when it isn't necessary to meet the requirements is overengineering
Then you have a strange experience. Good developers are good in algorithms and refactoring to make code clean.
@@tongobong1 I know for a fact that most of my juniors would do better than me on most of these algo questions. Yet, I have way more to offer as an experienced developer. Junior people are often good at algorithms because they're good at solving well defined problems, where the space of solutions is implied by the fact it's an interview question. They're not good at incorporating complex business considerations in their design, cutting corners where it's allowed, experimenting with new technologies and quickly determining if theses techs are suitable for the problem at hand. These are the things that we should test people about. Not leetcode.
@@ssssssstssssssss exactly. Unless you're working on a search engines algorithm, or Ubers fleet management, most of the time the challenges are going to be to adapt to continuously changing customer demands. Good architecture is what makes that possible. If your implementation is shoddy, you can always improve that as and when needed, if your architecture is sound (for instance, if you have good unit tests). While if you have good algos but poor architecture, every improvement is going to be painful.
@@plouf1969 OMG you should improve your knowledge of algorithms. You can find great lectures on youtube from top Universities for computer and information science. Good background in algorithms can drastically improve your ability to find good solutions for mathematically complex problems and you will not feel threatened by junior developers that know algorithms well. I agree that refactoring, designing good architecture, unit tests... are very important topics but everything starts with finding good algorithms for solving problems.
Love the idea of hiring people for a day to test them out. Would much rather do that then stumble through a broken interview process.
That opening statement is critical, re: about working with smart and motivate people. I’m a PO in my current role, have been a business ops manager, data analyst, BA, etc. I write SQL code, but am not a developer but have been part of some amazingly successful and complex projects with true dev ops mentality and have been part of some sluggish, awful projects that should have been way easier. Regardless of the team I have been on, waterfall, agile, whatever… if you don’t have smart, motivated people, you first have to focus on that. The worst project I had was probably one of the least complex, but we had unmotivated, not the sharpest people. We spent more time on trying to develop trust, and communication going between scrum, kan an, hybrid, whatever. It didn’t matter what we did cause we just didn’t have the right combo of smart, motivated people.
Excellent content. Thank you. However, I find the constant moving frame background color very distracting and unnecessary.
In my experience, managers need to be very confident in themselves in order to work with competent developers. For most managers, it's extremely diffifcult to work with talented people, because they get jealous or threatened. 99% of managers prefer to work with people who are less competent than themselves. That's the reason many managers create a very hard hierarchy within his team, in order to hinder any communication between developers and the client/upper management. They do that because they are afraid developers will steal their spotlight. In these organizations, the managers, indirectly make all of the important decisions relative to the code (even if indirectly) and the developers are only responsible for typing the manager's solution on the IDE. But If things go wrong, they always blame the developers. Developers don't have any actual decision making power. And communication/argumentation will often lead to an angry manager. That's why good developing practices like TDD, DDD, BDD, Clean Code and Continuous Development rarely gets implemented in real world software. Politics always trumps the technical endeavours.
@@pcap8810 yes it is common for a company to lose competent people because it is not firing the incompetent.
No... I find many managers are FAR TOO CONFIDENT to be useful to anybody.
What I've noticed over the years is that modern management approach software development individuals/teams as if they are sales people/teams. They think that by overloading them, they'll "man" up and do the work they way sales teams do. They think the "Glengarry Glen ross" style of motivation will work for engineering teams. Which, again, demonstrates that they have no idea that software development requires a different mindset/skillset than sales. Try explaining to that style of manager that software development is akin to performing a series of complex calculations and that they should understand what mental health is required for that to be accurate and trusted, and watch the blank stares. I noticed this beginning in '98 when the need for an internet service/presence for a lot of companies meant they had to find whomever they could to manage the newly created projects. So you no longer had technical people managing technical people. And outsourcing to the cheapest developer (newbies) for mission critical products (internet banking) seemed to be the norm in silicon valley. And that went well!! ;-0
This is how I run technical part of interview. I present a problem that we faced in the company, but simplified. Then I ask candidate to think about it aloud. If he/she manages to find a solution (he/she can just say it, not write it), then I present a complication. And then I add some more complications. When they come up with a solution I often say "OK, but...". Then I'm paying attention on a thinking process of a candidate. Some of my best developers are those that presented a solution not mentioning a single programming language or tool. Some of them didn't event manage to find a solution but they were so excited about the problem. One candidate emailed me an hour after an interview, excited that he found a solution.
I got a friend of mine who's still in University an internship interview where I work and they said "The interview is going to be during the first week of next month", what they meant was that was the scheduling window, but he took it to mean he'd have an interview every day for a week 😂
This thing about trust is very important. I heard a rumour that the finance director was complaining that the engineers were making the business "engineering lead". I wonder when that director last talked to a customer.
So many of my friends and colleagues spend 20+ hours interviewing. It’s like they have to meet half of the org! What do you need to know that can’t be found out in an hour?
Trust
Presumably you would go on more than one date with someone before proposing marriage. Bad hires are very disruptive to a team.
@@7th_CAV_Trooper yes but you should always be able to get rid of bad hires because no matter how many interviews you have you can't find out whether he is really such a nice, honest and hardworking person like he seems on interviews.
All you need to do for this method to work is hire perfectly motivated and highly skilled people. At that point you can still use feature branches, or trunk based, or a share FTP folder. It won't matter. This process stuff is all mostly useful in non-ideal situations. Anyone can propose a working process in an ideal one.
Exactly, the process accounts for maybe 10 percent of the outcome, the fundamentals and context for the rest. The problem is that having strong fundamentals is hard and fixing that in an existing team almost impossible. Improving the process on the other hand is the easy, bike-shedding route that so many managers like. Also it's the biggest cop-out of all the process improving salespeople out there: of course it doesn't work under non-ideal conditions. Well duh! And if you think about it, when the process is the spotlight it has become political, it is mostly a tool to manage soft failure.
there will be a lot of “you worked at FAANG? welcome aboard” with all these lay offs
Being occasional slacker means you have some time for creative thinking at work. Which probably means company has at least potential to react quickly to changing environment around it.
I'd totally love if our IT industry had a hiring process like they described at the end! Walk the walk for a day to prove your game and you're in! My Gong-Fu is good, but I hate our interview process it's like collage exams and I've been in the biz for over 20+ years to be still asked basic academic questions on interviews at this point and expected to give book answers over experience answers. But that's the way of it. If we had certs like Journeymen and such like Electrician, that wouldn't be a thing, they'd trust our certification to have handled our knowledge. My brother is such and tells me that's how their hiring practices are. We're paid more, but I envy their hiring practice so much more. But I ain't one to gossip... .
having to take a whole day away from a current role in order to "interview" like this would exclude a lot of people, though?
@@ljnoble5171 Not really, they could have whole labs dedicated to the exercise of vetting candidates in a room with personnel whose job is thus, or who volunteer a few hours for the function, or they staff for it specifically like they do to get us in the first place with hiring firms. Plenty of options, really. But I ain't one to gossip... .
Yes I think interviews should be more like conversations between two engineers about common problems we face and not so much about answering questions about some details that we can find the correct answer on google in 5 minutes.
I did such an interview once... my PC wouldn't boot and IT didn't fix it until the afternoon, I failed the interview for only doing half a day's work. This sounds like a ridiculous made up story, but I assure you it is 100% accurate.
@@edgeeffect I 100% believe that's how it played out, and say to you that if that's how they played it - you're the one that got out lucky. They revealed that something beyond your control that is corroborated by the DevOps ream needing to fix it, and they failed you instead of immediately starting the interview over - no grace period if they wanted to exclude "cheating." Then it was just a sign of worse things to come when it came to having your back when you need them - you'd be sacrificed for not making a deadline or making a decision that when different that optimal vs. being in your corner (and I'm talking legitimately, not if you screwed up from incompetence). You'll just have to recognize those moments as them outing themselves as maybe not the best fit, and move on with your head up for the next interview. It's bitter, but will be sweet when you get the better fit (irrespective of how starved you are - die on your feet vs living on your knees kind of thing). Trust me - is you hate it after a month leaving for greener pastures looks bad on you to the next employer, not the last employer, even though fit works both ways. But I ain't one to gossip... .
I loved to hear about the "myth of the slacker". It's true, if given a chance, people will always prefer to do their best and feel good about it and gain self respect. But PRs are not bad, and some form of gate keeping isn't bad, code review isn't about sloppiness, more pares of eyes are good...
These two gentlemen's seems to be excellent. I would love to work with people like you. I live in south of Europe, in a beautiful country,but most of the people doesn't have any business view and doesn't have the competence and skills to manage a software company. They are killing an entire product line of good software and good engeneeres with bad management.
People make or break successful delivery, and are probably the most abused aspect in team building. I really enjoy a good tech interview, one where the interviewer knows their stuff, and knows what they want in a candidate. What's seldom is wonderful, because what we mostly get are underqualified, inexperienced, job-protecting types that follow neither rhyme nor reason.
I lead a small team of 7 developers, and not everyone can be a rockstar, but I'm happy to take on green juniors and help them improve. In recent times I've lost 2 great developers who went from borderline juniors to excellent 'mid-level' developers in short time, and unfortunately left to other companies who would pay them a competitive salary (ours doesn't sadly). Allen's point about slackers is spot on - I've seen very few 'slackers' in my time, developers by nature are self-motivated to do a great job and improve their skills. We still use PR's and feature branches, and we're trying to remove this workflow but people do from time to time make simple mistakes, or are unaware that they're reinventing something that already exists in the code or in external libs. We should be pairing more and mentoring, but the uncontrollable part of this is the demands by the upper management makes this great theory but not achievable. You can only try to achieve utopia within the constraints of money and management.
In what circumstance would you ever need to calculate the stack frame size of a function? That seems insane. In my 15 years as a c++ programmer I have never came close to having to know that.
Exactly my reaction to this problem. There's no practical value I can see in that. If only a way to probe a candidate for some in-depth knowledge for how things work under the hood at the machine instructions level. Even if I'm hiring for a team that works on an IL or a VM of a sort I'd rather ask to explain what would the the difference in sizeof of an instance of a class with and without a virtual function. Obviously, even a right answer to that question wouldn't be grounds for an immediate hire but those programming gymnastics types of questions are completely superficial and are a waste of everyone's time IMO
This comment thread is over!
I've had to track down stack overflow issues caused by too many variables on the stack in unoptimized builds. (Lambda captures + forced inlining.)
The point of the question isn't to get the right answer. The point of the question is to evaluate the candidate's critical thinking skills, and to evaluate how well they understand how their programming language works in practice.
I had to do that in System's programming class in the late 80's, but not since. Perhaps if you are creating a compiler or a VM.
Feature branching is sometimes required by regulation outside the company, as in the law requires a designated person or a group of people to put their stamp on a code change.
You mean it's required by a parent company. Where does the law specify what methodology a development department should use?
There aren’t any compliance frameworks that specify feature branching specifically (that I’ve ever seen - like SOC 2 etc). What they do specify is some form of ‘change management’ or ‘change approval’. However, that is not going to be tied to the specifics of e.g. git because some orgs don’t use that (like Google). So what you have to have is a mechanism to say that the code has been ‘approved’. That can come in all kinds of different formats that may or may not involve branching. In any case, whilst trunk-based development specifies the lack of branching, the practical version of that in git involves using very short-lived branches (feature branches imply long-lived) as simple staging areas upon which to rebase master. So a PR is just a temporary viewport onto a change in a fast-forward commit strategy in a trunk-based setup.
Random q: what does it take to be one of those approvers? Could you reasonably have one on your team or if you mob/ensemble there with you? “Shift the problem left” kind of thing.
I have spent a lot of time working in regulated industries in various parts of the world and in a variety of different industries. No regulatory framework that I have ever seen mandates Feature Branching. Some do mandate reviews, but there are several other ways of conducting reviews that don't depend on FBs.
I once did a "come work for us for a morning" interview... the PC they gave me was broken, IT didn't have time to fix it... and I failed the interview because I didn't get any work done.
The point about performance hit home. I've never ever had a Manager work with me to figure out why the drop in performance and what to do better. Just get on a PIP with ambiguous goals and hope for the best. The worst!!
The thing that most frustrates me with interviews is, even though ive got 36 years experience I still find myself rejected because "we use framework X here and you're using framework Y at your current job". The fact that I've obviously picked up Frameworks A, B and C along with a generous handful of other languages and paradigms in the past is irrelevant.
1:50 That's mostly a problem you have in environments which are not using TDD. If you can't ensure, that the program is tested in depth and there's no strategy to test, the tests are not automated, or the tests take insanely long, then the tests will get skipped or ignored. I had that on a hardware project, where the tests on the master branch were already failing when I started. I only noticed that, because I finally wanted to merge my stuff upstream and I did at least run the tests once then. Turns out everything was already broken on real hardware when I picked it up. So now I either had to explain, why it was someone else's fault or I needed to go and read into code that wasn't written or designed by me and was undocumented on top of that as well. In my opinion, this is even more insane for hardware than it is for software. Especially as it's not that hard to interface with a hardware module, as hardware modules don't use inheritance, I don't get, why so much VHDL and Verilog code remains completely untested (I don't even understand how they were able to write the code in the first place). The first thing I do is, write some tests of my own, only for documentation purposes, but that's not how it should be done, in the first place. It's a similar case for a software project I just picked up. It works incredibly well, for how untested it is. And everything works, because luckily enough, that code was always (only) tested in that context. But aside from that context, it would go absolutely crazy. Functions promise one thing, but actually do something completely else. Just in the context that they're called in, it seemingly works, even though the documentation for that function is a lie, and if that function did what it said it did, the code would not work. That's in my opinion usually the case when only one person works on the codebase. That person knows incredibly well, what they've written, knows what they shouldn't touch and knows if something breaks, what the cause was. It's however useless to anyone else. There's no "shortcut" to understanding how that module is supposed to work, making it next to impossible for others to understand what's going on, in case it's already broken. When you now bring a new person into such a codebase, the "trust problem" is completely rational. You know at how many points the application can break and you know you have no way of testing that.
I think companies lose a lot of people to the fact that we have about 3-4 interviews before presenting a contract.
Yes. The best places that I worked at essentially interviewed constantly, and were VERY selective about bringing new people in. It worked for us!
As someone who is on a team actively hiring someone to work with me, I extremely value the interview process. I may have turned away a good candidate, but if you can't effectively explain to me how you solve a problem in an interview setting, then how are we going to work on a team together? And I'm not asking off-the-wall questions. I'm asking questions that have come up in my work. I may cherry-pick the more complicated situations, but that's because I want someone who is at least as capable as I am, and preferably more. I will settle for someone who I can communicate well with but doesn't quite have the technical chops, but those seem few and far between. It also doesn't help that resumes are almost universally full of lies or exaggeration. The number of times I've seen "Experience with SQL" and the competency level is "I know how to do JOINs" is astounding. On the flip side, my boss admitted I wasn't hired on the merits of my resume, which apparently under-sells my skill set. I just try to be honest about what I have done and what I know, but having seen behind the curtain it seems that's not expected.
Oh jeez. Sounds like I need to stop being so honest on my resume... I probably look pathetic by comparison
It's probably how Allen wants to be hired, but "Come work for us for a morning", simply won't work for most people. It's great for a senior consultant, you've probably developed the skills to hit the ground running and so much of what you offer is in your advice. Perhaps you're a technical founder looking for your next challenge. But it's impractical for salaried workers with skills far more focused on steady individual contribution. It messes with your taxes and may be in conflict with your current employer's contract, such as non-competes and some even prohibit second jobs. These things are generally not enforcable but I've seen them used to put pressure on people.
One more reason why we need to make non-competes illegal And I mean explicitly Like “don’t even put it on there”
I am willing to work for a morning... for the right price, of course. I refuse to work for nothing.
@@scootergirl3662 It's not just non-competes but IP assignment too. My point is, there's way more to this than you'd think and it varies throughout the world to what you can and can't do.
@@unduloid working for free is unlikely to be legal either. You'd likely own the IP to anything you produce (or worse, your current employer will own it)
The best interview I had was me pair programming with an employee. We didn't actually code anything; we just had a discussion. I quickly understood the project, the code style, and how the team worked. I really like Allen Holub's work-for-a-bit idea.
I've met slackers and idiots and they don't agree that waterfall process is bad. Every features and stories should always be a final spec or else you're wasting dev and qa time when you are revising and refining the features and specs base on feedback.
I was once hired as a "favor" for one director who was not liked and wanted to use sources the teams didn't. I was given one impossible task after another, with measurements moved every time I achieved. I was miserable and eventually fired, which was their goal to say "See, so-and-so's idea of hiring is bad." Oddly though, I was paid nearly 6 weeks severance which told me someone didn't want to get sued. It really sucks getting caught between two boneheads having a pissing contest.
Tbf, i think the point people are trying to make is if you're a competent software developer, you're gonna be working with all kinds of people, some who are smarter than you and some who aren't. So it is important to be able to work well with people who aren't as smart as you.
My experience is that most companies want young, easy to manipulate, people. Preferable people with not much of a social life (nerds) So they can be easily manipulated into lots of work outside of paid hours. But in the last years this has changed since communicating and teamwork has become more important. So the standard 'nerd' isnt good enough anymore. But this is also has become a problem for managers, since they have to change too. Just yelling, threatening and scaring programmers does not work anymore. they actualy have to motivate them. Give them stuff and make compromises. And most managers did not adapt yet. In most companies these days it is the managers that are usualy the problem, the reason the engineers not working the best they can or are slacking.
I've seen people who were under utilised, and this gave the appearance that they were slacking, but I don't think I've ever seen anyone who was genuinely slacking in the 20+ years I've worked in IT
You haven't seen enough. Underutilized is just a code word for evading responsibility for your deliverables.
Remember: If you weren't hired, you dodged a bullet. Either you weren't a good fit for the role--in which case you would have been miserable--or they rejected a good fit for the role, in which case management is dysfunctional.
Finally someone says this out loud.
I've got slight PTSD from the "size of the stack frame" question!
This "agile approach" to hiring comes with its own set of problems, though. Depending on jurisdiction, there might be legal concerns with short-term engagements. Also, a highly regulated environment such as in banking might get in the way because of security or compliance regulations. But much more importantly, there might also be ethical concerns. Imagine you are considering to hire somebody from a different continent, whose decision whether to (and indeed permission to) move to your country with their spouse and children depends on you offering the job. And imagine there might be no going back to their native country after leaving it. So that person might be taking a great risk. You should be as sure as you can be that this person doesn't end up stranded without a job in your country on your account before offering the job. That's simply a matter of doing the fair and responsible thing. This is not a contrived example I just conjured up, this is straight from the trenches - my team is struggling with just that kind of decision.
Remote working? Zoom? Slack? Why would a dev. need to move to your town?
@@edgeeffect Have you ever tried working remotely with someone from a country that doesn't have usable broadband or uncensored access to the internet? Well, I have. It. Doesn't. Work.
I applied for a ton of job in austria and germany after I finished university. I was scared because of all the stuff I read in internet, I was prepared for test like interviews. so, my first interview was with the company that makes teamviewer (via phone). I sucked hard at that interview because it was 180 degrees different from what I was expecting. I couldn't even tell them what LINQ is even though my bachelor thesis had to do with it. so, after more than 50 interviews, I only had 2 or 3 of them asking me code stuff. all other were interested into my motivation, loyalty, personality, character, things that describe me as a human (rather than a software developer).
Fix oida!
"... the proper way to deal with someone who is underperforming is to find out why and fix it ..." Bravo!!! In one of the companies I've worked for, I was told I was underperforming. My issue was... helping others!! I was replying tons of questions, writing documentation, testing code (it was not required 🤷♂ => we ended up fixing the same issues over and over!), etc. Once I stopped doing that, I went up ... through the roof (they lower their performance all the sudden, then I increased it a bit, but the difference became obvious)). From my point of view, that's not the proper way to deal with the situation (the company's behaviour), but I had to hold the job so ... PS: I did still help. But a couple of times per day (30 minutes in total, 45 at most), before that it could easily be 8-9 times per day, from 5minutes to 30 minutes... unsustainable!
I think the laundry list of skills requirements come from the waterfall way of thinking. If your software is supposed to be perfect upon delivery, and you aren't doing quick iterations on the problem to work out the best solutions, then you need people that have deep skills in every technology that you might use. Of course it never works out, and even a group of people that have the skills you need won't deliver perfect software on the first try. Hiring flexible people that have a scientific approach to problem solving will always work out better in the long run, but it takes time for the business side to get comfortable with that.
It also carries with it the assumption that people can't learn, that they can't be more than the list of skills on their resume.
i love collabs
The thing is, people who can write software generally enjoy it enough that slacking doesn't really appeal to them.
To the idea "agile only works with a good team": I learned software development in one of these code boot camp things and in our final project was to work together to develop a software product. The sixteen of us were inexperienced as could be, and we made many mistakes as a result. However, we didn't have a problem with organizing or motivating ourselves. Agile can work with the greenest of teams.
It sounds like you had a good team!
Unfortunately, I think hiring laws and other legal concerns (some justified, some not) are a big hurdle for why many organizations take such a cautious, un-agile approach to hiring. Just a hypothesis of mine, but when I worked in a bank I saw that legal reasons were a driving motivation for *many* decisions. And not just bank specific ones but ones that likely apply to many corporations.
I don't think it's as easy as "I looked at your resume come work for us" . Specially if your country has work protection laws as it is in most countries in europe. You'd need to hire someone for at least 3 to 6 months for that trial period. Too much of a time-money risk to take in my opinion. White board questions might not be the best way to evaluate a candidate but you can ask other things. Unless your company is literally swimming in money I would not just hire someone based on their resume
Yea, try also hiring devs from abroad with that approach, sponsor visas, relocation packages, have them change their lives irreversibly only to send them back 1 month later if "it didn't work"? ... I normally like what I hear here but this sounds provincial
Don't most countries have that 3-6 month trial period when they can let go of a worker "for any reason at any time"?
@@Colochoide you start with remote contract for 3-12m, then relocate
I fail to understand how a person fail to perform after getting refined by 10 different rounds of interviews and tick marked against the buzz words like - leet coder, algorithm expert, system design expert etc …definitely there’s a serious flaw in the recruitment process.
I want to hear more about the interview What happened next?
This is a snip from Allen and my "Engineering Room" chat which you can find here: kzhead.info/sun/m9yRnbimmWWjeY0/bejne.html
Amazon encourages adversarial relationships. "Be right a lot" is one of their core "leadership principles". They rank developers based on how much they comment and challenge code commits. They also rank developers based on how many commits they make. This results in simple features being broken down into many commits - literally 10 lines of HTML will sometimes be done as multiple commits. If you approve a commit without commenting in the repository, it hurts your employee score. It also doesn't help the fact that managers are incentivized to terminate a percentage of employees every year, if they don't, it also hurts their employee score as a manager. I've known good developers at the company who were forced to work 7 days a week for 3 months straight because they were arbitrarily chosen for a PIP by management.
I wish KZhead had a big heart reaction button.
There is if you click in the 3 dots next to share
@@user-db4dd4ze3n haha, yes! Definitely a better alternative! 😁
God forbid hiring practices from taking into account that human beings are capable of learning and getting better. Just hire the best guys and let the newcomers never get the experience amiright fellas
In my experience, both the slacker and the "super programmer" are myths. The super programmers I have run into, legends in their companies, write code that is unreadable and unmaintainable. Its a consequence of management that holds speed of coding above anything else. The only real "slackers" I have run into are people who don't really want to be programmers and are working their way into management.
Amazon work culture is proud of it
I'm old enough to remember when HR referred to resources for humans rather than humans as resources #soylentgreenmanagement
With motivated and smart developers it doesn't matter what branching strategy you use or waterfall or whatever. Things just work. Things just happen. Because they are interested and engaged. Pay them. For as long as you can.
A highly motivated person who isn’t smart will work hard to overcome their shortcomings HOWEVER a smart person is useless if they have no motivation to apply their intelligence. Also I will hire a logical person with knowledge of one language over a person who knows 10 languages but doesn’t have a clue how to logically apply any of them
So you know within microseconds if you like someone but a whiteboard exercise still won't tell you. 0.5ms whiteboard exercise I guess?
I thought Dave then said “then you throw in the drugs” Maybe I have a different idea of why a party means…
Maybe the drunks are drunk, because they got that insane amount of work and the only way to cope with it, is get a few bottles of beer. ;-)
7:46 this
50% of the population has an IQ lower than 100. Let that sink in. You probably need atleast 110+ to be able to be a viable engineer. And on top of that you need various other attributes.
This doesn't mean 50% of programmers have an IQ lower than 100, though.
"Fix the trust issue" *intern looks uncomfortably at the screen*
I am wondering why do you have such strong opposition towards feature branching. We're working on a code base with several million lines of code, and the code isn't even in one single repo. We target a bunch of different platforms. Maybe some developer has all the devices representing all the platforms, but most don't. And even if all of us did have all the devices/platforms to play with, it would be an enormous waste of time to manually check the code on all devices. With branching we can let the CI build for all the platforms, run all tests, make sure that everything can be linked, etc. And when everything is green, merge it to master. I couldn't imaging working on master in this projcet. With well over a hundred developers, I think we would not be able to do it without feature branching.
My opposition to feature branching is that, I am sorry, but you can't do what you are recommending if you practice it. You can't, by definition, have both CI and FB, unless the branches last for less than a day. I'd add that the data (read the State of DevOps reports & Accelerate) say that teams that practice FB produce lower quality software more slowly. None of this is personal preference or choice. CI is defined as "everyone integrates and evaluates their changes together AT LEAST ONCE PER DAY". You can't do that with FB's because, also by definition, you don't get to see what other people are doing until they think their feature is finished. CI isn't easy, it would be nice if FB's worked better than they do, but they don't, and they don't for some fundamental reasons that it is impossible to duck. This doesn't mean that projects that use FBs always fail, or that switching to CI is always easy. But if you want to be working in the most effective way that we know of so far. The way that we have data that predicts outcomes for teams that do it, and predicts more chance of commercial success for firms that employ teams that practice it, then that way is CI, not FB. In my opinion FBs are a sticking plaster fix that paints over the cracks in a dev process. Sure it can help if your approach is a bit broken, but it is a local optima and once you are there, it makes things worse not better. That last part is only my opinion, the rest is not, it is how FBs and CI are defined.
@@ContinuousDelivery Thanks for the reply! I think we had a different idea about what feature branch is (or what is a feature). It makes much more sense now :)
Never seen slackers? Wow... Is this some form of modern privilege? I imagine that the reason Dave thinks that feature branching adds nothing to a CD pipeline is because the testing is already thorough and stubbornly petty. You wouldn't see a slacker in such an environment because he will be automated away by a red build and deployment report. For the people that have to do the PR reviews of feature branches, slackers don't exist because anyone with enough hubris to show off slacker attitude is going to be met with a pink slip. No employee, good or bad, is in the business of getting in such bad waters unless they don't care about the job at all.
Shame, you cut off the video right before Allen was going to say something interesting. I would pay to hear what Allen recommends instead of the laundry list approach.
Here you go: Roughly the same spot, but in the full video: kzhead.info/sun/m9yRnbimmWWjeY0/bejne.html You can pay me a cup of coffee if we meet some day ;)
not personality problems? you've not worked in government It have you?
The myth of the slacker in Easter Europe is related to the communist regime. During this time the economic development was based on 5-years plans. These plans were usually not met by quite a lot. Not accomplishing the plan was a major issue and someone had to take the blame. People in management at that time were always people from the communist party and the party never makes mistakes. So someone who IS NOT from the party and being late for work is a really good candidate to take the blame. More over there was a form of silent resistance to the management/party/regime in the form of working with somewhat lower quality and wasting resources. There is a video that explains this to some extent: kzhead.info/sun/lbOihJyQpKCvlZ8/bejne.html
I had to code FizzBuzz on a piece of paper!
#facepalm
I had to code FizzBuzz formulated in this way: If it's a multiple of 3 write Fizz if it's a multiple of 5 Buzz. I said either it's unsolvable or if it's a multiple of both it's my choice ...
Funny 😁
I would love see a discussion between Dave Farley and Martin Fowler on ChatGPT / GitHub copilot.
These guys sound out of touch. Where do we find these geniuses that make perfect changes that don't benefit greatly from peer review? Somehow they never have any bad hires or people who just aren't that great yet? Somehow mentorship and training will turn a junior developer into someone who operates independently and without supervision within a week or something?
I don't think they argued that peer review can't bring benefits. But it does bring costs.
They’re both proponents of pair/mob programming, which is a more efficient way to solve the challenges peer review is intended to solve
@@doomlord224 They're still out of touch. That implies that in a team the number of people who really know what they're doing outnumbers the greenhorns. More often than not, it's the other way around.
As a junior dev, I would prefer to be paired with a more experienced dev and work with him (this will provide amazing tutoring and mentoring) instead of being assigned to some task that I have to do on my own, and waiting for 4 weeks for my pull request to be “reviewed” (I didn’t make this up, I really needed to wait for a month for a review)
Te
6:30 #Te
Love it: come work with us for a day and we’ll pay you.
To be fair - If a company brought me in to work for a day id smash it... However they'd never get me in to work for that day .. even paid Who has time for that? we all have obligations, and I think this means doing it when I'm not on call, probably on a weekday when I should be at my current job, or outside of it when I'm with my family.
Stop hiring (and quickly remove) contractors who spew nothing but self promotion while simultaneously being counter productive and aggressively rude to staff. Such pieces of garbage cost millions in lost productivity and time. This is especially applicable to engineers.