My experience: * out of college people remember theory, cannot code. * mid-level engineers start to forget theory, can code, begin system-wide design. * senior engineers can design, forget how to code.
If the position of senior engineer expects hands-on coding (mine does), coding exercise during interview is quite revealing (sadly). Personally I do not believe in engineers who cannot code.
The question is, how to distinguish one who can get up to speed quickly from one who cannot.
In the end, there are expectations of the engineer, and expectations of the company. If the candidate is super-rusty, question is, why? For extended period of time this engineer did not code, and apparently was comfortable with it. Would such a person be happy in the environment, where 50% of the time goes to direct development (remaining 50% -- mentoring, project management, etc)? Note, I wrote development, not coding. But writing technical docs is not development either.
There are lots of critical skills and qualities for which there are no simple tests. For example, an excellent mentor could level up all those around them and provide far more value than a great programmer with weak interpersonal skills. In the end, it's a gamble.
It is signal for me. My interview consists of many areas beyond coding. But coding is one I explore too. (like write a methods with two sequential loops and single if in your favorite language.) You would not believe, some 30% people fail.
Mentor or programmer -- we need both qualities in the end. both extremes are harmful. To be a good mentor, one need to have respect of colleagues -- and it comes from contribution too.
gamble -- agree again.
I tried to highlight most common problem I see during interview, not judge specific people, or even less people category.