I worked with a TON of them
We have effectively brain-drained the whole country
They talk a good game, can recide from memory the C# syntax, but can’t code for $hit.
I interview with a ton of these guys. Whenever anyone asked about some obscure c# class or attribute I say “I don’t know what that is, I’ve never had a need to use it” and then if they act all superior I ask THEM about some obscure code that I have used and how they would adapt it to accept data from a hardware device connected to a serial port.
I swear hardly any of them knew how to make an event handler to handle process the input. And the ones that did prcessed it a character at a time, until I asekd them about data coming in at 128kbaug and how they would refresh the screen after each character....
They KNOW what a mutex or semaphore or monitor is, but when asked how to apply it in that situation they have no clue.
The place I was at before this gig was full of them. Their code was was so complex and convoluted for what it did. They had layers upon layers of classes that had one line of code or method in them. We’d hit a problem and they would immediate want to create yet another class that would basically check a value and set a flag. They said it was better to have lots of small single purpose classes over having a couple of static utility classes to handle stuff like that since that “was the agile way, you know one class one purpose”. I would just smile. The freakin’ stack trail was sometimes over 30 layers.
Another stupid thing they would be checking Windows credentials in almost every single layer in the business logic. I was like so you think the login is going to change from process to process in the same session? And they wondered why their code was so slow sometimes. But like you said they could recite syntax and spew textbook definitions of terms.