IT/Software career thread: Invert binary trees for dollars.

Well if you work with and know the developers at your current company that's a plus right off the bat. Networking will help you immensely if you decide to try to transition. It's also good to have someone you can ask questions too who has real world experience and knowledge. Not to mention they might have some books and other reading/learning materials to lend you.

Working in IT doesn't really translate to software outside of the aforementioned. Also, financial software is an entirely different beast than your traditional managed code software shop so keep that in mind if you do ask around at your current job.

I work with a ton of people who are ex bank employees and they've never said it is much different except for the culture at banks is far, far worse and you make more money.

Most software development interns are simply QA testers and maybe write novelty apps to assist with testing. You don't really go into the project and make any significant contribution. At least every intern I've ever worked with (or as) has been that way.

For me (Hiring manager) if your skill is ok but your eagerness and curiosity is high then you get a small Yes from me (small/big Yes/no). If you got a lot of skill then it's a big yes from me.

One of the first things I think to myself is "Can I see myself directing this guy to what he needs to do? Is he/she someone I would like to work with everyday?" if you're going for an intern position chances are I'm gonna have to manage you much more than a Software Engineer I or II, so it means you pretty much have to become my shadow and if I don't get a good impression or you don't seem eager to learn (and stop being my shadow) then you're not going to cut it.

Software job interviews are based more for the position than anything. We don't give out the same tests/questions to everybody, if you come in for an internship most of the interview is going to be about your culture fit, and what your passion is all about (with some IT/coding questions). If you come in for a Software Engineer II position then most of it is going to be IT/Coding.

Here they like to challenge interns and see how far they can let them go. For instance, when I was an intern I took a real eagerness to learn things by viewing specs, schematics, other people's code, etc. They started me with small automation/testing tasks and gradually built me out from there with finally me working on production code. When my co-op officially ended, they offered to keep me on as a standard intern in another firmware group (POST). I was further challenged and essentially was working on production code for my entire duration. It started out as small things like fixing menu text, or things that were running out of bounds, but eventually it turned into me working on major projects where even my boss didn't know the answer and simply told me "read the spec."

On the other hand, we have this co-op who has been here three times so far (co-op contract with his school) and is basically terrible. They gave him one bug fix in his first group and it took him his entire duration to fix it. They simply didn't add anything to his plate and that was it. Now he's in our group (BIOS) and his code is horrendous. You can tell the dude doesn't learn anything and clearly does not pick up on the general overall coding style of the group (lowercase var names, strange conditional statements). He's challenged as far as he puts forth effort, and it's not much.

I think in general when we hire interns/co-ops we're looking for someone who has a passion for what they do, an eagerness to learn, and the ability to be ok with doing some of the mundane. We aren't looking for people who are superstar coders, and that's been said by bosses here many times. What you learn in school isn't going to necessarily prepare you for what it's like in the real world. It will give you a good foundation, but most of what you learn will be on the job - and most managers recognize that.

The best way to contribute to a team is to listen, be a knowledge sponge, and ask questions frequently.

Here they like to challenge interns and see how far they can let them go. For instance, when I was an intern I took a real eagerness to learn things by viewing specs, schematics, other people's code, etc. They started me with small automation/testing tasks and gradually built me out from there with finally me working on production code. When my co-op officially ended, they offered to keep me on as a standard intern in another firmware group (POST). I was further challenged and essentially was working on production code for my entire duration. It started out as small things like fixing menu text, or things that were running out of bounds, but eventually it turned into me working on major projects where even my boss didn't know the answer and simply told me "read the spec."

On the other hand, we have this co-op who has been here three times so far (co-op contract with his school) and is basically terrible. They gave him one bug fix in his first group and it took him his entire duration to fix it. They simply didn't add anything to his plate and that was it. Now he's in our group (BIOS) and his code is horrendous. You can tell the dude doesn't learn anything and clearly does not pick up on the general overall coding style of the group (lowercase var names, strange conditional statements). He's challenged as far as he puts forth effort, and it's not much.

I think in general when we hire interns/co-ops we're looking for someone who has a passion for what they do, an eagerness to learn, and the ability to be ok with doing some of the mundane. We aren't looking for people who are superstar coders, and that's been said by bosses here many times. What you learn in school isn't going to necessarily prepare you for what it's like in the real world. It will give you a good foundation, but most of what you learn will be on the job - and most managers recognize that.

The best way to contribute to a team is to listen, be a knowledge sponge, and ask questions frequently.

Interns are treated better then employees at my company. Similar to Noodle

Functions are supposed to be broFist() man.

I was never really a C++ coder and it took me forever to learn that for whatever reason many C++ coders prefix their member variables with an underscore. I never quite learned why.

Deathwing_sl said:

They get paid more than 300k? Can I come intern for you?

I always prefer "int broFist" or "int bro_fist" for variables, "int BroFist()" for functions.



That, I haven't seen much. I thought that was a Microsoft thing to make their code as illegible as possible.

Click to expand...

=p No, I'm talking about better then our Junior non-interns.
The Highest-Paying Internships - Forbes
See #2.

My pay this year was an outlier due to grants vesting

Deathwing_sl said:

Capitalization is for function names, you heathen.

Click to expand...

Bro I write in C, about as low-level as you can get, adhering to the UEFI spec, working with legacy code from god knows when, I just follow what everyone else does

Yeah I feel I am quick to adapt to that stuff. We do have a coding requirement document somewhere that outlines this, but essentially every word is capitalized with the exception of global (OH NOOOOO) variables that have a lower-case character in front.

The intern just did everything mixed, however he felt.. and someone signed off on it..................

Vinen_sl said:

=p No, I'm talking about better then our Junior non-interns.
The Highest-Paying Internships - Forbes
See #2.

My pay this year was an outlier due to grants vesting

Click to expand...

It almost sounds like many of those are expecting competent developers and just calling them interns. Possibly for the sake of trying them out and very easily killing their job without any legal ramifications towards the company since you were just a 6 month intern or whatever.