9 ms·
Or they could just lie and tell you from the perspective of another dev on their team, or even combining the achievements from several of them at once. Of cours
by username90 7y ago
Or they could just lie and tell you from the perspective of another dev on their team, or even combining the achievements from several of them at once. Of course most people wont lie a lot but this style heavily favors those who do so you will get a disproportionate amount of liars on your team.
- dahart 7y agoI think your assumption is incorrect, based on my own experience. I’ve never hired a liar, and I’ve hired a lot of people. I have, however, declined to hire people who failed to answer follow up questions honestly or appeared to not be able to explain their success. Anyone who wants a job knows it’s a bad idea to lie because you find out immediately once you hire someone whether they are lying, and it would be grounds for immediate firing. Also follow-up questions weed out lies & half-truths very quickly. You should try it, see how long you can answer probing questions about someone else’s experience. I agree that most people won’t lie, and what does happen is almost always not lying but just spin, trying to glamorize rather than outright fabricate. My experience is that people get honest about their glamorizing very quickly if I keep asking more questions.
- username90 7y ago> you find out immediately once you hire someone whether they are lying Do you really believe this? Lets say we have a mediocre person on a team who tells the story of him being a star performer. How would you catch that? He went on the design meetings, he know why every decision was made, he has worked on the project for years. There is no way you would catch it, and the halo effect would likely mean that you still think he is doing decent work but that the environment might have made him a bit worse but you wouldn't believe that he lied.
- aantix 7y agoNuance comes from experiencing constraints from implementing the solution. Eventually the liar runs out of those details when pressed.
- dahart 7y ago> Do you really believe this? Yes, absolutely. I’m not lying. :) Like I said, I have lots of experience with it. I’ve interviewed people who tried to inflate their contributions, and it’s easy to tell over the course of a 5-10 minute conversation. > How would you catch that? Easily, they would fail to be a star performer, and fail to match the abilities they advertised. You can’t lie your way into good programming. However, it’s bigger than lie or not. Seasoned programmers have mature philosophies, and you can tell by talking to them. And honestly, I don’t mean this judgementally, but your question does sound like it comes from a lack of experience. You will find out what I’m talking about in time; big lies are not in the least bit easy to pull off, and almost nobody tries that kind of thing because the probability they’ll get caught and have serious consequences is very high. Being present in design meetings and knowing why decisions are made does not make you able to talk about it fluently. BTW, while I believe this myself absolutely, I don’t know for absolute certainty that I’m right. So if it’s easy to do and the payoff is large then you should do it and write about it! If you could easily lie your way into a job, then it should be easy to work your way into one of those super high paying jobs, making robots or neural networks, and get away with it for years.
- bigwavedave 7y ago> You can't lie your way into good programming. Agreed. There's so much more that goes into programming than just knowing a programming language or two, so even if someone does know basic coding or has medium understanding of a former coworker's acxonolishments, there's so much more in the domain that (in my experience) liars, fakers, and overhypers are exposed very quickly after hiring. Granted, understanding this doesn't help weed them out before the fact, but still I think most interviewees know this and are wary of spinning their stories too far out of control.
- empath75 7y agoYeah all you have to ask is questions like why did you use A instead of B? Did you run into any problems implementing that? It doesn’t take long before people start stammering and deflecting if they’re full of shit.
- username90 7y agoWhy wouldn't a person be able to answer those questions? You were on the standups, you know whatever issues they had, you were on the design meetings, you know what alternatives were considered and why they weren't chosen. Being able to walk through someone else's thought process is a lot easier than doing the actual work. The end result is that you will hire people for high level roles like tech leads or architect who are very mediocre at what they do since they sound like a star performer at the interview. All you need to get a good career in such an environment is just to job hop a lot and at every job you mostly try to gather impressive things people around you do in order to sound impressive in the next interview. I bet a no small fraction of CEO's went that route, and I think it is a pattern we should avoid since it is so easy to test actual coding skills in tech.
- itronitron 7y agoYou keep mentioning design meetings as a source of technical insight that a person can co-opt as their own expertise. If you steer your interview questions more towards things that are 'solo' in nature then you might have a better job of identifying people that have more software development experience. An example of such a question could be ... can you tell me about a time that you tracked down a bug that you at first thought was not possible but later identified and found a solution for?
- dahart 7y ago> Why wouldn’t a person be able to answer those questions? Why would they? You’re making assumptions. Being in standup doesn’t mean you understand so well you can talk about it. Knowing why good decisions were made and actively making good decisions are two completely separate things. Do you think you’d be prepared to be the lead singer or guitar player for a band if you memorized every note of every song of your favorite band? Would it help if you listened to all their podcasts, read all their books, studied their history? Would it help if you were their roadie or even their manager or producer? The answer is no, being near them and witnessing their output does not equip you to mimic their creative process, or to even understand it. Same goes for programming. > Being able to walk through someone else’s though process is a lot easier than doing the actual work. I’d say that’s true, and is exactly why you’d catch a liar in the unlikely event they made it through the interview process. > All you need to get a good career [...] is just to job hop a lot Yeah, it’s so easy. So do it! You have to keep lying and continue to convince every single company. You’d have to avoid people ever finding out and/or avoid companies calling each other for references. This takes so much effort, it’s literally easier to go to grad school and become an amazing programmer. What is making you think a lot of people are doing all this lying? Are there people around you that you suspect are lying? > I bet a no small fraction of CEO’s went that route, and I think it is a pattern we should avoid since it is so easy to test actual coding skills in tech. Multiple enormous problems with that sentence. CEOs don’t need coding skills, they need organizational skills, sales skill, communication skills and a host of other things, none of which are writing code unless you’re in a startup. (And then CEO is a goofy term anyway.) You’re speculating. If a huge number of CEOs are faking it, then it should be easily demonstrable, so find some evidence. When CEOs fake it, the result is the company goes out of business. It turns out we do avoid this “pattern” because it’s not really a pattern, it by and large isn’t happening, and there are many forces preventing it from happening that you’re not acknowledging. Last but not least, coding skills in tech aren’t the most important. They’re very important, but not the most important. Teamwork, communication, attitude, and goals are all more important than actual coding skills.
- wslh 7y agoYou can discover the lie asking very technical questions on how the solved some issue. They will answer at the greatest level of detail if they did it themselves.
- username90 7y agoNote that we aren't talking about people who can't code, we are talking about mediocre performers who know what they are doing but are still far from top talent. Knowing how to explain a coworkers thought process is not very hard when you have reviewed their design documents and been on every meeting.
- marktangotango 7y agoProvided you or the arbitrary interviewer have the technical background to evaluate the answers! I once had reason to view the resume of a former colleague who took all credit for a major project I implemented. This project involved parsing and a particular parser generator. He worked on it after I implemented it, but he claimed it all. And he was knowledgeable enough to back that claim up!
- smsm42 7y ago> And he was knowledgeable enough to back that claim up! If he worked on it and could convincingly fake it, I - as a recruiter - wouldn't care too much if he embellishes a bit and claims he also did it from the start. Maybe he factually didn't, but if he's good enough to make me think he did, there's a decent chance he would be good enough to actually do it for me. Not a certainty, there's never certainty, but a good chance. Of course, given the choice, I'd prefer the one who actually created it, but one who worked on it and knows it well enough is not bad either.
- palerdot 7y agoThe point is the hiring method attracts people who are both not genuine , to admit that they just jumped in on an impressive project and insecure enough , that they think they should claim everything as their own ... It doesn't matter if they actually possess the technical skill as there might be behavioural issues between this person and the rest of the team.
- smsm42 7y agoThat is a very dangerous gamble though because the next question would be "you did all that? How cool! Tell me more details!" and my experience shows that faking the details, unless you've done at least something very close to what you claim you did, is not very easy. And generic bullshit is rather easy to detect - usually you can see when the person is genuinely talking about something they did and are excited to share and when they're just stalling because they have no idea. Of course, once in a while you can get a bullshit artist of high caliber - but those very quickly reveal themselves when you ask them to actually do something.
- ozim 7y agoYeah... or I have been working on that cool project six months ago and by the time we just have this talk I had a 100 other things on my plate which are not that cool. Then maybe I want to change job because we got new boss that was stressing me out for 3 months and I gave up. So I am rusty on the details and I am also intimidated when you bring in 3 people to have talk about it. I would say it is OK if it works for you but it still might be that you drop off some good guys. Because it is environment that creates good employees, and if someone was working for months or years in a bad environment, he can be perfectly capable of doing work, but not being confident and feeling good about talking about his last job.