Job Market

This is a very interesting thread.

My C++ experience is limited to a 15-credit certificate program (of which was one C course and one C++ course), and 1 year of professional development.

I couldn't answer any of mikeblas questions posed in this thread.

I wanted to make two points:

  1. I feel like C++ is the most difficult language to master. Assembly and C have been around longer, but C++ introduces OOP, and with it, many more layers. This is compounded by the fact that we're still dealing with C++ code that's 30 years old. That's 30 years of different styles, templates, and #defines. Maybe I'm jaded because I'm working with the Win32 API, but looking up HKEY to find PHKEY to find *KEY to find ... is difficult to wade through (and to remember), and old concepts that linger like FAR POINTER don't make it any easier--and that's just the tip of the iceberg.
  2. The thread heavily emphasizes direct C++ knowledge--but what about style? If someone writes code that's difficult to understand and maintain (with no comments), how does that compare to someone who writes code that's easy to understand and full of useful comments? Of course, writing "easy to understand" or "well-stylized" code isn't going to make up for a huge gap in knowledge, but it must make some difference. Well-written, easy to understand (and use) objects seems like it should be a strong priority.

EDIT: I would enjoy a C++ "programming challenge" once in a while, if any of the experts are so inclined, where you'd lay out a problem, a time frame to solve it in, and conditions (resources available, like the web, or no resources, etc.) At the end of the time allotted, we could post our results and we would all learn from the thread--and it might give the experts some insight on others abilities, or something to benchmark their interview candidates against.
 
Last edited:
[*]I feel like C++ is the most difficult language to master. Assembly and C have been around longer, but C++ introduces OOP, and with it, many more layers. This is compounded by the fact that we're still dealing with C++ code that's 30 years old. That's 30 years of different styles, templates, and #defines. Maybe I'm jaded because I'm working with the Win32 API, but looking up HKEY to find PHKEY to find *KEY to find ... is difficult to wade through (and to remember), and old concepts that linger like FAR POINTER don't make it any easier--and that's just the tip of the iceberg.
The Windows types are numerous and a bit intimidating, but they're very consistently named. "P" means a pointer, "C" means const, and so on. With a bit of experience, you get used to them. You should be familiar enough with the tools you're using (the Visual Studio IDE, for example) that jumping to the definition of a type should only be a couple keystrokes away. When you're familiar with the language, you shouldn't have much trouble guessing from context, either; a pointer type will be used differently than a value type.

[*]The thread heavily emphasizes direct C++ knowledge--but what about style? If someone writes code that's difficult to understand and maintain (with no comments), how does that compare to someone who writes code that's easy to understand and full of useful comments? Of course, writing "easy to understand" or "well-stylized" code isn't going to make up for a huge gap in knowledge, but it must make some difference. Well-written, easy to understand (and use) objects seems like it should be a strong priority.
I don't expect people to write comments on a whiteboard in an interview, though I certainly do expect them to be able to verbally explain the code and walk me through their mental model of the function they've just written.

In real life, code quality and maintainability is something that usually comes up during performance reviews. It also shows in feature success; if I write something that everyone on the team hates, it's usually because I didn't comment it well or it isn't maintainable. "Maintainable" has to do with code clarity, but it also has to do with the ability to measure the performance and efficacy of the resulting feature.

Also, you might've missed the part of the thread where we indicated many of these questions are language independent. You can write bsearch() in any language; you can write something like reversing a list in most languages. The point of the thread is that there seem to be very few good engineers in the job market. That's something I don't understand because I read lots about high unemployment rates.

EDIT: I would enjoy a C++ "programming challenge" once in a while, if any of the experts are so inclined, where you'd lay out a problem, a time frame to solve it in, and conditions (resources available, like the web, or no resources, etc.) At the end of the time allotted, we could post our results and we would all learn from the thread--and it might give the experts some insight on others abilities, or something to benchmark their interview candidates against.
There are lots of sites that do this; programming contest sites are pretty common. Unfortunately, they don't often focus on teaching or analyzing performance and instead cling to the score the automated tester software that runs the site ends up showing. I think the main reason for that is you're asking for too much: the person you want to learn from is a busy professional and doesn't necessarily have the time to explain and teach. On top of that, doing it for free on a forum (or even a dedicated website) means there's probably not much return on investment.

