Job hunting and programming tests

[Erloas]

Sorry if this gets a bit rambley. Just sort of talking through some stuff I have been thinking about but don't really have anyone that would understand some of it to talk about it with.

Most computer courses that I've been in expect you to pick up languages on your own. The important thing about a class you take isn't so much the language itself but the lessons it teaches in the language ; how to access a database, how to build a data structure, how to do object-oriented design and programming. Once you understand the general concept in one language, you're expected to be able to apply it yourself in others. For instance, if you pick up the Factory design pattern and learn it in Java, you're expected to be able to apply it in Python, Ruby, or C# on your own.

That was sort of what I was expecting but it wasn't really said anywhere in the courses.

You might be surprised. Time Magazine reports that there are a number of up-and-coming cities, including Salt Lake City (#9 on the list).

I'm getting constant calls from recruiters in places like Omaha, New York, Minneapolis and so forth. It's because I have my resume posted on a job site board and it is reasonably attractive.

I knew about SLC, the fact that I can drive there and back in a day for an interview is one of the main reasons I would look there specifically. Denver is the next closest. There really isn't anything where I'm at though. I just liked the thought of living somewhere like Seattle so I figured I would focus my search in those areas. And California is so well known I couldn't rule it out.

So here's my thoughts on getting into the field:
1) Referrals are still the best way to get to the hiring manager. So if you have any friends or relatives or acquaintances in the computer field, now's a good time to ask.

Heck, talk to me in PM and we'll set up an email conversation so you can send me your resume. I don't think my new employer or my old one is hiring entry-level right now, but I'll keep my eyes open.

I knew there were a lot of XiTP and programmers had to be one of them, so I figured I would see what I could find here, both in terms of what to focus on, but also on networking. Been trying with some other companies we work with, but for the most part there aren't a whole lot of high tech companies that we deal with. There are some for sure, but not any that I actually get to deal with.

2) You're at a university? Great! Get down to their co-op program and see if you can get a summer assignment as a software engineer. That'll get you in the door at a company at best, at worst it's experience for the resume.

Being an Online course that is harder. Although I will look at their job boards and see what I can find. I used to live in Phoenix, so I've got plenty of people to help me if I want to go back. Right now though it is really hard to justify giving up good money if I don't have a job already lined up. I'm willing to take a pay cut though, as about the only good thing about the area is the pay is higher than comparable jobs in other parts of the country. And I know that while a programming job will probably start out lower it has a lot more growth, as I'm about capped where I'm at now.

3) Careerbuilder, monster, ziprecruiter, craigslist. Review the job postings and apply through the site (zip recruiter has 1-click apply -- and yes, I got interviews through them). Post your own resume to those sites and allow recruiters to call you. My last three jobs all came through careerbuilder because the hiring manager or recruiter called *me*. I didn't get many bites to applications I sent out, especially to big-name companies, which tend to be slower. But when they came to me, I had much better success.

I get it. My cousin, in ME, said it was really slow for him and then he finally got in a Tesla. He said as soon as that went on his resume he started getting calls all the time and his pay shot up pretty substantially. I got an interview through him at SpaceX but didn't get that one, but that was doing electronics.

And right now my resume/LinkedIn is focused on electronics, more as a technician because that is what my experience is in. So I'm kind of wondering if I should still try for one of those jobs, which I can likely get much sooner, or if I should switch to software right now. I'm really wanting to leave my current job (and we're so backwards and out of date it isn't advancing me at all) so its hard to say which is the best option. Finding an electronics tech job in a high tech company and then gradating from my Masters would be a good option. While it is easy enough to focus a resume in either direction, the LinkedIn profile can't really change. I'm also not sure if I say "I'm working for my masters in Software Engineering" is going to pretty much make every tech job say "well he isn't going to stay here, lets look at someone else." Although specifically for embedded systems they do go together....

For embedded systems specifically, C++ is the common language of choice. For the software engineering industry in general, Java is I think the top language, with C# a strong competitor for companies that use .NET and other Microsoft technologies.

For IDEs, C# is usually done with Visual Studio (because Microsoft), but out of the box it has a lot of shortcomings compared to other major IDEs. Look into ReSharper as a Visual Studio plugin if you go for C#. Java has two really major popular IDEs - Eclipse, and IntelliJ. In my opinion IntelliJ is the better one by far.

I know that MS has a free version of VS out but I haven't actually tried it yet. I know before when I did Java it was with NetBeans. I've been looking at several recently but was at a bit of indecision as to which way to go. I had tried Eclipse and several others, but it was about the same time I was learning Linux so I know I didn't give them all good look.
When I was looking I found that NetBeans did Java and C++ as well as being on Linux and Windows, so I could just use one IDE for anything they might ask me to do. I'm sure there are plenty of others like that too. So I'm open to suggestions.

On to other subjects, if a job involves VBA, Excel, or Access, those are usually huge red flags that the company doesn't have a strong software focus and that any programming job they have will be poorly managed and supported because it's far outside their core area of competence. There are exceptions of course, but it's something to be wary of.

And I really should stop typing and go to work now.

I realize that. i was just trying to say that that is about all I can list as having real world experience in. We're old and out of data in every way. In fact when I started it was still using Access 97 and we at least got it transitions to something a bit newer.

I know I skipped over some stuff but I've read it all, just might not having anything specific for it right now.

[pendell]

And right now my resume/LinkedIn is focused on electronics, more as a technician because that is what my experience is in. So I'm kind of wondering if I should still try for one of those jobs, which I can likely get much sooner, or if I should switch to software right now. I'm really wanting to leave my current job (and we're so backwards and out of date it isn't advancing me at all) so its hard to say which is the best option. Finding an electronics tech job in a high tech company and then gradating from my Masters would be a good option. While it is easy enough to focus a resume in either direction, the LinkedIn profile can't really change. I'm also not sure if I say "I'm working for my masters in Software Engineering" is going to pretty much make every tech job say "well he isn't going to stay here, lets look at someone else." Although specifically for embedded systems they do go together....

Don't forget to check out the contracting market; In that case they don't care if you're not there forever, plus a three to six month gig will definitely spice up your resume. You get your feet wet, they get their work done, everyone's happy.

There are two downsides, in addition to the "have to job hunt again pretty quickly". The first is that contracting typically pays you money and nothing else. No sick days. No holidays. No vacation. If you work, you get paid. If you don't work, you aren't. End of story.

