How would you know if someone you were working with was a good software engineer?

#1 I have learned only a little so far of the software engineer's role in a team, but I do know that with any job it requires the constant ability to being able to adapt quickly when changes are needed, its the same concept in nature as well.
If I was given the choice of a software engineer, I would look for someone that would be willing to make the effort to create a simple workflow for everyone, this would get the work environment moving. This would also mean that the concept of adaption would apply to the entire team of artists and programmers.
There will be modifications that will need to be made in any project as it progresses and you can't have anyone in the team, no matter how seemingly important, become a piece of sandpaper every time a workflow change is implemented.

#2 I think that it depends on a lot of different factors. One might be what role is the Software Engineer playing? Architect? Lead Developer? User Experience? Scripting? etc. Or is this just a general purpose developer?

Another factor I think is in the Project Manager and Business Analysts. Even the best developer can fail if the direction is poor.

My best experiences as a Software Engineer have been where the requirements and design were created for me, however I was still able to provide technical input about what is feasible and what might be better. Also when I am in a team where there are other developers that are above my skill level and some that are below. I think that no matter how much info the internet or books have there is no substitute for experience. I always learn more when I have someone else to question and someone to ask questions of me.

I think that the only way in general to answer your question is the same way I would answer the question of who is a "good" <anything>. Someone who is passionate about the field, and has a desire and capacity to learn. The other part would be based off of what starting point experience wise you want them, a passionate Junior Developer is a "good" developer assuming you want them for the Junior Dev slot.

#3 For any type of design I would implement some kind of design review. If you could not fill that role you may need another qualified developer to fill that role. I am kind of biased as I come from a EE design field. We incorporated design reviews to determine if what we were attempting was feasible. This becomes critical when dealing 480VAC motor controls or human protection from moving parts. Software can kill in those situations.

I would also look at the code itself: is it commented, does it look neat and follow best practices for the language in use, is the logic easy to follow or is it a mess of coding tricks only a PhD in CS can comprehend? Is the code divided up logically into submodules where appropriate? Do they use some sort of version control to track changes? Do objects follow a hierarchy or are they complex mess of interconnected dependencies? Is there a master design document to track changes by contributors?

One good test is this: When a change is made does it break a bunch of other stuff? It is does then I would hazard a guess that the software was built like a house of cards. House of Cards = Bad Design

#4 All that knocked me sideways hahahaha.... A few of them I realised eventually but the majority of the information I was given here I had no clue about. Going around fumbling like an idiot I was.

All the info has helped greatly and is much apprectiated, thank you.

-----

The whole thing though regarding having/expecting someone to adapt vs enforcing certain coding procedures/standards which change like the wind is still quite puzzling to me.

Are coding standards an attempt to ensure that there is some order to allow it to mould into discipline rather than hacking away?

I heard many programmers/engineers relate it to snobbery or on the other side of things the proper way to do things (which in reality seems to be based on what people's preferences are).

#5 Coding standards are more about making sure that everyone is writing code in a similar fashion so that the codebase maintains readability. It also allows certain assumptions to be made about someone else's code when they write a class or functions that you're making use of it. If they forgot to comment some things, but they followed the rest of whatever standard their team agreed on then you can know what to expect from functions and variables based on their naming.

Every programmer has a slightly different style of doing things. Some love Hungarian notation (why they would is a mystery), some prefer camel casing for everything and some don't. If you have more than one programmer in codebase then things can get messy real quick if there isn't some kind of agreed upon standard.

#6 Cheers Scott, that cleared up the issue for me. Take care.

Thank you to the community, answers and views are much appreciated.