|
You can't practically validate it. This is why it's important not just to ask about previous results. This is also why you see so many "solve this random programming problem" type interviews - they hope (wrongly) that it's less fakeable and somehow gives you an idea of how they will do in the future. I don't find those particularly useful (like many), i instead try to understand how they think and approach things. If this is a manager, for example, give them real organizational problems you've seen, and ask them how they would approach them, and walk you through their thought process, etc. You will often start to get "weird" answers with fakers or spinners, especially if you start to ask about anything related to performance or improving it (again, in my experience, YMMV, etc). One idle theory (IE i don't claim this is correct in any meaningful way) i had about this was that a lot of the didn't actually know how to help people or organizations, so if you force them to try to explain how they approach it for real, they start to fall apart. Instead of thinking about that stuff, they were thinking about how to progress or spin things for themselves. Meanwhile, good managers often spend lots of time thinking about how to help their people and organizations, and whether they are good or bad or whatever, it's not a topic that tends to trip them up. For IC's, for example, you can get them to teach you something real they learned on the project they claim was a great success, ideally a thing that helped make the project successful. In my experience, this also will lead you fairly quickly to discover if they believe they are smarter than everyone else. The best people i ever found (in retrospect) were usually the ones who would teach me things they learned, but usually not things they came up with. They would teach me something they learned from someone else during the project, but was still critical to the success of the project. Everything in an interview is, of course, fakeable with enough preparation. The above things for sure - but it is harder for people to fake approaches, fake teaching, and spin results successfully all at the same time, etc. You start to get into the "this person is in the 99% percentile of all fakers" kind of thing that is probably not worth trying to solve ;) |
Whether they can code or not isn’t indicative of whether they can get things done. The last time I had an open req last year, the coding part was ChatGPT simple. It was for a green field initiative. I needed to be able to throw any random thing that came up - a complex deliverable - and know they could run with it - talk to the stakeholders, disambiguate the problem space, notice XYProblems, come back with a design and a proposal and learn what they needed to learn with a little direction. I needed a real “senior developer”. Not someone that “codez real gud”.
I actually turned down a “smart” candidate who was laid off from the AWS EC2 service team I think dealing with Elastic Block Storage (EC2 encompasses more than just VMs).
I knew he could code. But he didn’t show me any indication that he could deal with the ambiguity on the level I needed or the soft skills.