Some people like that lifestyle; I can't say I do.

The other downside is that contracting jobs typically pay corp-to-corp. That is, you have to form your own one-person corporation and you're paid as a subcontracting corp, not an employee.

The good news is that you can command better prices than you can as an employee.

The bad news is that you have to. You're going to have to pay for your own health insurance and so forth. Also, because you're a "corporation", that means you're going to be paying corporate income tax, not employee income tax, and it's a significantly bigger bite.

If you are currently in electronics -- can you get a job in an electronics shop which also does software? I actually work in a shop that does that very thing ... Honeywell Elster . They build electric meters , which requires electronics techs, firmware techs, and software people like me. And because getting a full-time employee in through HR is an absolute nightmare, many managers want to bring you on as a contractor, than convert you to full time once you're inside as an internal person.

The only reason I'm not hitting you up to refer you to a hiring manager right now is that the division isn't hiring at the moment. But you might check out companies like Ltron or GE. Or even Honeywell once they start hiring again.

I'll attest that Honeywell is a great place to work. Sure, it has its share of corporate nonsense, but I've seen that at every corporation I've worked at.

At any rate -- I think your best bet is to sign on with a shop that has both electronics and software, then switch over to software as an internal hire. Once you've got your software chops firmly in place, you can then decide whether to stay at your company (there won't be many people in the world who can do what you do, so you should be able to command reasonable wages and job security) or strike out for somewhere else.

Good luck!

Respectfully,

Brian P.

[Douglas]

I know that MS has a free version of VS out but I haven't actually tried it yet. I know before when I did Java it was with NetBeans. I've been looking at several recently but was at a bit of indecision as to which way to go. I had tried Eclipse and several others, but it was about the same time I was learning Linux so I know I didn't give them all good look.
When I was looking I found that NetBeans did Java and C++ as well as being on Linux and Windows, so I could just use one IDE for anything they might ask me to do. I'm sure there are plenty of others like that too. So I'm open to suggestions.

IntelliJ has support, whether natively or through plugins, for a LOT of languages. C++ is definitely covered, Java is just the highest priority focus. There are also a few different versions built to focus on certain other languages. As for operating systems, it's written in Java so it should theoretically run on nearly anything that can qualify as a developer computer these days. I use it on Windows on my personal machine, and on Mac on my work machine, and they have a Linux install too.

In short, IntelliJ is good at the one-IDE-fits-all thing too. And the Community Edition is free. Here's the IDE products page.

[Erloas]

Don't forget to check out the contracting market; In that case they don't care if you're not there forever, plus a three to six month gig will definitely spice up your resume. You get your feet wet, they get their work done, everyone's happy.

There are two downsides, in addition to the "have to job hunt again pretty quickly". The first is that contracting typically pays you money and nothing else. No sick days. No holidays. No vacation. If you work, you get paid. If you don't work, you aren't. End of story.

Some people like that lifestyle; I can't say I do.

The other downside is that contracting jobs typically pay corp-to-corp. That is, you have to form your own one-person corporation and you're paid as a subcontracting corp, not an employee.

The good news is that you can command better prices than you can as an employee.

The aforementioned cousin is doing that, and at least right now he is making more than enough as a contractor to pay for the benefits and still come out ahead compared to the direct hire jobs he has been offered, even at jobs where he worked for them as a contractor first. Of course he said that wasn't the case until he got the right name on his resume.

The only issue with that is that I'm not at that point yet, I would if I could but at least from what I've tried I haven't had any success.

If you are currently in electronics -- can you get a job in an electronics shop which also does software? I actually work in a shop that does that very thing ... Honeywell Elster . They build electric meters , which requires electronics techs, firmware techs, and software people like me. And because getting a full-time employee in through HR is an absolute nightmare, many managers want to bring you on as a contractor, than convert you to full time once you're inside as an internal person.

The only reason I'm not hitting you up to refer you to a hiring manager right now is that the division isn't hiring at the moment. But you might check out companies like Ltron or GE. Or even Honeywell once they start hiring again.

I'll attest that Honeywell is a great place to work. Sure, it has its share of corporate nonsense, but I've seen that at every corporation I've worked at.

At any rate -- I think your best bet is to sign on with a shop that has both electronics and software, then switch over to software as an internal hire. Once you've got your software chops firmly in place, you can then decide whether to stay at your company (there won't be many people in the world who can do what you do, so you should be able to command reasonable wages and job security) or strike out for somewhere else.

I know Honeywell fairly well, I know they have a decent amount in Phoenix, and I think we toured one of their facilities in college (that may have been on that was cancelled too... hard to remember specifics now).
That would be the ideal situation, its just getting into it that I'm still working on. Not a whole lot of hits on my job searching so far, I even tried a resume writing service, as I know that tends to be one of my weaknesses. I had a friend from college that is living in Seattle and working for a biomed company which would do both, and the same week I asked about anything they might have the CEO sent out an email saying they were on a hiring freeze. Also another company that I work with a lot out at work I had tried to get on as a field service tech, and they also do a lot of software, most likely would have hired me but they are also under a hiring freeze and they couldn't get an exception for me. (not a whole lot of people with 10 years of experience on their monitors and industrial experience... just have to keep following up with them)

At this point I just have to keep refining my resume/LinkedIn and keep trying and see what I can find. Any more there probably aren't a whole lot of companies doing electronics development that isn't also doing programming.
I think the other big problem is relocation. I've heard electronics techs are in relatively short supply but their lower down the priority list so I don't think they look at relocation there nearly as much as they do engineers and programmers. The aforementioned friend in Seattle said I could stay with them a little while, and being there would probably help... but I've got just a few too many bills to give up my job to do it.

IntelliJ has support, whether natively or through plugins, for a LOT of languages. C++ is definitely covered, Java is just the highest priority focus. There are also a few different versions built to focus on certain other languages. As for operating systems, it's written in Java so it should theoretically run on nearly anything that can qualify as a developer computer these days. I use it on Windows on my personal machine, and on Mac on my work machine, and they have a Linux install too.

In short, IntelliJ is good at the one-IDE-fits-all thing too. And the Community Edition is free. Here's the IDE products page.

