What do companies want in a programmer

[TheBeardedQuack]

I've browsed the Jobs section a few times just being nosy but I noticed that even with about 3 years study in C/C++ I haven't got a clue about a lot of what people are talking about or asking for in terms of programming experience.

Anyone have any opinions on what kinds of software development / programming experience / library knowledge / etc, that most companies look for?

I want to be a professional games developer working on my own/small team but I think it'd also be amazing to be able to program as part of a company team for any clients request. (More the want of generalised/specialised programming ability)

[Cubbi]

I can tell you what I'm looking for when interviewing C++ programmers, but we need people with a lot of experience, so it may not apply to your situation with "3 years study in C/C++" (which, by the way?)

I expect familiarity with unix environment, ability to debug (with valgrind/purify, from cores and on the fly), familiarity with revision control systems, unit testing frameworks, static analysis tools, profilers.Not necessarily what we use, but if you used one or two of each category of development tools, it won't take time to learn. On the language front I look for C++ (language including object model and static polymorphism, standard library including allocators, and some boost), nice to have ksh, python, C, Fortran, but none of those is a requirement.I also look for familiarity with multithreading, atomic ops, IPC and shared memory (not "solve the dining philosophers" or "implement a barrier" but what did you use and why)..
For a beginner, I'd say practical debugging is most important. Find yourself an open source project with an active JIRA and fix the bugs.

[N36fSL3A]

Not trying to highjack this topic or anything, but what field is that?
Usually I'm told that I should learn to unlearn the STL, and that it's evil.

[BHX]

Fredbill wrote:

Usually I'm told that I should learn to unlearn the STL, and that it's evil.

Anyone that tells you to unlearn STL is an idiot. Without STL you lose a lot of C++ features (http://en.wikipedia.org/wiki/Standard_Template_Library#Composition ).

@SatsumaBenji
All the times I've sent my resume and portfolio anywhere I was always told I didn't have enough industry experience which is true as I am self taught and never worked for a company. I need to focus on entry level so I can get the experience a few years.

[Cubbi]

Fredbill wrote:

what field is that?

financial industry

[TheBeardedQuack]

Thanks a lot Cubbi for all those suggestions. I have been "looking into" multithreading (only with boost), Unix and Python... But in more kinda "oooh that looks interesting" rather than actually putting time and effort in to learn these topics properly.

I will read up on and practice common debugging techniques and writing testable code, as I've seen some people mention that it's a lot harder to find bugs if your code isn't made in such a way to help you test it.

[N36fSL3A]

BHXSpecter wrote:

Anyone that tells you to unlearn STL is an idiot

Well people who make 90 percent pretty much all of us here look like n00bs are not idiots.

(I'll just back out of here so I don't derail this)

[BHX]

Fredbill wrote:

Well people who make 90 percent of us here look like n00bs are not idiots.

If someone is telling you to avoid STL, they are either trolling you or part of the 90% because no veteran programmer would say to avoid STL. Ignoring STL would just increase your work more and require you to write your own containers, algorithms, etc. You would lose std::vector and a lot of the other useful things STL has that most beginning programmers don't realize they are in fact using STL.

Fredbill wrote:

(I'll just back out of here so I don't derail this)

Technically you already derailed it once with your first STL remark. This just makes twice.

[Disch]

BHX wrote:

Technically you already derailed it once with your first STL remark. This just makes twice.

Hello Pot, have you met Kettle?

[N36fSL3A]

I guess I'll come back then.

Technically you already derailed it once with your first STL remark. This just makes twice.

I actually asked a legitimate question related to the OP.

If someone is telling you to avoid STL, they are either trolling you or part of the 90% because no veteran programmer would say to avoid STL. Ignoring STL would just increase your work more and require you to write your own containers, algorithms, etc. You would lose std::vector and a lot of the other useful things STL has that most beginning programmers don't realize they are in fact using STL.

I think you're wrong.

The Source Engine doesn't use STL a lot if it does at all. (Based on it's actual source code).
I've read that using the STL is frowned upon when making programs in embedded systems. That AAA companies don't use the STL much unless they're forced to, and that writing your own types are favored over using the standard library's for performance concerns.

[Cubbi]

