3 ms·

Anecdotal but we've hired an engineer who was pretty decent in the interview but couldn't figure out how an if statement worked in a legacy codebase. Yes, I wr

Anecdotal but we've hired an engineer who was pretty decent in the interview but couldn't figure out how an if statement worked in a legacy codebase. Yes, I wrote that right. He struggled to understand conditionals in general when building his own logic. The guy even had a masters degree.

bakuninsbart 7y ago
So I had the same problem for a while, it was quite absurd, because I got through my uni courses, could decently code in Haskell and some other things, but never figured out the appropriate position to put an if clause. I then did a course on assembly programming and having to be extremely structured and using jump statements actually helped me a lot in easier to use programming languages. Point of this comment is that people might be good at a lot of things, while just having some weird brainfuse related to a very specific thing. That said, not using if statements makes programming rather difficult.
- sieabahlpark 7y ago
  No see I wish they had any redeeming skill, he always asked an engineer to assist him with anything. They couldn't figure out anything on their own. It was shocking someone could complete the interview (small problem with a solution that is essentially explained, make x do y) and completely fail at building their own solutions without guidance
dorfsmay 7y ago
Can you elaborate? What did he do or say that made you think he could do the job even though it looks like he wasn't able to work with other people code?
- DavidWoof 7y ago
  Not OP, but there's a group of people who have essentially a good manager's understanding of a project. They understand the trade-offs, they can talk intelligently about technical choices and architecture, and to some degree can even talk about individual modules and classes and language choices. But they blank at code and struggle with the basics. They get lost for hours at the most trivial bugs. It's weird, but it's very real. Real coding takes a certain kind of abstract thinking that some people just don't have.
  - LanceH 7y ago
    I have (half?) jokingly said that hiring could be done by selecting people who try to right click something when confronted with a windows task they don't know how to do.
  - mixmastamyk 7y ago
    I’ve known many smart IT folks that say they don’t or won’t code more than a batch script.
Jach 7y ago
We had an intern once who struggled with initializing a new object at a root component's initializer in file A, passing it down to the initializer in a child component in file B (required adding to a dictionary object also in A), and extracting and passing it down again to a child-child component's initializer in file C (required adding a new argument to that function, either the param itself or a dictionary object to follow convention) and extracting it for use there. Later I realized the issue was the person's prior experience had been on small programs, mostly written entirely by themselves, and thus they were able to keep them entirely in their head. Since then all my technical interviews try to additionally answer "can you reason about and make changes to code you didn't write, whose entire body is big enough you can't fit it all in your head at once (at least in the amount of time we have)?". A few times I've used a variant of the exact problem I described (of what's ultimately passing data to some nested functions) using simplified code from our codebase. I use a different problem most of the time now, regardless of level, but it's still about modifying existing code and using existing objects rather than cooking up something from scratch.

bakuninsbart 7y ago

So I had the same problem for a while, it was quite absurd, because I got through my uni courses, could decently code in Haskell and some other things, but never figured out the appropriate position to put an if clause. I then did a course on assembly programming and having to be extremely structured and using jump statements actually helped me a lot in easier to use programming languages. Point of this comment is that people might be good at a lot of things, while just having some weird brainfuse related to a very specific thing. That said, not using if statements makes programming rather difficult.

sieabahlpark 7y ago
No see I wish they had any redeeming skill, he always asked an engineer to assist him with anything. They couldn't figure out anything on their own. It was shocking someone could complete the interview (small problem with a solution that is essentially explained, make x do y) and completely fail at building their own solutions without guidance

dorfsmay 7y ago

Can you elaborate? What did he do or say that made you think he could do the job even though it looks like he wasn't able to work with other people code?

DavidWoof 7y ago
Not OP, but there's a group of people who have essentially a good manager's understanding of a project. They understand the trade-offs, they can talk intelligently about technical choices and architecture, and to some degree can even talk about individual modules and classes and language choices. But they blank at code and struggle with the basics. They get lost for hours at the most trivial bugs. It's weird, but it's very real. Real coding takes a certain kind of abstract thinking that some people just don't have.
- LanceH 7y ago
  I have (half?) jokingly said that hiring could be done by selecting people who try to right click something when confronted with a windows task they don't know how to do.
- mixmastamyk 7y ago
  I’ve known many smart IT folks that say they don’t or won’t code more than a batch script.

Jach 7y ago

We had an intern once who struggled with initializing a new object at a root component's initializer in file A, passing it down to the initializer in a child component in file B (required adding to a dictionary object also in A), and extracting and passing it down again to a child-child component's initializer in file C (required adding a new argument to that function, either the param itself or a dictionary object to follow convention) and extracting it for use there. Later I realized the issue was the person's prior experience had been on small programs, mostly written entirely by themselves, and thus they were able to keep them entirely in their head. Since then all my technical interviews try to additionally answer "can you reason about and make changes to code you didn't write, whose entire body is big enough you can't fit it all in your head at once (at least in the amount of time we have)?". A few times I've used a variant of the exact problem I described (of what's ultimately passing data to some nested functions) using simplified code from our codebase. I use a different problem most of the time now, regardless of level, but it's still about modifying existing code and using existing objects rather than cooking up something from scratch.