I'll give it a look. I'm open to everything right now.
Is there a common, or at least one you prefer, GUI API for C++? I can't remember the one Java uses but I know they had one that was basically built in. I could just as easily switch to Java, just want to look at my options, and I don't think I got JDE installed on my new computer before they locked it down so I'm not sure how much Java I can actually run on it.
I know at its base C++ is command line but I can't think of many side projects that I could do that right now that wouldn't use a GUI. I've found a few online but haven't really got any practice with them yet so would like to hear some preferences.

I did use the DX8 or 9 API for one of my senior projects but I don't think DX is the way to go with what I'm wanting to do in the future.

[Erloas]

It shouldn't be an accomplishment to get a piece of sample code to run... but sometimes it is. I've spent an order of magnate more time lately trying to get everything in place just to get things to compile than I have writing any code. I know eventually you get it all worked out, especially if you use the same IDE and APIs for everything. Its still amazing how you can search for a problem and find that other people have been having the same problem for a decade and a bunch of coders don't get it fixed in that time.

Right now its just trying to get GTK to compile on NetBeans in C++, worked through three sets of problems so far... I think I'm close.

edit:
I still haven't been able to get GTK to compile. Everything I've found talks about installing an all-in-one bundle from GTK website, which no longer exists. I tried Code::Blocks too and the GTK project build they have built in is for 2.0, and while I've found a few things that talk about changing it in the script I can't ever get it to work. It seems like the new GTK installation is missing some files.

So after a bit I decided to try Win32 API in Code::Blocks, and I can get that to compile and bring up a window, so that is a big improvement from what I've had. I guess for the time being that is what I'll use.

[Erloas]

I've been liking Code::Blocks quite a bit in the time I've been using it. I'll probably look at NetBeans again once I get the first project out of the way. I figured at some point I had to switch from trying to get the IDE figured out to practicing coding.
I did check out IntelliJ, though the free version is only for Java, the C++ version only has a 30 day trial.

The first assignment in class was to build (or download) Dijkstra's algorithm, research some testing frameworks and apply them to the code.
It took a while to get the rust out and get my data structure set up, and I went through a couple versions, but I think the version I have now is solid.
I don't actually remember using vectors before... I'm not sure if I just mentally tossed them in with arrays or it's use just wasn't that widespread 15+ years ago. (the GNU part of the header gives a copyright of 2001, though an HP and other versions are 94/96 respectively).
It took a bit of fiddling, but I ended up with a vector of a structure that included a vectored structure in it. Getting access to the various commands in each step took a bit of practice but it all seems to be running smoothly now. And then I started the algorithm by passing a pointer to my structure, and finding the syntax to get it to let me use it was a bit of a stumble but I've got that now too.

Maybe not the most complicated thing to do, but it felt good to get it all working after so long away. That part only took one afternoon, all the earlier time was spend messing with GUI APIs and compilers.

[Errata]

I haven't seen that site, but in general I'm a fan of programming tests for hiring software engineers. There are a lot of programmers out there who are shockingly incapable of even simple programming. Degrees from good schools don't prove you can, and prior work experience can be ambiguous without more objective information than we often have access to about how they performed there. Doing a programming test doesn't prove that you'll be a good engineer, but at least it sets a minimum standard for basic competence at programming. Some are meant to be short and pretty trivial, while others are a fun challenge. I can't think of any such programming test I've seen that I thought was unfair to expect a prospective employee to be able to do.

Now, let me guess, if someone makes a reasonable failed attempt but lays their code out clearly and with comments, they are preferred as a candidate to the person who writes code that will work but does not comment it or lay it out neatly?

We fly candidates who make it past our initial interview round out for a weekend and the coding test takes around 4 hours. But if it looks like they're close we'll give them a little more time to finish up. If they're nowhere close eventually we have to shut it down.

Our usual test has a sliding scale of completion. The results are automatically validated with some sample input, and it's possible for your code to perform better or worse on the test data. It's not feasible to come up with a 100% perfect algorithm in the time given. There's a certain score threshold that's generally considered a pass. But if someone has really good code we might cut them some slack on the score. And if they have really horrible code we might not want to hire them even with a passing score.

[Sermil]

It may be different in the programming world, but in my world (transportation/logistics) jobs are only posted and resumes taken if nobody knows anyone who can refer someone in. Most of the people in the office (20-30) were hired because they had worked with someone somewhere else, or knew someone who trusted them enough to say "This person will probably be good at X."

Networking is huge when finding a job, because it lets you skip to the top of the pile - except, perhaps, at HR-straitjacketed corporate behemoths.

Oddly enough, in over 2 decades as a software engineer, I have never actually been hired via referral. Always just been "I saw your job posting X on website Y...". I think I'm a bit of an outlier, though.

[Douglas]

Oddly enough, in over 2 decades as a software engineer, I have never actually been hired via referral. Always just been "I saw your job posting X on website Y...". I think I'm a bit of an outlier, though.

I have a bad habit of being lazy with my job searching. I only get away with it because of how little I tend to spend, resulting in lots of money saved up to tide me over, and how in demand my profession is. I'm a software engineer too, btw.

My first major job post-graduation came from the company seeing my résumé on monster.com. My second came from a recruiter contacting me on Linked-In, based on a recently set up profile with very bare bones information. As I recall my profile had my name, my degree, my profession, my previous employer, and that I was looking for a job. And zero connections, and nothing else. My current job I actually did apply to, but I hadn't applied to many.

In software engineering companies do usually want referrals, and often offer multiple thousands of dollars in bonus pay to anyone who provides a referral that gets hired, but the bulk of hiring usually comes from job postings or public recruiting. I think it's because the profession is in such high demand, especially in the upper ranges of skill, that very often the people who might be referred are already well employed and happy where they are.

[Deadline]

I'm currently running an application development shop for a state government agency, so keep that in mind with regards to my advice on the job market of today. I've done the contractor/consultant life, and it has its benefits and drawbacks. The big benefit is pay (I still make less now than I did as a consultant), but you all too often find yourself living out of a suitcase in hotels, traveling constantly, and never knowing if you'll have a new job or contract to jump onto after your current one is complete (so you wind up having to also become a salesman). The travel was initially a bonus, but once I met my wife, got married, and we decided to start a family, being a weekend husband and father wasn't going to work. From there I did a number of things - attempted to start my own .com company (this was before the whole .com bust), worked for another software startup (as a salaried employee, those 14 hours days can kiss my rear), and even wrote and sold some custom software to local companies. I wound up landing a job with state government, and I've been here ever since.

