What are some challenges when you are a engineer?

• Biggest challenge is to accept the reality of the real world- that knowledge and talent are not everything.


• Not every theory that you have read during your education will work in real life situations.


• Being a part of the office team. So as to get better results and growth.


• Working with the people is more important than your core work.


• Understanding your personal finance.


• Exploring possibilities and finding solutions.

Start enjoying your job everything falls in wright place.

1) Make a plan based on actual observation of problem and generate data to confirm issue.
2) Use problem solving tools, fish bone digram, and make sure you have all/any process in current system listed.
3) Consult with other team members who actually do the job, take note to use in potential solution
4) DO NOT have any preconceived ideas about how to solve, just observe, you are a blank slate
5) Must be willing to go and see for yourself and the collected data is accurate
6) Solution must have consensus with team members who will help implement solution (VITAL)
7) Try solution with team members and collect data to see if problem solved (confirm solution with collected data)

Becoming an engineering itself is a challenge and then comes the diversity of complications post completion . What is more important is your thirst in execution , if you become an engineer just because of seeing someone or if someone have suggested you to chose it as your career then better analyze the suggestion for yourself and then make a final call but if you want to become an engineer solely possessing an area of interest in technology , processing , manufacturing , construction and designing you should go for it . And one simple thing when it comes to challenge , challenge is everywhere but "Survival of the Fittest" is the key to success .

Engineers make the world go around and have a good grasp of data around whatever they work on.
This helps you understand gaps and plan for product and needs for a service or instrument you are designing.
challenges around getting a good data that helps you prove your design and hypothesis is challenge every engineer will face.

Need for continuous education
Managing frustrations
Make sure you listen to your peers
Determining a career path
Job transitions
School vs. Real world

Becoming an engineering itself is a challenge and then comes the diversity of complications post completion . What is more important is your thirst in execution , if you become an engineer just because of seeing someone or if someone have suggested you to chose it as your career then better analyze the suggestion for yourself and then make a final call but if you want to become an engineer solely possessing an area of interest in technology , processing , manufacturing , construction and designing you should go for it . And one simple thing when it comes to challenge , challenge is everywhere but "Survival of the Fittest" is the key to success

CS takes a more balanced approach between theory and application while IT focuses more on application
CS offers you an opportunity to learn variety of topics related to computers. IT offers you an opportunity to discovers innovative uses of those fundamental concepts.
CS generally require a decent background in math while use of math in IT is limited to data analysis / processing / statistics, etc
You may call IT as one of the sub-divisions of CS, however there are certain things that are unique to IT like integrated programming, system administrations, maintenance, etc.
While these differences exist on paper, in India the line of difference between IT and CS courses is very blurry.

Here are the similarities :
None of them involves hardwares. You may have to take one or two courses on digital systems where you will study about ICs and logic gates. That’s it. You won’t learn how to repair computers in any of them.
Most of the courses offered in both the branches are related to programming. You will have to program on a daily basis in both the branches.

There is more to the solution - in the real world - that just the solution.

It is easy (comparatively) to design the optimal solution. To design a solution that has buy in from senior executives, has a proper return on investment, can fit within IT's production time line, is simple to use, and still fulfills the customers needs (which is not necessarly what the customer wants - wants rarely equal needs) is an entirely different task.

If all you can do is "number engineering" you will forever be relegated to a cube crunching numbers. If you really want to be part of the decision making process, you will need to develop interpersonal skills, presentation skills, accounting skills, and good business acumen as well as your terchnical engineering skills.

Relating Requirements and Architectures. It is clear that architectures cannot be directly derived (by refinement or other means) from a requirements specification. On the other hand the identification and elaboration of a suitable architecture are not independent of the requirements it must serve. The relation runs both ways with the architecture acting as a framework for the elicitation of requirements and shaping the space of possibilities that are afforded by the system. This complex, intertwined, co-development of architecture and requirements lies at the very core of software development and though we observe it, we do not understand it.
2. Moving to ‘Evidence-based’ Practice. For the most part our existing state-of-practice is based on anecdote. It is, at its very best quasi-evidence-based. Few key decisions from the choice of an architecture to the configuration of tools and processes are based on a solid evidential foundation. To be truthful, software engineering is not taught by reference to evidence either. This is unacceptable in a discipline that aspires to engineering science. We must reconstruct software engineering around an evidence-based practice.
3. Engineering Scalability. Increasingly we are required to build ‘Internet-scale’ services that must handle very large and rapid variations in the demand for resources. Existing practice is poor. We have some high level patterns for limited classes of application. Mostly, the best answers we can offer are resource profligacy, throwing hardware at the problem, or 'suck it and see', basically putting up a system and systematically fixing it each time it falls over. It is unclear to me whether our existing mathematical and analytic tools are able to give us purchase on scalability.
4. Addressing Semantic Divergence. We operate in a context where standards for modelling and information exchange are very important. Unfortunately software engineering standards, principally promulgated by the OMG, and web standards, principally promulgated by the W3C, have been moving in different incompatible directions. The idea that the (semantic) representations at 'run-time' should be different to the (semantic) representations at 'development time' seems to me wrong, wasteful of effort and profligate of technical opportunity. We need to address this.
5. Confident Estimation. We are very poor at answering the first question that any client asks: 'how much is this going to cost me?' We cannot reliably predict the cost/effort required to build a system. We may be fortunate and have built a very similar system before in which case we can make a rough guess, otherwise we are clueless. Function Points, the state of the art, are precious little assistance. Other estimation schemes only work for small systems, relatively ‘late’ in the process. Software economics needs a radical rethink. We need to integrate cost into software engineering in a fundamentally new way.
6. Engineering the Cloud. We know how to build Software-as-a-Service (SaaS) applications. Sort of, see my reservations about scalability. We don’t however know how to: buy it, manage QoS (Quality of Service) or achieve interoperability among SaaS offerings. SaaS is not simply 'yet-another-software-architecture' it is bound together with a set of new business models that require an engineering response.
7. Building ‘Apps’. Apps have fundamentally changed how services are likely to be consumed. Fragmentary, highly-tuned, device-specific interfaces that bridge across to SaaS with managed data ‘sync’ to keep context, are becoming a very important development target. Not least because a viable payment model exists. We have only scratched the surface of the engineering challenges: app stores, app management, app assembly or composition, all require attention.

