We have an intern I'm struggling with. He grasps process well enough. "Do this and then that and then record the output." What he doesn't get is the feedback loop of understanding the output and using it to change the input. Engineering isn't process, it's more trial and error. I find it frustrating not for him but for myself. I can't figure out where I'm failing as a mentor. I can't really believe he can't get it, and since he isn't getting it, there must be something I'm not explaining. Communication failures work both ways. What am I not doing right? It's also exhausting, trying to find new ways to explain the same concepts again.
Some people are just terrible engineers they go through all the copy and paste motions and can enter data but cant interpret it or understand where the output is or isnt applicable. Those people either become manager or get relegated to roles where they cant do much damage. I figure if 4 years of schooling hasnt drilled in the idea that just punching numbers into a tool is a bad idea then I'm not going to make any progress in the next two months. It always surprises me how many terrible engineers there are out there. I always felt that most of the people in my engineering classes were really sharp but then I meet all these engineers that dont even understand basic concepts like tolerances and it just makes me sad.
You're right, and I've known other engineers who struggle to apply concepts and are much more comfortable just taking direction. I really wanted him to succeed, and he just isn't. While I've worked with others like this, maybe it's my first time training someone who doesn't pick up the concepts.
Success in engineering school is all about reading engineering problems. Success in engineering is all about writing engineering problems. I had a real inferiority complex in engineering school because everyone was always better than me... then we got to capstone design and these mutherfuckers didn't know how a doorknob worked. And, once shown, they couldn't take it apart, put it back together or repair it, let alone draw it or modify it. Sometimes you can get the unimaginative to grasp the issues of the boundless story problem by getting them to find the bounds. Iteration is a matter of understanding that the solution of the problem is the conditions of the next problem until you no longer care about the outcome. Sometimes.
I don't think a door knob is an example of a simple initiative designed. It's a really common object but it's actually quite complex and it likely not something most people could describe much less draw. I bet if you asked 100 engineers to draw a scketch of a door knob working mechanism you would get 90-95 different designs that look nothing like a door knob does
Your backyard furnace would be the kind of thing that would get you hired over another candidate.
If it were me, it's a story I'd remember for the interview. You're right that it might not fit for a programmer, but it might. It shows problem solving skills and a personal interest in learning new things. Sorry about bringing up a difficult topic.
That's pretty badass. How'd you keep the oxygen out?
And I think success in engineering school is about learning how to solve a problem where the method is given and the result is unknown. In my experience, in practice engineering is knowing the answer and then figuring out how various methods prove (or just as often disprove) that answer. I've tried this, and "unimaginative" is a good description. I had one success on Monday with "(blank) didn't have any effect" (which was the correct observation). Then today when trying to coax him into an observation he went back to "I could try (blank)." I'll have to think about why that didn't work.Sometimes you can get the unimaginative to grasp the issues of the boundless story problem by getting them to find the bounds.
Yep, it seems like most things go the road of "well, x is what I want/needs to happen given our current equipment/business processes, but y is what is currently happening. How do I get to x?" What about something along the lines of asking him to come up with multiple possible solutions, and then asking him to rank them with reasoning? Kind of promotes more typical problem solving and might indirectly lead him into the wonderful world of some basic principles of risk and project management.
Perhaps something you could try is getting him to explain back to you, in his own words, the concepts you just explained to him. Not only does this force him to process the information on another level, but hopefully it should give you a clearer picture of the things he's not understanding. As kleinbl00 said in a post of his a few days ago: the best way to learn something is to teach it. If you can get the intern to 'teach' the things he's currently not getting, it might go some way to helping him progress.
I've tried this a bit without stopping to think about it. Maybe I could ask him to write down instructions on doing this analysis under the guise of "documenting for future interns." It might help him think more about the why of his work. Thanks, I'll give this a try.
I had to look up the Socratic method, but I don't think it would make much progress. It isn't that he's doing things wrong or has wrong ideas, he's just trying to do without trying to understand.