Fast forward 14 years (egads, time flies), and I'm now running the shop. I've been part of development teams for every major system here in that time. Over all my past and current experience, I've found that the ability to write code and create effective algorithms is only a fraction of being a successful developer. Being able to relate to customers and work with them to help them discover their needs and iron out their processes, those are key to success as a developer. These are often referred to "people skills" or "soft skills", but they are incredibly important. I don't think I've ever been in a position where I or any developer I've worked with was ever just fed specifications and produced code. You have to be able to connect with people, explain things in ways they can understand, and help them take ownership in the process. A successful developer can not only write solid code, they are skilled communicators as well. You may even find that in a senior developer role you wind up being a system architect or project manager in some cases (personal quibble: don't slavishly adhere to a given PM process either - they are tools like any other, adapt them to work for you). The ability to move among those roles is huge. That adaptability is what we look for more than anything else. So if you've already got a decent foundation in writing code, I'd recommend focusing on those "soft skills".

The transition to management rather than developer is one that I'm not certain I'm in love with, but here I am regardless. I've had plenty of experience with our recruitment processes, as well as a hand in shaping some of it. I have to admit, I'm in agreement with kyoryu about these programming tests. We've tried it off and on, and all too frequently we've found it just doesn't tell us enough about the applicants. All you really need is to be able to write good, functional code. Anything too complicated and you can either mentor with a senior developer who has those skills, or quite often look it up online. For reference, my last batch of interview questions didn't ask anything about programming at all. There were about ten questions, asking things like "Please describe a project that you have been involved with that did not go according to plan. Please describe what went wrong, your contribution to correcting the problem and any lessons learned." The only time I get into asking specific programming questions are if I don't see much in the way of development experience on their resume, or something about it strikes me as odd.

Aside from that, I'll echo everyone else with regards to the various online options you've got for finding employment. I've had Linked-In personally recommended to me by several developers I've met as a solid tool for getting your information out there as well. And if you don't have any relevant experience on your resume, look into internship opportunities. Those frequently require no experience, and can be a great way to flesh out your resume.

[Errata]

Over all my past and current experience, I've found that the ability to write code and create effective algorithms is only a fraction of being a successful developer. Being able to relate to customers and work with them to help them discover their needs and iron out their processes, those are key to success as a developer. These are often referred to "people skills" or "soft skills", but they are incredibly important.

My parents were both programmers and eventually technical managers for government agencies, so the description of your workplace sounds very familiar to me. However, programmers can fall into the trap of working at particular types of jobs and then assuming that the entire software industry is like those jobs. But it's very diverse and there are many different types of programming jobs with vastly different requirements and standards.

In my industry, there are field engineers whose entire job is to have a combination of soft and technical skills and interface between customers and developers. They have computer science degrees but never write a line of code, just figure out what's necessary and help smooth out problems on customer sites. Whereas the developers virtually never talk directly to a customer. In 18 years I've spoken directly with maybe 10 customers. It's just not part of the job. Most customers are hundreds or thousands of miles away. The field engineers have to travel regularly within their geographic regions for problems that can't easily be resolved remotely, but developers almost never travel for work. Field engineering is a fine job, but it's not "better", and if you enjoy developing software, you probably wouldn't like it as much, because you don't get to do that.

In my industry, the requests from customers can usually be boiled down to something very simple. After the field engineers and salespeople have had a few back and forth discussions with them, it usually ends up as a requirement that can be described in a paragraph or so. Often all we really need is some sample input (which can take some time to get into a usable form, but in the end is very straightforward), and it's pretty self-evident from that how the result is not ideal and could be improved from a usability/efficiency standpoint. However, even though it's easy to describe how the behavior could be better, it's very hard to figure out exactly how to make our product do that thing. The developer needs excellent computer science skills to actually implement what is a very simple request to describe. The customer and field engineer have no idea what it would take to make it happen, only the developers do, so soft skills are not the priority for our developers. We have to be very selective because not every programmer can do the job, and you can't just look up how to do it on the internet.

So yes, in some industries, being able to navigate complex algorithms is highly valued, and those employers need to hire carefully, because someone whose instinct is to try Googling it or asking a coworker is probably not going to last long (it's fine to try those things, but you need something to fall back on because it won't always work). In some industries you'll basically be doing minor variations on things that thousands of people have done before you, so looking it up is an extremely viable option and possibly better than reinventing the wheel if it's sufficiently standard. But in other, more specialized workplaces, you might be coding something that only 5 or 10 people on Earth have ever done, and all their solutions are copyrighted and/or not available to you. From time to time, you may even get to innovate something sophisticated that literally nobody has ever done before, and if you can't do even the simple types of problems on coding tests, a job where you need to do that is probably out of the question for you.

[Anthony222]

Well, as digital technologies have been developed rapidly, competition in IT industry has increased. Recently I've found the article that incudes tips on how to hire the most experienced C++ developer - https://diceus.com/hire-c-plus-plus-developers-ukraine/. Frankly speaking, I was one of those people who predicted a soon downfall of this language. But having read that post and surfed the Internet, I've found out that C++ developers are still highly needed, mostly because it is not easy to find a person who can rewrite the working code of the product developed in C++ into another programming language. In short, I'm not surprised that it is difficult to get a good job in IT industry as employers look only for the experienced programmers.

[Errata]

Your link treats C and C++ as separate languages, which is odd. C++ is almost, (though not 100%) just a superset of C. Projects that use these often have modules compiled in C or C++ mixed interchangeably, and usually the compilers will support mixing them with no trouble (as long as you use extern "C" or whatever for interfaces). If you treat C/C++ as one language, they're solidly in first place, and the second place language, Java, is very closely related. The things that make Java different from C++ are also some of what make Java unsuitable for certain types of development.

Not everyone writes web pages or apps. For many types of system programming, C/C++ is the gold standard and that shows no signs of changing. People still start brand new projects with it all the time, it's not some dusty old legacy language. In my industry hardly anyone uses anything else. For my personal preference, I tend to write code that is technically C++, but using a relatively C-like subset of the language unless I will get a tangible benefit from object oriented features. I avoid templates like the plague, though they're not always avoidable when interfacing with other people's code.

Even if you ARE writing apps, your site suggests that 3 different languages are used for 3 different types of phone. But if you want to write portable code that you can deploy for any type of phone, you don't want to write it in 3 different languages. C++ is a perfectly reasonable choice that can be compiled efficiently to run on any of those mobile devices. If you want to develop graphics for them, OpenGL is a standard graphical interface that you can port to just about any computer or device, and C is the native language and most natural way to interface with it. A LOT of important open source software is in C/C++.

I think it's common for rookie programmers to ascribe far too much significance to the programming language they use. And then they naturally want to write code using whatever flavor of the month niche language they learned because of some minor perceived advantage over similar languages. But the language is generally pretty low on the list of important factors in software development. When you learn your first language, it seems like a lot of effort, but most of that effort was actually learning the underlying programming concepts and not that one specific language. New languages will get easier and easier, until switching between them is not a big deal. Being interoperable with an existing code base and any third party code that you may some day need to interface with is far more useful than whatever minor conveniences an obscure new language might offer.

[factotum]

Your link treats C and C++ as separate languages, which is odd. C++ is almost, (though not 100%) just a superset of C.

Yeah, but the philosophy behind the two languages is rather different. Yes, you could write a C++ program without using any of its unique features and end up with something almost identical to a vanilla C program, but that's not how you're supposed to use the language.

[Errata]

Yes, you could write a C++ program without using any of its unique features and end up with something almost identical to a vanilla C program, but that's not how you're supposed to use the language.

What you're meant to do are just guidelines. People can end up causing themselves a lot of self-inflicted grief with the overuse of C++ features, and each new revision (11, 14, 17), just makes it easier to go down the wrong path. By committing to strict C, you give up a lot of potentially useful features for no real benefit. By using C++ but not committing to intensive use of every possible C++ feature, you leave your options open. You can still use C style where it makes sense, but with the option to use encapsulation, inheritance, polymorphism where it makes sense and will improve the organization and/or reduce the redundancy of your program. There are no language police who will get on your case for not fully embracing every aspect of C++ at all times.

[Deadline]

My parents were both programmers and eventually technical managers for government agencies, so the description of your workplace sounds very familiar to me. However, programmers can fall into the trap of working at particular types of jobs and then assuming that the entire software industry is like those jobs. But it's very diverse and there are many different types of programming jobs with vastly different requirements and standards.

True, but speaking as both someone who works in the government industry now, and used to work as a software consultant at the turn of the millennium, the opportunities for a position where one only writes code and doesn't have to interact with clients is small. And from everything I've seen, it's getting smaller. That being said, being able to write code and interface with a customer is going to vastly increase your potential job opportunities. For reference, there is a single position in my agency who only writes code and doesn't generally interface with clients. It's just rare. I have 30-40 positions that require both.

I'd be keen to know how the industry is trending on this. In most places I've seen, any shop that is big enough to have both isolated developers and staff who interface with the client is looking to cut their costs. They do that by either outsourcing their developer staff to cheap labor foreign countries, or by seeking staff who can fill both roles as needed.

Admittedly, if we are talking software development that isn't business software, then I don't have any experience in that arena. If we are talking about highly specialized scientific applications, then I could see it being a better fit.

And I generally do look for folks who have relevant developer education/training when I hire, for reference. I can generally be assured that someone with, say, a CS degree probably has a solid foundation to fall back on when it comes to developing a solution. But in the business world, I'd be hard pressed to name any field where you have to be a world-class developer to get the job done.

Edit - I also wanted to point out that the job opportunities where you get to write a brand-new application from the ground up are also more rare than those where you maintain existing applications and write software to integrate existing systems together.

[Errata]

I can generally be assured that someone with, say, a CS degree probably has a solid foundation to fall back on when it comes to developing a solution.

I disagree. That's not been my experience at all. A CS or CE degree is a bare minimum to interview someone, but a high proportion of CS graduates don't seem to have a very solid foundation at all, which is one reason that programming tests can be an important data point. A degree, even from an excellent school, isn't sufficient proof that they can actually program. And even work experience can be ambiguous without more context.

They do that by either outsourcing their developer staff to cheap labor foreign countries, or by seeking staff who can fill both roles as needed.

If you're of the opinion that the software you're writing is easy enough that anyone could do it, then yes, outsourcing makes total sense.

And yet, that's not what's happening. US software companies are not cutting back on US staff or cutting industry wide domestic labor costs. What is actually happening is that Software Engineering salaries keep rising faster than inflation, notably during the last recession in which most other sectors stagnated. Outsourcing is only a good option for simple and repetitive tasks. US Software companies are demonstrating through their hiring practices that many of them value talented people and are willing to pay for that.

As for hiring people who can fill multiple roles: If you have a relatively consistent full time workload for many people traveling to customer sites and interfacing with customers, and a never ending workload writing software that will take man-centuries to complete, then no, having people split their time between the two and do an overall worse job on both is not a cost savings. Specialization of labor is crucial to the modern economy. As long as there is a steady supply of work to keep them busy, then a workforce composed primarily of specialists has proven far more efficient than an equal number of jacks of all trades trying to do a little of everything.

[Deadline]

I disagree. That's not been my experience at all. A CS or CE degree is a bare minimum to interview someone, but a high proportion of CS graduates don't seem to have a very solid foundation at all, which is one reason that programming tests can be an important data point. A degree, even from an excellent school, isn't sufficient proof that they can actually program. And even work experience can be ambiguous without more context.

A fair point on the degree, but it doesn't have to be the bare minimum to interview. A solid work history demonstrating knowledge of the skills you are after is also a good starting point. The hard truth on the hiring process for a developer is you won't really know how they'll work out until after you've already hired them. My issue with programming tests is that most of the really good developers I know wouldn't pass said tests. And the test just isn't going to give you all that much useful info about a developer. Using a test as a data point in the hiring consideration is one thing, using it as a barrier for entry is entirely another. You don't need hard barriers to entry unless the people doing the hiring have no idea what they are hiring for. And if that's the case, you need to re-think your hiring process.

If you're of the opinion that the software you're writing is easy enough that anyone could do it, then yes, outsourcing makes total sense.

Again, I have to ask just what kind of software you think makes up the majority of the market out there? Barring some super specific scientific software, most of the software on the market doesn't require rockstars to write and maintain. Obviously you don't put rookies on their own writing highly important or sensitive sections of code (things like user auth, secure transactions and the like), but software development is most assuredly not some exclusive club where only the best of the best are courted and hired. If you are trying to liken, say, Google and its hiring practices to what the majority of companies are doing, I think you are doing yourself a disservice.

So I suppose I'll have to add a caveat: If you are looking to get a job at one of the big names in software development, then my advice will be less useful. Those big names have highly talented people lining up to work for them, because of the prestige associated with it. That means that if you aren't the best of the best, you probably won't get hired.

Regarding outsourcing, I'll just point out that Software Developers have always commanded a higher salary than other fields (though I would need to research more on how that increase is trending), and outsourcing for software development is also on the rise. I'll also point out that the skillsets you get when you outsource for software development are not as bad as you seem to think they are.

As for hiring people who can fill multiple roles: If you have a relatively consistent full time workload for many people traveling to customer sites and interfacing with customers, and a never ending workload writing software that will take man-centuries to complete, then no, having people split their time between the two and do an overall worse job on both is not a cost savings. Specialization of labor is crucial to the modern economy. As long as there is a steady supply of work to keep them busy, then a workforce composed primarily of specialists has proven far more efficient than an equal number of jacks of all trades trying to do a little of everything.

Specialization of labor is crucial to the modern economy, this is true. But you are overvaluing it when considering things from the perspective of people who are looking to get hired. If you are highly specialized in a specific area, that works great when there is someone who needs that specific thing. Broadening your skillset means more job opportunities, which in turn means a much easier time landing a job. It also means easier mobility when the thing you are specialized in goes away, but that's pretty rare.

As a last point, I do really appreciate you sharing your viewpoint on this. It's always good to hear from other folks in the field. If you are able to share the info, I'm extremely curious as to just what your field is where you are working with such highly specialized skillsets.

[Errata]

Barring some super specific scientific software

There are a lot of fields you're overlooking. You dismissed Google as irrelevant, but they have around 20k software engineers, so they have as much weight on the job market as hundreds of individual small companies. Google isn't the only big company, and there are many, many small companies with high standards that hire from the same pool of people as Google or the like, often either losing employees to Google, hiring them away from it, or simply interviewing the same candidates. Particularly around Silicon Valley, but by no means limited to it, there are many companies that aim high. Most programming tests should be fairly trivial to people with strong computer science fundamentals, which includes most people who hope to work in a place like that.

The more selective companies writing more demanding and innovative software tend to be the ones that pay better. And even if they represent 10% or less of the job market, they'd also tend to be toward the upper percentiles of compensation. It's worth attempting to qualify for those jobs if you can.

Specialization of labor is crucial to the modern economy, this is true. But you are overvaluing it when considering things from the perspective of people who are looking to get hired. If you are highly specialized in a specific area, that works great when there is someone who needs that specific thing. Broadening your skillset means more job opportunities, which in turn means a much easier time landing a job. It also means easier mobility when the thing you are specialized in goes away, but that's pretty rare.

There's a huge difference between specializing in a specific field vs. having almost entirely unrelated core skills. A new computer science graduate doesn't necessarily need to know exactly what type of programming they're going into before they start, as long as they have a strong general foundation and are willing to learn. However, the type of generalization you were talking about before isn't even about programming, but wearing two hats, that of a developer with the soft skills of a business development person. Two things that often don't go together, and really don't need to go together to fill a useful role. If you're naturally good at and enjoy both, then maybe that kind of bridge between those roles is your calling. But normally it makes more sense to have most employees fill one role or the other, not try to hire a bunch of people to all fill two roles each. There is plenty of work out there for people who are simply very good at programming, so I don't agree with the advice that at a certain point you should stop trying to get better at programming and focus on being good at some other thing. That may open certain doors, but it will also close doors at companies that are picky about finding strong programmers.

As a last point, I do really appreciate you sharing your viewpoint on this. It's always good to hear from other folks in the field. If you are able to share the info, I'm extremely curious as to just what your field is where you are working with such highly specialized skillsets.

The field I work in now is specific enough that it's almost personally identifying, particularly if cross referenced with any location clues that might appear in other threads. So I wouldn't mind going into details, but would rather not post it in a searchable forum. However, I've received job offers in completely different fields, some of whom I'd never heard of before they reached out to me. There are a lot of very selective companies out there that you may not think of immediately, but who are doing interesting things and need good programmers.

[Sprütche]

When this thread started I signed up in Hackerrank. I did a lot of the practice stuff from the easy category and some from the medium category and I took part in a few competitions.
My results are good compared to a lot of other competitors but poor overall. In the recent competition I finished in the top twenty percent but I only got less than 60 of 375 points. My solutions often work for the first few test cases but they time out when the big ones come.
My background is in mechanical engineering so I lack the formal knowledge in computer science. What do I need to learn to write faster code? I keep running into divide and conquer, greedy and dynamic programming but the books I looked at did not cover much of it. Does anyone have any reading recommendations? I guess getting familiar with the libraries is important.

[Errata]

My background is in mechanical engineering so I lack the formal knowledge in computer science. What do I need to learn to write faster code? I keep running into divide and conquer, greedy and dynamic programming but the books I looked at did not cover much of it. Does anyone have any reading recommendations? I guess getting familiar with the libraries is important.

I found the free CS50x online course from Harvard to be an excellent resource for people starting out. If you've gotten as far as you have, it sounds like you've already gotten past the introductory stage. However, if so you should be able to breeze through the redundant parts pretty quickly, but there are parts of it you may find very helpful. They go beyond a lot of other intro courses in terms of showing you alternative algorithms for solving the same problem in more efficient ways. They give you a good foundation in how to evaluate and classify the performance characteristics of different algorithms, which may be part of what you need to figure out why your solutions aren't scaling well on larger data sets.

[Douglas]

When this thread started I signed up in Hackerrank. I did a lot of the practice stuff from the easy category and some from the medium category and I took part in a few competitions.
My results are good compared to a lot of other competitors but poor overall. In the recent competition I finished in the top twenty percent but I only got less than 60 of 375 points. My solutions often work for the first few test cases but they time out when the big ones come.
My background is in mechanical engineering so I lack the formal knowledge in computer science. What do I need to learn to write faster code? I keep running into divide and conquer, greedy and dynamic programming but the books I looked at did not cover much of it. Does anyone have any reading recommendations? I guess getting familiar with the libraries is important.

For that kind of issue, the big thing is Big O performance characteristic. It's a pretty simple concept, really: If you change the size of the input, what happens to the run time?

A quick example, what happens with something like this:

for (int i = 0; i < n; i++) {
    for (int j = 0; j < n; j++) {
        for (int k = 0; k < n; k++) {
            for (int l = 0; l < n; l++) {
                // do something in here
            }
        }
    }
}

That's a loop inside a loop inside a loop inside a loop. Well, for an input of size n, the innermost loop does something n times. The next loop up does that entire loop n times, for a total of doing something n * n times. The next loop up, with j, does all of that n times, and finally the outermost loop does the j loop n times. Overall, this ends up doing something n * n * n * n, or n⁴ times, which makes it O(n⁴).

Now, if you graph n⁴, you'll see that it shoots up really really fast. This is bad. It means that increasing the size of the input even a little bit can make your program take a lot longer to run. Oh, and what if the "do something" bit involves calling a library function? You have to account for the big O performance of that library function too. If the library function is O(n), then that's yet another factor of n which makes your code even worse at O(n⁵).

Of course, understanding the concept is good but it doesn't actually help without knowing how to apply and use that knowledge. I'll give some examples, going from best to worst.

O(1): Also called "constant", something with this performance will take the same time no matter how much input there is. This is not usually possible to achieve for anything non trivial. Certain data structures have been devised that do most or all of their individual operations in constant time, though, and you should make yourself familiar with them and their usage. For example, a hash map or hash set can add or remove elements in constant time, check whether a particular element is already in it in constant time, and (for a hash map) retrieve the value associated with a key in constant time.

O(log(n)): Logarithmic performance. You get this with a "divide and conquer" algorithm if after dividing the problem into two you only ever have to do one of the two sub-problems. The classic example is a binary search. If you have a sorted list and want to find something in it, you check the midpoint to find which half of the list it's in, and then search just that half - by checking that half's midpoint to find which quarter of the list it's in, and so on.

O(n): Linear performance. If you double the size of the input, you double the program's execution time. A simple loop, where the contents of the loop run in constant time, gets this. Two simple loops, one after the other, not one inside the other, also gets this. You might think that should be O(2n), but for the purpose of big O notation that 2 is meaningless. Adding another element to a fixed size array, where you have to first resize and copy the entire array, is O(n).

O(n * log(n)): This is just called by what it is, "n log n". You get this with a "divide and conquer" algorithm if after dividing the problem into two you have to then do both of the sub-problems. Most good sorting algorithms have this performance, and it's not possible to sort any faster without certain extra problem-specific conditions.

O(n²): Quadratic performance. You get this with a loop inside another loop, with both loops running a number of iterations proportional to the input size. It's fairly common for a novice writing their own sorting algorithm to end up with this, several of the most obvious ways to sort a list naturally result in a loop inside a loop.

O(n^x): Cubic, quartic, etc. This general class of performance profiles is called "polynomial". Whichever value x has, this performance is usually achieved by having x loops nested inside each other. If you find you're getting into this territory, above quadratic, take a step back and re-evaluate whether there's a better way. Cubic or worse performance is pretty bad for most problems. There are problems where it's simply not possible to do better, but I wouldn't expect HackerRank to use such problems much.

O(2ⁿ): Exponential. You get this with things like an exhaustive search through all possible combinations of values for n elements. "What if everything is a 0? Ok, what if everything's a 0 except the last element which is 1? Ok, what if it's the next-to-last element that's 1? Ok, what if both of the last two elements are 1? etc." This is worse than any polynomial performance, no matter how bad the polynomial's exponent. O(2ⁿ) will, with high enough n, be worse than O(n^1000000).

O(n!): Factorial. This is even worse than exponential. You get factorial performance with things like an exhaustive search of all possible ways to re-order the input elements.

There are of course things even worse than factorial, but they rarely come up in serious discussion.

To pass test cases with large input sizes, you need to learn to recognize each of these, evaluate the big O performance of your own code, and figure out ways to move your code from one big O class to a better one. I haven't done any public tests or competitions on HackerRank myself, but I would guess it's usually possible to get at least quadratic, if not better.

[Errata]

I haven't done any public tests or competitions on HackerRank myself, but I would guess it's usually possible to get at least quadratic, if not better.

That's a good standard for most real code. You certainly don't want to do worse than that for things that could scale, and for some things quadratic code is going to be your bottleneck. However, at least for programming contests there are some exceptions to this. I'm not familiar with that particular site, but one of the tools I've found most helpful to master for programming contests is the iterative deepening depth first search. Problems that can be solved in that manner seem to come up fairly regularly in some form or another, so if you can learn to knock one of those out quickly it can be easy points. I think technically it might be considered exponential. However, I find it's common for challenges to include graph problems where exponential time is the best you can reasonably expect to do, certainly within the constraints of the limited time you have to program a solution. Even though it's not really a fast algorithm in big O terms, it can be guaranteed to identify an optimal path within a reasonable maximum amount of time, while a regular depth first search could spend an indefinite amount of time and would likely not be an acceptable solution for all data sets.

[Sprütche]

Thank you for your input.
That CS50 course looks good. I will work through it.
I am familiar with the Big O notation, at least for solving systems of equations. I wasn't aware there are so big differences in the data structures. I work mostly with normal vectors or arrays so that's next on my list.
And i am definitely guilty of the loops within loops stuff. I know it is slow, I just don't see better ways often.
Sorting is a good example. Some of the n² solutions I thought of myself but none of the n*log n solutions.

[Douglas]

I am familiar with the Big O notation, at least for solving systems of equations. I wasn't aware there are so big differences in the data structures. I work mostly with normal vectors or arrays so that's next on my list.

The primary motivation behind most commonly used data structure designs is to get a better class of Big O performance for one or more specific operations - add, remove, index, replace, check contains, lookup, resize, find max or min, etc. - and in some cases do it with constraints such as maintaining sorted order at all times. There are a lot of cases where two data structures do exactly the same thing, just with different Big O for various operations. Usually it's a trade off.

It is very common for a data structure's documentation to specify the Big O performance of each operation. Learn the major ones, and in each program figure out which operations you will need to use a lot and choose a data structure with good Big O for those operations. "Good" is usually constant, or sometimes log n. There are some data structures that accept log n for something where constant is possible in order to bring another operation from linear down to log n or to make a constraint (such as "always sorted") possible to satisfy.

Arrays have constant time indexing and setting/replacing. They're pretty crappy for anything else, with linear time for pretty much everything besides indexing and replacing.

And i am definitely guilty of the loops within loops stuff. I know it is slow, I just don't see better ways often.
Sorting is a good example. Some of the n² solutions I thought of myself but none of the n*log n solutions.

Divide and conquer is your friend. Think, is there any way to, in linear time or better, split the problem into roughly equal sized smaller versions of the same problem? That's how n*log n solutions are typically devised, for any problem.

[aspi]

My background is in mechanical engineering so I lack the formal knowledge in computer science. What do I need to learn to write faster code?

If you have a relatively solid background in Math, the MIT Introduction to Algorithms lecture is really good - and it's a free video lecture.

I'm not familiar with that particular site, but one of the tools I've found most helpful to master for programming contests is the iterative deepening depth first search. Problems that can be solved in that manner seem to come up fairly regularly in some form or another, so if you can learn to knock one of those out quickly it can be easy points. I think technically it might be considered exponential. However, I find it's common for challenges to include graph problems where exponential time is the best you can reasonably expect to do, certainly within the constraints of the limited time you have to program a solution.

Depth first search (and especially iterative deepening depth first search) is actually one of the fastest running algorithms for graphs, which is why it is so popular. For the kind of graphs that you will encounter in most application scenarios, it actually has a linear runtime. The complexity you are likely thinking of stems from the size of the graph that you are searching: as a classic example, you could be searching for an optimal chess move based on a given board state. While the depth first search through the tree that encodes future game states is very efficient, the size of the tree is growing exponentially due to the number of possible moves in each turn. So even if the algorithm is linear, it still can't save you from the sheer size of the problem space that you are searching.

[Errata]

Depth first search (and especially iterative deepening depth first search) is actually one of the fastest running algorithms for graphs, which is why it is so popular. For the kind of graphs that you will encounter in most application scenarios, it actually has a linear runtime.

If you have a graph with hundreds of nodes, and the optimal path through it passes through around 20 of them, then a naive implementation of a depth first search might spend weeks systematically digging through every permutation before deciding on the best one. A much faster approach would be to run it looking for paths no longer than 10, then no longer than 12, 14, 16, 18, 20, etc. In this case it would succeed at 20, and then you wouldn't have to consider the astronomically larger portion of solution space that consists of answers length 50+. So in practice this can be a huge savings.

This is important, because if it's a challenge scenario, they're absolutely going to trip you up with this. They may give you a small example of input to test your code with, and your regular depth first search will appear to work fine. But then when they throw a larger data set, your solution will run for far too long and be killed. It will spend forever in some irrelevant corner of solution space rather than homing in on the far more reasonable solution that you actually care about.

This isn't a theoretical thought exercise, but something I've encountered on multiple occasions when participating in programming contests. Some form of search problem constructed in a way that an exhaustive search will get you into trouble, but iterative deepening is a very simple way to fix the obvious pitfalls that is really not significantly more difficult to code.

If a search of every path through graph is "linear" but just happens to be linear on the number of possible solutions that grows exponentially with the number of nodes, that seems like a grey area at best. Big O notation is a useful analysis, but it's not going to tell you everything you need to know about performance. And it may be that a linear search through the entire possible solution space may be far too slow to be a practical option for some problems, which will be important to understand if you encounter a problem like that.

[NichG]

For that kind of issue, the big thing is Big O performance characteristic. It's a pretty simple concept, really: If you change the size of the input, what happens to the run time?

...

There are of course things even worse than factorial, but they rarely come up in serious discussion.

To pass test cases with large input sizes, you need to learn to recognize each of these, evaluate the big O performance of your own code, and figure out ways to move your code from one big O class to a better one. I haven't done any public tests or competitions on HackerRank myself, but I would guess it's usually possible to get at least quadratic, if not better.

This reminds me of the worst thing I've ever seen in terms of a quantity mathematicians asked to be calculated for things. If I recall correctly, the scaling was something like O(e^e^n!), due to needing to do multiple nested exhaustive searches over graph partitions (for a given 'outer' partition, you would then find the 'inner' partition of each of side of the partition which would maximize something, then you'd find the 'outer' partition which minimizes that thing, and the thing itself was actually nontrivial to compute even given the partitions).