8. Developing ‘Adaptive’ Systems. We have problems building systems that must exhibit robustness to a changing environment; problems building systems embedding significant COTS/Community Sourced independently evolving components; problems building systems that involve user scripting and ‘plug-ability’. In short, problems building the sort of systems we are called on to construct all the time. We need to develop engineering models and methods for assembling software systems that can dynamically adapt to context and can ‘account for themselves’.
9. Reconstructing Governance. I have been struck by the tendency in software engineering for us to repeat our mistakes. More specifically to repeat mistakes that we understand are mistakes and which we possess the knowledge to avoid. We are driven to this, I contend, by misalignments at the boundaries between business and software engineering that is at the point where business value and the requirements of an engineering process collide. This is the domain of governance, which is poorly understood and little studied.
10. Rethinking Software Production. Software development is no longer garage ‘design and make’. Most software products and services are embedded in a network of complex inter-product and inter-supplier dependencies. Software is the result of the operation of a 'supply chain' that must be designed and forms part of an 'ecosystem' that must be accommodated. Rethinking software production requires a new discipline of business model and software system co-design.

The most important factor that you need to know that what you study and the work that you do might be completely different. While studying engineering you might be more in to the theory , but as a professional engineer , you have to be more practical and need to put more input and make sure that your suggestion reaches everyone
If you decide to be a computer engineer make sure that you have knowledge of additional programming along with the one you study in college

I found that it is fun to work with more people than working alone, and it is always helpful to find and work with others who have different skill sets than you.

Here are some of the biggest challenges engineers have encountered in the course of their careers.

1. Need for continuous education

David Brady, Professor, Imaging and Spectroscopy, Duke University:

I have always had to work to keep learning new things. Engineering is always changing and one has to keep fresh skills.

Martin Brooke, Associate Professor, Duke University Department of Electrical and Computer Engineering:

Outsourcing of engineering work overseas and the need for continuous education have radically changed what engineers in the USA do. Engineers need to be prepared to change around what they do and learn new skills at any age.

1. Managing frustrations

Hal Babb, Lockheed Martin Fellow, Lockheed Martin:

Not enough time, talent, or money to pursue the dreams of the time.

1. Make sure you listen to your peers

Pamela Bhatti, Assistant Professor, Georgia Tech:

I am very application oriented and sometimes different from my peers. That being said, it’s important to listen to your peers and get along — they often have something very useful to say and want to work with you.

Engineer Challenges 02
Power industry career. (Image via Tennesse State University)

1. Determining a career path

Carter Burks, Senior Electrical Engineer, Lockheed Martin Missiles and Fire Control:

Each new role has required me to constantly reassess where I’m going and where I want to be five years from now.

Indira Negi, New Devices Group, Intel Corporation:

A role that wasn’t well matched with my skills and interest…slowed down the pace of my growth. It is really important to find a job that you love, or at least really like.

1. Profound responsibility

Jatin Mehta, Senior Electrical Engineer, Lockheed Martin Missiles and Fire Control:

You quickly find yourself working long hours and working on weekends, and it becomes a challenge to achieve a good work-life balance.

1. Communication

Gisele Bennett, Director of Electro-Optical Systems Laboratory, Georgia Tech:

Communication skills between engineers and scientists are sometimes challenging. My advice is to be as clear as possible in communicating.

1. Coping with rejection

Amanda Foo, Propulsion Manager, Lockheed Martin:

My biggest obstacle was overcoming the expectation that hard work equals rewards and recognition.

How to combat this:

Determine what you’re doing wrong; ask for feedback, and change.

Abigail Kuchan, Lockheed Martin Engineer:

One major challenge was learning how to cope with rejection — not being selected for a job or having my ideas turned down — while continuing to put my best foot forward.

Engineer Challenges 03
Assistant electrical engineer at work. (Image via electricalengineerjobs.org)

1. Job transitions

Phil Cheng, Systems Engineer, Lockheed Martin:

Transition means having to adapt to new people, learning new skills and possibly a change in work location. Adjusting can be a challenge, but it gives the engineer a chance to learn about an area they might never have known about and to develop new mentors.

1. Being a female

Abigail Kuchan, Lockheed Martin Engineer:

Being the only female in a group of men is a challenge, but it’s important to realize that people who don’t respect you because you are a female are the exception and not the rule.

Not all women feel gender is a challenge:

Julie Kramer, Orion Chief Engineer at NASA, says she was very lucky because when she came on-board at NASA 27 years ago, she was taken under the wing of “the old Apollo guys” that treated her really well and no different just because she was a woman. According to Kramer, NASA is more concerned with “who’s best for the job,” not gender.

She does admit that several of her colleagues in engineering school felt they were treated differently because they were women, though.

1. School vs. Real world

Brian Foy, Lockheed Martin Engineer:

Engineering in the classroom is very different from engineering at work. The problems you solve at work do not have one well-defined, universally correct answer.

What challenges have you come across that should be on the list? Tell us below.