Fredbill wrote:

I've read that using the STL is frowned upon when making programs in embedded systems

Embedded systems have a lot of variety. I spent most of my carrier first working for an embedded RTOS vendor (at which time I've seen all varieties of code our customers ran), then working for one the companies that used the OS. Sure, I had to deal with old code that predated the STL, which used containers and algorithms from one of its earlier competitors, bur replacing it with standard C++ was both a significant performance improvement and made the system portable to much-needed new hardware. On the other hand, I also hear online that there exist embedded systems whose compilers are so underdeveloped that they cannot support the standard library and must be fed restricted code.. haven't had the chance to see first-hand.

[BHX]

Disch wrote:

Hello Pot, have you met Kettle?

You have little room to criticize after spending days debating with a troll on religion in a derailed topic that reached 36(?) pages. I can safely call him a troll seeing as he was banned twice and had two other accounts reported before the thread finally died with him being gone. If he was still here, I guarantee it would still have been going now. Lost track of how many threads mods at the other sites closed because he would ask a question and then argue with the people that answered.

@Fredbill
Everything I've found thus far on STL in embedded systems isn't that they frown on it. They just use a different library that implements STL specifically for the embedded system or the programmer writes their own, or just completely avoids it due to not wanting to mess with it.

For example, EASTL ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html ) is one I see referenced a lot. So I stand by what I said, anyone that tells you not to learn or to unlearn STL or calls it evil are idiots.

[N36fSL3A]

BHX Specter wrote:

You have little room to criticize after spending days debating with a troll on religion in a derailed topic that reached 36(?) pages.

He wasn't debating, he was genuinely interested. You aren't some God (pun intended) who tells everyone what to do with their time and how to spend it. I'm trying to say this the nicest way I can, mind your own business.

If I were you, I wouldn't even comment on that matter based on the things that you've done.

So I stand by what I said, anyone that tells you not to learn or to unlearn STL or calls it evil are idiots.

I'd rather believe a programmer with decades of experience than a relatively new hobbyist programmer. You throw numbers out there, bragging about how much experience you have, but without hard evidence of the works you've made, I'm not going to believe a word you say. These people on the other hand provide numbers, and proof of their work to show.

I've noticed that the STL is pretty bad for static library/dll applications because their implementation depends on the version of the runtime they have. I try to avoid it in my game engine at all costs, only using it temporarily when I have to do something I don't want to spend a lot of time implementing at the moment.

[TwilightSpectre]

In my experience, the STL is very useful and important. Anytime that anyone says that the STL is inefficient, ignore them. Your compiler vendors have most likely spent years with very smart people who know the intricacies of the compiler implementing these things, and its highly unlikely that your lookalike is going to be better (if, in some cases, that is even possible anymore).

The reason that people might say that the STL is inefficient is because the quality of the implementation fluctuates wildly. For example, to do some work with the STL and comparing that same work done in an optimized C-style, the STL could be four times as fast on one implementation and half as fast on another: you never really know.

Another reason might be simply that in some cases hand-writing a container can be more efficient because the you know there are certain conditions that are being kept in place for the data, and you can optimize the container to behave properly in those cases.

I've noticed that the STL is pretty bad for static library/dll applications because their implementation depends on the version of the runtime they have.

This depends on the compiler. For example, for clang you can link to a specified version of the standard library, while of course changes in version of MSVS will of course create non-binary-compatible objects. However, when is this really a problem? Its not like you can compile some files with one version of a compiler and some other files with a different version and expect linking it to work, regardless of whether or not you use the standard library.

Also, with run time libraries, GCC and Clang normally will have you distributing your program along with the relevant runtime libraries required anyway, and MSVS programs will normally have the required libraries installed anyway, and its not like different people have radically different versions of those libraries.

Basically, don't not use the standard library (double negative!) for mediocre reasons. Efficiency isn't normally an issue, runtime libraries make no difference, and its also often a good idea for code readability since people can understand the standard library, they know how it works, and they don't have to work out how your home-grown implementation works, and how they should go about using it.

[CodeGazer]

NT3 wrote:

Anytime that anyone says that the STL is inefficient, ignore them. Your compiler vendors have most likely spent years with very smart people who know the intricacies of the compiler implementing these things, and its highly unlikely that your lookalike is going to be better (if, in some cases, that is even possible anymore).

I wouldn't ignore them all the time because sometimes they are telling the truth. You have to realize that the STL is meant to be a "standard" IE very generic.

In certain cases like in game development (I just chose this because that is what I am familiar with) the STL implementation can be more inefficient not because they are built badly it is just because a custom implementation is built specifically for that problem whereas the STL is meant to be much more generic.

So no I wouldn't ignore them all the time because they are telling the truth sometimes. Though I will agree that most of the time this will not be the case and I am definitely in agreement that you probably should use the STL over custom implementation for the most part unless there is a good reason to do otherwise.

[BHX]

Fredbill wrote:

I'd rather believe a programmer with decades of experience than a relatively new hobbyist programmer. You throw numbers out there, bragging about how much experience you have, but without hard evidence of the works you've made, I'm not going to believe a word you say. These people on the other hand provide numbers, and proof of their work to show.

That is fine, it is your choice and you don't believe a word I say. Though, could you tell me how giving "hard evidence of works" proves 20 years experience? That would only prove I understand the language and gives zero proof of the years I've put into it. Again, it is perfectly fine if you don't believe a word I say because it still won't change my opinion. STL isn't evil, it may have shortcomings on embedded systems, but that hardly makes it evil nor does it make it so you should avoid learning it.

[Ispil]

The irony. It is tremendous right now. "I don't want to get this off-topic." Sure enough, it is now off-topic. First page, too. Bravo.

Anyway, though I lack any sort of industry experience personally, I can say after listening to my father complain about the people developing the software that he uses for work that it is a must that if you are developing a software that can receive tickets for possible bugs that you know how to communicate whether something is or is not a bug. Don't just brush things aside. It tends to... piss off a lot of people.

[NoXzema]

To be honest, I haven't contributed to that many projects which causes people to question my abilities, rightfully so. I can talk big all I want but that doesn't really get people anywhere. Whenever I contribute various snippets to improve a code base overall, they grow to be more reliant on me.

While I don't think the STL is evil, it's good to know some quirks that it may be unsuitable towards. Some people find it unsuitable for extensive unicode support. Some may not be able to pull the correct type of optimization out of a generic STL implementation. It's just a matter of the situation. Also, the upcoming facilities actually make me worry since it's hard to depend on them. Some people still use boost::thread because std::thread is not that well supported by some compilers.

I'm actually interested in how I would fare in a company interview. I wouldn't think highly since I don't have a completed college education and maybe only 3 or 4 noticeable projects (if even they can be considered noticeable) that I've contributed to or created. While I would be able to answer quite a few questions perhaps about any standard, design, or what to avoid, I wouldn't imagine myself being in the top grade.

I'm overly curious, though, about how much my college education has effect on the matter. I've been thinking about going back to a university and putting some effort into it but I'm still rather unsure.

[Lachlan Easton]

Years put in does not a good programmer make.
The STL is avoided in most high end game engines (such as Source as Fredbill and the Unreal Engine)
It doesn't take much googling to find reasons why http://simonask.tumblr.com/post/59763277483/why-stl-isnt-great-for-game-development
http://gamedev.stackexchange.com/questions/268/stl-for-games-yea-or-nay
(top answer)

[TwilightSpectre]

Did you actually read the top voted answer in your stackexchange link, rather than the answer chosen by the person who wrote the question?

kevin42 wrote:

Back when I worked in professional game development, STL was too immature and bloated. But that was >10 years ago.

Now I work in military simulation, which has even tougher performance requirements (like the framerate can never go below some FPS). In military simulation STL is used all over the place.

Some of the people who tell you not to use STL use the argument that it's not always the perfect or even the best solution to the problem. But that isn't an answer to the question. The question should be: Is there something inherently wrong with using STL in games? I'd say no, STL is most of the time a better implementation than what a user would come up with on their own.

Just make sure you know how to use the STL, and use it in your game. Read some books and look at the implementation code in the STL you are using.

EDIT: Some other very valid advice from the same link:

I would say that, off the top of my head, it is a better idea to use the STL unless you know exactly why you don't want to use it.