But it can be approximated in O(n^3), so...

[GeorgePresson]

C++ has been a popular general purpose programming language for many years. Recent developments in microcontroller technology (such as ARM Cortex-M), increasing application complexity and enhancements made in the C++ 2011 standard mean that C++ is now replacing C as the preferred language for many embedded systems.

This course teaches the C++ programming language in the context of real-time and embedded systems. It highlights the resource and performance implications of using key C++ features and programming styles. As well as giving delegates an in-depth understanding of the C++ programming language, this course provides practical experience of programming a modern embedded microcontroller using real-time development tools. It is a direct replacement for a general class in C++ programming, with the added benefit that the syllabus, contextual examples and exercises are tuned to the requirements of the Embedded System and System-on-Chip communities.

Although C++ for Embedded Systems focuses on the C++ language features that are appropriate for "bare metal" systems or those using a Real-Time Operating System (RTOS), the course is also suitable for anyone wishing to learn C++ to develop applications within an Embedded Linux environment – C++ features such as stream-based I/O that are generally only used with complex operating systems are included in an optional module that can be presented if there is sufficient time and interest.

The workshops are based around carefully designed exercises programming and debugging a real embedded system to reinforce and challenge the extent of learning, and comprise approximately 50% of class time.

C++ for Embedded Systems is aimed at electronic hardware, software and system-on-chip engineers who need to gain a working knowledge of the C++ language to build an embedded system. The course is also suitable as a general introduction to C++ programming, particularly for anyone working in an electronics-related business area or with a background in digital electronics.

[jay103]

C++ has been a popular general purpose programming language for many years. Recent developments in microcontroller technology (such as ARM Cortex-M), increasing application complexity and enhancements made in the C++ 2011 standard mean that C++ is now replacing C as the preferred language for many embedded systems.

Now we know what happens when a post-bot hits the "no links can be posted by new users" restriction. Sounds like a homework essay for a first-year CS course.