A large company virtually guarantees a wide variety of work.
There is almost certainly a job that you will enjoy at Boeing if you are willing to dig for it.
While the pay is average, the benefits are actually pretty good, particularly the 401k match.
Many systems (both hardware and software) and processes have not been updated since well before the turn of the century, haven't been maintained, and are barely holding together (duct tape and chewing gum is only a slight exaggeration).
As a result, you are going to spend way more time than you need setting up anything hardware-related. It was not unusual to spend hours setting up for 10-15 minutes of testing, and that was if you could get the hardware working at all.
Any requests to management to fix these issues will fall on deaf ears. Either the program does not have the time or budget for it, or it's clearly not an issue and you just need to work more hours to compensate.
The majority of programs seem to always be millions over budget and years behind schedule. In addition, there is rarely consensus from the powers that be over the priority of work. As you might imagine, this does not exactly create a calm workplace that is conducive to doing your best work.
The company's age can also lead to a bit of an old boys' club in certain areas, where if you haven't been there for at least a decade, don't bother; your opinion will not be taken into account.
Pay is a bit on the low end. A first-year engineer at Google will make about the same as an end-of-career senior engineer at Boeing.
Work towards repairing and updating the tools and equipment that software engineers need to complete their work, and be willing to act on issues that are brought to your attention.
Gaslighting an employee by telling them it's a non-issue (especially when they can show you how many hours are wasted) doesn't help anyone, and claiming you'll look into the issue only for it to never get fixed isn't much better.
Not bad, but since the software test is in pen and paper, you should practice pseudocode and not cheat. Interviews are now in the post-AI era, where companies use it extensively or not at all.
Though it was pre-recorded, there was one behavioral question, one coding question, and one recording of you explaining your solution. The question was impossible, and I later looked it up to see it wasn’t actually solvable.
Three engineers interviewed me at my university during a career fair. Two were mechanical, and one was a DevOps engineer. They introduced themselves and asked me some questions. Overall, it was very relaxed.
Not bad, but since the software test is in pen and paper, you should practice pseudocode and not cheat. Interviews are now in the post-AI era, where companies use it extensively or not at all.
Though it was pre-recorded, there was one behavioral question, one coding question, and one recording of you explaining your solution. The question was impossible, and I later looked it up to see it wasn’t actually solvable.
Three engineers interviewed me at my university during a career fair. Two were mechanical, and one was a DevOps engineer. They introduced themselves and asked me some questions. Overall, it was very relaxed.