That said, I've run such exercises here once or twice. They were interesting, but mainly intended to compare languages rather than programming skillz. The point of that exercise was demonstrating that Perl really isn't a great language for string processing, though many people assert that it really is ... at least, not when performance matters.
 
Threads like this make me depressed. I've been a software developer for 4 years. I do my job well. But if I got asked those questions today, I would vaguely remember something from a college class.

But if you asked me to write a automated billing reconciliation process (and we use Oracle Pro*C, go figure), or to add functionality to our antiquated in house product, or to tune SQL statements... I could do all that and much more. It just makes think that staying with the same company for too long is going to cause me to fall farther behind unless I spend countless hours outside of work on it.

No, I don't remember the answer to FizzBuzz, although I've seen it twice or three times. It's one of those things I'd just have to memorize.
 
As an aside, I just read your Essay for Programming Students Mike... and I have to say there's a lot of good stuff in there. If I had to rate myself, I would say my strongest language is SQL, at about... a 7?

Hell, I wrote a program in SQR (talk about antequated) based on the Collatz conjecture once. Too bad SQR is essentially a dead language. I'm posting it just to make me feel a little better about myself lol

Code:
begin-setup
   declare-variable
      default-numeric=integer
      decimal #rem(8)
   end-declare
end-setup

begin-program
   input #num 'Input the starting integer'
   if #num > 1
      do collatz(#num)
   end-if
end-program

begin-procedure collatz( #input )
   display #input

   if #input > 1
      do is_odd(#input)

      if #_odd = 1
         let #output = ((3 * #input) + 1)
         do collatz( #output )
      end-if

      if #_odd = 0
         let #output = (#input / 2)
         do collatz( #output )
      end-if

   else
      stop quiet
   end-if
end-procedure

begin-procedure is_odd( #x )
   if #x > 1
      let #rem = mod( #x, 2 )
      evaluate #rem
         when > 0
            let #_odd = 1
            break
         when = 0
            let #_odd = 0
            break
      end-evaluate
   end-if
end-procedure
 
FizzBuzz for programmers is like the I-IV-V for musicians. It shouldn't be something you have to recall from memory, it should be obviously apparent to anyone even half-way respectable.

No, I don't remember the answer to FizzBuzz, although I've seen it twice or three times. It's one of those things I'd just have to memorize.
 
This is the first time I've heard of FizzBuzz. lol.

And while I laugh at it's concept, I'm surprised that "veteran" programmers can't perform operations like that on the spot. I'm a green developer and I could perform those tasks easily.

It is interesting to compare that with this thread, where by contrast I'd be lost.

I would almost like to go through a few mock interviews to find out exactly where I stand compared to my peers in the eyes of recruiters.
 
Last edited:
FizzBuzz for programmers is like the I-IV-V for musicians. It shouldn't be something you have to recall from memory, it should be obviously apparent to anyone even half-way respectable.
The irony is that that code that he posted couldn't be closer to fizzBuss.
 
*sigh*...

Let me clarify.

If I walk into an interview room, and someone asks me, "Hey, can you write a solution to FizzBuzz?"
I'd not remember what the hell the problem was.

If I walked into an interview room, and someone asks me, "Can you write a program that outputs the numbers 1 to 100, and puts Fizz on every multiple of 3 and Buzz on every multiple of 5?"
I could do it in minutes.

I couldn't remember what FizzBuzz was until I Googled the problem. Does that make sense?

The code I posted wasn't supposed to be FizzBuzz, it was a solution for the Collatz conjecture...
 
*sigh*...

Let me clarify.

If I walk into an interview room, and someone asks me, "Hey, can you write a solution to FizzBuzz?"
I'd not remember what the hell the problem was.

If I walked into an interview room, and someone asks me, "Can you write a program that outputs the numbers 1 to 100, and puts Fizz on every multiple of 3 and Buzz on every multiple of 5?"
I could do it in minutes.

I couldn't remember what FizzBuzz was until I Googled the problem. Does that make sense?

The code I posted wasn't supposed to be FizzBuzz, it was a solution for the Collatz conjecture...

I don't think anybody here would claim that you are a bad engineer if you couldn't "write FizzBuzz". The problem would be if you couldn't do the more specific issue - if you couldn't solve the problem as described. However, some things, like binary search, should be well known to you, as that kind of divide and conquer problem is the stock and trade of many engineering problems.

So really, I don't know what you're complaining about.
 
If you can write fizz buzz, that's great. But I also expect a conversation about how it works, and how to make it faster.
 
If you can write fizz buzz, that's great. But I also expect a conversation about how it works, and how to make it faster.

Heh, based on how he worded it, one could make a particularly simple version of this program (and a crude form of time/memory trade off):
int main()
{
printf("12Fizz4BuzzFizz78FizzBuzz11Fizz1314FizzBuzz...etc...");
return 0;
}

But that's just me being a jerk ;)
 
Did this quick in PHP... When you say make it faster? You mean like, code it differently? Or backend mods? I don't get how you could make this any faster by changing the actual code...

Code:
<?php

for ( $i = 1; $i < 101; $i++ )
{
	if ( $i % 3 == 0 ){
		echo 'Fizz';
	}
	
	if ( $i % 5 == 0 ){
		echo 'Buzz';
	}
	
	if ( $i % 3 && $i % 5 ){
		echo $i;
	}

	echo "<br>";
}
 
i was actually talking about electrical engineers when I said that, didn't see yall were talking about software, my bad!

but yeah it's very scary if someone with a comp sci degree can't solve fizzbuzz in under a minute


Did this quick in PHP... When you say make it faster? You mean like, code it differently? Or backend mods? I don't get how you could make this any faster by changing the actual code...

Code:
<?php

for ( $i = 1; $i < 101; $i++ )
{
	if ( $i % 3 == 0 ){
		echo 'Fizz';
	}
	
	if ( $i % 5 == 0 ){
		echo 'Buzz';
	}
	
	if ( $i % 3 && $i % 5 ){
		echo $i;
	}

	echo "<br>";
}


Let's start with your code.

Does this code do what it is supposed to? What are your test cases? There are bugs...

Once those are fixed, how can you make this code snippet do less work / use less CPU? (minor revisions, not a rewrite)
 
never said I had a comp sci degree, I'm an EE but I know basic c++ I'm gonna have to reread the problem because I think it works as it should so i must be missing something
 
how can you make this code snippet do less work / use less CPU? (minor revisions, not a rewrite)

only thing I can think of is using if, else if, else if, else to cut back on the number of checks? I like my way more though, lol
 
or something like this? lol I dono i think there comes a point when it does more harm than good?

Code:
<?php

for ($i=1;$i<101;$i++){
	
	$a=$i%3;
	$b=$i%5;
	
	if(!$a){
		echo 'Fizz';
	}
	
	if(!$b){
		echo 'Buzz';
	}
	
	if($a&&$b){
		echo $i;
	}

	echo "<br>";
	
}
 
only thing I can think of is using if, else if, else if, else to cut back on the number of checks? I like my way more though, lol

You could do hard coding, as I (somewhat snarkily) suggested. You could also unroll the loop. The pattern for "fizz" and "buzz" repeats every 15 numbers, but won't end evenly at 100, so you could do something like this:
Code:
void FizzBuzz(int max)
{
 int i = 1; 
 for (;i+15 <=max; i+= 15)
 {
  printf("%d",i);
  printf("%d",i+1);
  printf("Fizz");
  printf("%d",i+3);
  printf("Buzz");
  printf("Fizz");
  printf("%d",i+6);
  printf("%d",i+7);
  printf("Fizz");
  printf("Buzz");
  printf("%d",i+10);
  printf("Fizz");
  printf("%d",i+12);
  printf("%d",i+13);
  printf("FizzBuzz");
 }

 for (; i <=max; i++)
 {
  if (0 == i%3)
  {
   printf("Fizz");
  }
  if (0 == i%5)
  {
   printf("Buzz");
  }
  if (0 != i%3 && 0 != i%5)
  {
   printf("%d",i);
  }
}
 
And they say early optimisation is the route of all evil.. The mod operator isn't that expensive (just tried it in a loop of a trillion integers and it took 3.564 seconds, that was single threaded).

So you removed a bottleneck that never existed, meanwhile you introduced a huge amount of code repetition with code that is almost impossible to test.
 
The mod operator isn't that expensive (just tried it in a loop of a trillion integers and it took 3.564 seconds, that was single threaded).

Expensive is a pretty application specific term. My 30-seconds-thinking-about-circuits-that-can-calculate-modulo tell me that for non-trivial bases you essentially have to perform a division to get the result.


Edit: FWIW, your data is suggesting about 10 cycles per iteration on a ~3.5GHz processor. This doesn't give a completely clear picture however, since there is likely some ILP occurring.
 
Last edited:
never said I had a comp sci degree, I'm an EE but I know basic c++ I'm gonna have to reread the problem because I think it works as it should so i must be missing something

I don't think you said you had a computer science degree, but you did post this:

I haven't touched C++ in many many years and I only took 2 classes in high school, but I could easily solve all of those in an hour or two and I don't claim to be a C++ dev on my resume lol. So that is very scary...

It's been a lot longer than an hour or two since you posted that, and I haven't seen any solutions. You seem to be struggling a bit with FizzBuzz, the simplest problem we've discussed in this thread.

I think what you're showing us is that many people are unaware of their own limitations, don't have an accurate idea of their own competency, and tend to overestimate their skills.

And they say early optimisation is the route of all evil.. The mod operator isn't that expensive (just tried it in a loop of a trillion integers and it took 3.564 seconds, that was single threaded).
Is there a more expensive operation than integer division that a processor can do internally? How does it stack up against more complicated operations?

Are you completely sure your computer does 280 billion division operations per second? How many division operations is your single-threaded program doing per clock cycle?

I don't think anything is premature about these optimizations. After all, I asked for them as the next step in the questioning process. Writing FizzBuzz is something any engineer should trivially do. Once it's done, there's 55 more minutes in the interview hour. What else can the candidate tell us about himself in that time?

So you removed a bottleneck that never existed, meanwhile you introduced a huge amount of code repetition with code that is almost impossible to test.

How many division operations did the solution in post 132 perform compared to the solution in post 137? Do you really believe the revised code isn't faster?
 
Are you completely sure your computer does 280 billion division operations per second? How many division operations is your single-threaded program doing per clock cycle?

You're 3 orders of magnitude off. It's 280 million per second, and roughly 0.1 divisions per clock on a 3GHz processor.

Edit: Actually you're correct.
 
Last edited:
The claim is a trillion division operations in 3.564 seconds. 1,000,000,000,000 divisions in 3.564 seconds is 280,583,613,916 divisions per second, isn't it? 280.5 billion operations per second is 1 trillion operations divided by 3.564 seconds.

What did I get wrong?
 
Yeah you're right; I made the reverse mistake I thought you made. The numbers are seemingly too fast.
 
Ah, perhaps I could have been missing a few zero's... :rolleyes:

Yes division is by far the most complicated operation you can throw at a cpu (It would be interesting to see what something more suited to floating point operations [such as a gpu] could do with this). The point I was making is that the previous code introduced room for errors which could easily be missed by someone testing it unless they had deep knowledge of how it was implemented (5 and 25 use a different path to calculate "buzz").

Which reminds me, how do you handle code quality in such an organic environment? Such as the above or where someone used 9 zero's instead of 12?
 
Last edited:
Yeah you're right; I made the reverse mistake I thought you made. The numbers are seemingly too fast.

Thanks. It is too early to be having a bad math day! The numbers claimed are impossibly fast. Maybe he's overclocking. LOL!!1
 
I have this vague memory that there are some really unusual and archaic instructions in x86 which might be slower than division; like a Taylor series expansion or something.

It might just be my imagination; I'm not at all familiar with the x86 ISA.
 
Ah, Perhaps I could have been missing a few zero's... :rolleyes:
Or maybe you just made the numbers up. I have a pretty humble i7 965 at a stock clock of 3.2 GHz, and I'm doing a billion divisions (and additions) in 9.9 seconds, which is 101 million divisions per second. A trillion divisions would take around 9900 seconds, which is 2 hours and 45 minutes.

The point I was making is that the previous code introduced room for errors which could easily be missed by someone testing it unless they had deep knowledge of how it was implemented (5 and 25 use a different path to calculate "buzz").
I don't know what you mean by "5 and 25". I think testing is possible without transparent knowledge into the code. The tester just runs it and sees if the output generated is correct. That doesn't require any insight into the implementation. What kind of errors do you think are possible and only verifiable with an understanding of the implementation?

Which reminds me, how do you handle code quality in such an organic environment? Such the above or where someone used 9 zero's instead of 12?
At Valve, you mean?
I have this vague memory that there are some really unusual and archaic instructions in x86 which might be slower than division; like a Taylor series expansion or something.
There is no op code for the Taylor series. There are floating point op codes for trigonometry, however. These are indeed more expensive than integer division -- but not by much.
 
Last edited:
No I did actually write the code, just it was a little too good to be true. That was on a 2600k @ 4.8ghz (c# .net4)
Code:
        [TestMethod]
        public void mod3()
        {
            int a;
            for (int i = 1; i <= 1000000000; i++) 
            {
                a = i % 3;
            }
            Assert.AreEqual(true, true);
        }

Passed	mod3	00:00:03.5651047


Well someone could just run the first 15 and 'think' it checks out. But there could be a typo in the code that does that actual calculation (for instance calculating buzz at 25). I think that is adding a quirk which doesn't need to be there.


Yes, I remember you saying before that there it no formal company structure, everyone just works on things that interest them or have expertise in. You don't forward your code to quality control, who then verify it and pass it on to production. And if a bug is found there are no departments so who fixes it? I do like the idea I just can't see it working on a large scale, but having used Origin I can say that it does!
 
Threads like this make me depressed. I've been a software developer for 4 years. I do my job well. But if I got asked those questions today, I would vaguely remember something from a college class.

But if you asked me to write a automated billing reconciliation process (and we use Oracle Pro*C, go figure), or to add functionality to our antiquated in house product, or to tune SQL statements... I could do all that and much more. It just makes think that staying with the same company for too long is going to cause me to fall farther behind unless I spend countless hours outside of work on it.

No, I don't remember the answer to FizzBuzz, although I've seen it twice or three times. It's one of those things I'd just have to memorize.

Here's are some common SQL things I like to talk about in interviews:
I think that google can probably resolve a lot of these problems but we are looking for devs who avoid them from the start because once your DB is in place and large enough for these problems to manifest it is a painful and expensive process to correct.

Say you are setting up a membership table which will be replicated to multiple servers.
The asp.net membership schema is pretty good so you use it, or something similar.
What are some obstacles to scalability?

[Here we may find people unfamiliar with this default schema so that's ok. Explain that it sets up a series of tables but that the user table tracks the username, userdata, pw and a guid userid to make replication seamless and user generation possible without a DB call]

Now the system has been in place for a while but we're having serious slowdowns with inserts... what should we do?

We do repeated calculations and persisting of collections of numbers and strings. How would you go about persisting and looking up these collections and checking whether or not a given set is already in the DB?

We do a lot of investment statistics from our table with millions of numbers.
With a table like this:
PKID, SYMBOL, PRICE, DATE

I want to find the minimum, maximum, mean, median and mode for each symbol.
What indices would you setup and what would your queries look like?


Note that these are pretty elementary SQL questions. Most people could come up with some "solution" but the solution they suggest will say something about their understanding about how indices, queries and BLL - DAL interactions work.
 
Here's are some common SQL things I like to talk about in interviews:
I think that google can probably resolve a lot of these problems but we are looking for devs who avoid them from the start because once your DB is in place and large enough for these problems to manifest it is a painful and expensive process to correct.

Say you are setting up a membership table which will be replicated to multiple servers.
The asp.net membership schema is pretty good so you use it, or something similar.
What are some obstacles to scalability?
You are not wrong there, I recently ran into this first hand where the same membership provider is shared between a few web apps. They have been working fine for years and growing steadily. Then suddenly they began fighting over database locks and deadlocking each other. It caused me enough pain that I will never type aspnet_regsql again, just not worth it.
 
You are not wrong there, I recently ran into this first hand where the same membership provider is shared between a few web apps. They have been working fine for years and growing steadily. Then suddenly they began fighting over database locks and deadlocking each other. It caused me enough pain that I will never type aspnet_regsql again, just not worth it.

Well, that's not an issue with membership schema so much as it's an issue with the default locking mechanism in MSSQL is incongruent with most large-user web apps.
 
No I did actually write the code, just it was a little too good to be true. That was on a 2600k @ 4.8ghz (c# .net4)
You have to be careful that the compiler isn't optimizing anything away; it's possible that it notices you're not using the variable a, and the loop is inconsequential, and therefore not executed. Your loop is for 1 billion iterations, not 1 trillion.

Well someone could just run the first 15 and 'think' it checks out. But there could be a typo in the code that does that actual calculation (for instance calculating buzz at 25). I think that is adding a quirk which doesn't need to be there.
I think this is a problem with incomplete testing rather than any problem with the suggested implementation.

Yes, I remember you saying before that there it no formal company structure, everyone just works on things that interest them or have expertise in. You don't forward your code to quality control, who then verify it and pass it on to production. And if a bug is found there are no departments so who fixes it? I do like the idea I just can't see it working on a large scale, but having used Origin I can say that it does!
I'm not sure how Origin is relevant.

At Valve, we don't have any job titles. The idea is that everyone does whatever they need to in order to make things work. We like to hire people who are very broad; if I'm writing a feature for Steam Community, for instance, I'll do the database work, the back end C++ work, and the PHP code to bring the feature to the web. I'll do the C++ code for the client, too. If I'm not so great at one of those tasks (HTML and CSS, for example) I'll get as much done as I can and find someone who can help me. Ideally, that person is also helping me learn as I go so that next time I can do it myself -- or at least do a better job of it myself.

Companies that have dedicated, vertical jobs become inefficient because those skill sets end up blocking other work. If I have to wait for a tester to become available, my feature is stalled. If I test it, and other people test it, then we get coverage and get it quickly. I don't have to ask my lead to ask his manager to ask the test manager to ask a test lead to ask a tester to do the work.
 
There is no op code for the Taylor series. There are floating point op codes for trigonometry, however. These are indeed more expensive than integer division -- but not by much.

Interesting. It's possible that the actual implementation uses the Taylor series expansion of the trigonometric function. It is an iterative process much like division techniques.
 
It's been a lot longer than an hour or two since you posted that, and I haven't seen any solutions. You seem to be struggling a bit with FizzBuzz, the simplest problem we've discussed in this thread.


What's wrong with the first fizzbuzz I posted? It works as requested... I don't do a %15 because I used if if instead of if else. if anything I've removed a check for % 15 and instead the %3 and %5 take care of that
 
What's wrong with the first fizzbuzz I posted? It works as requested... I don't do a %15 because I used if if instead of if else. if anything I've removed a check for % 15 and instead the %3 and %5 take care of that

-EDIT- Nevermind. my PHP is bad.
 
Last edited:
http://209.188.80.16/~morganb/

take a look ^ this code that you all think doesn't work, works.
Code:
<?php

for ($i=1;$i<101;$i++){
	
	if($i % 3 == 0){
		echo 'Fizz';
	}
	
	if($i % 5 == 0 ){
		echo 'Buzz';
	}
	
	if( $i % 3 && $i % 5 ){
		echo $i;
	}

	echo "<br>";
	
}
 
no? That is the 'fizzbuzz problem' I followed when I put together that PHP code, myself...
 
Back
Top