Hello all,

I'm approaching the end of my time at university and have been applying for a number of game development positions (programming, preferably engine/core-tech). However, I'm sad to say I have not been having much luck as of late; complete honesty: the two rejections I have so far both pretty much claim my C++ is "not yet where we need it to be". Beyond that they give no feedback so I'm unsure as to how I can improve; I appreciate some may say write more code (practice etc) but surely without some feedback to point out your weaknesses simply writing more code/practice isn't as effective as it could otherwise be?

One test for example was to write a function which given a string-based representation of an integer could produce an integer with the same value, to which I gave this solution (I'd like to reduce it to one loop if possible, however the test was timed and I had to rush a bit, I'm sure there are other optimizations that could be made). I'm just giving this as a piece of example code, I could provide more if anyone wants as I very much want to learn and improve.

int ConvertStringToInt(char *c) {
	bool isNegative = false;
	if(*c == 45) { 
		isNegative = true; 
		++c; 
	}

	int size = 0;
	while( *c >= 48 && *c <= 57 ) {
		++size;
		++c;
	}
	c -= size;

	int returnValue = 0;
	for( int i=0; i<size; ++i ) {
		returnValue += (*c - 48) * std::pow(10, size-(i+1));
		++c;
	}

	return isNegative? -returnValue : returnValue;
}

I'm not going to lie, the whole thing has me feeling very down; I'm not looking for sympathy though, I'm eager for some advice on how I can improve and hopefully do better in future applications.

Thank you everyone,

- Jamie

If you're getting feedback that your C++ is not up to par, you should pursue improving it. One way to do that would be to take a project you're working on, or a reasonable chunk thereof, and post it somewhere on these forums for critique and review. It's really hard to give you any additional general advice, given the lack of information you have about why you've been rejected from the positions. It's important to remember that it isn't always because you were bad, it could very well be that somebody else was better.

Further, in interviews, you often get asked simple programming questions for a few reasons, and they're not all to do with gauging you ability to actually write code. Simple problems allow an interviewer to get an insight into a more complete picture of a candidates approach to arriving at a solution. For example, you said that you were asked to write a "function which given an integer could produce a string," and showed us your answer. I can tell from the first line of code that the function you wrote converts a string to an integer; this is the opposite of what you were asked and suggests inattentiveness to detail (unless it was just a mistake when writing your post).

As for the function itself, some things to consider:

• Why is the parameter "c" called "c?" What's "c" mean? Why not "string?" Or something equally more-descriptive?
• Why is c not const? Are you going to modify c in the function? Do you need to? What benefit or drawback would adding const provide?
• You dereference c before checking if it's null. What should happen when the caller passes null? Why is that behavior good behavior? Why is that behavior bad?
• What's 45? Magic numbers are bad. Given the context in which you're using it I can assume (and confirm) that 45 is the ASCII code for the minus sign. It would be better to write this as "if (*c == '-')" since it's more obvious, and in general it's better to use symbolic names for most constants instead of magic numbers.
• Why do you support a leading - but not a leading +?
• As above, what are 48 and 57? Magic numbers are bad.
• The entire first loop is basically strlen. Why not call strlen?
• Why do you want to do this in one loop instead of two? Can you? What is the trade-off of doing so?
• What happens if the input is not a number, or is a partial number like "-23abbbabba"? Why is this good behavior or bad behavior? What alternatives did you have?

I'm approaching the end of my time at university and have been applying for a number of game development positions (programming, preferably engine/core-tech). However, I'm sad to say I have not been having much luck as of late; complete honesty: the two rejections I have so far both pretty much claim my C++ is "not yet where we need it to be".

Time for some truthiness: you're being unduly sad. It's expected that someone who hasn't yet graduated is not going to get a job offer, and it's expected that someone who hasn't yet graduated does not yet have the C++ chops. After graduation, you'll need to work on some games, during which process you will increase your choppiness. And even then, you should expect to get numerous rejections to job applications. While the game industry is very much in need of programmers, that does not mean the industry has to lower its qualification standards. Patience, young jedi. Much have you yet to learn. Keep on keeping on.

I'm approaching the end of my time at university and have been applying for a number of game development positions (programming, preferably engine/core-tech). However, I'm sad to say I have not been having much luck as of late; complete honesty: the two rejections I have so far both pretty much claim my C++ is "not yet where we need it to be".

Time for some truthiness: you're being unduly sad. It's expected that someone who hasn't yet graduated is not going to get a job offer, and it's expected that someone who hasn't yet graduated does not yet have the C++ chops. After graduation, you'll need to work on some games, during which process you will increase your choppiness. And even then, you should expect to get numerous rejections to job applications. While the game industry is very much in need of programmers, that does not mean the industry has to lower its qualification standards. Patience, young jedi. Much have you yet to learn. Keep on keeping on.

Thank you for the encouragement, much appreciated. :)

Thanks for your reply Josh, I did indeed make a small mistake in describing the function intent and thank you for the critique, you make many valid points and I shall go back and revise the code with them in mind (I'll also post some personal project work for critique). The only thing I will say is the brief for the question said it was safe to assume a valid string (one representing a numerical value) was being passed, hence the absence of a check for non-sensical values. I also appreciate that interview are to give a look into ones thought process, though this test was done remotely, not on site.

- Jamie

Edit: Improved the code a bit with your feedback in mind (I'm going with the assurance made in the test that a non-null, integer value in string form will be passed). Also replaced the conditional at the end as it resulted in 11 assembly instructions, whereas the multiply is only 2.

int ConvertStringToInt( const char *string ) {
	char sign = 1;
	switch( *string ) {
		case '-': sign = -1;
		case '+': ++string; break;
	}

	int size = strlen( string );

	int returnValue = 0;
	for( int i=1; i<=size; ++i ) {
		returnValue += ( *string - '0' ) * std::pow( 10, size-i );
		++string;
	}

	return returnValue * sign;
}

It's pretty normal to biff a job interview, I think I had a little under half a dozen interviews after graduating from college until I managed to get my first job in game development.

That said, you should probably look into why you had two loops (strlen is just obscuring the problem, at that point, if they're allowing basic string functions why not just return atoi and be done with it), and see if you could've done it in one, is there any reason you need to wait and do the multiplication in a second pass?

Did you try googling atoi() implementations after your interview to see how others do it?

For example: http://research.microsoft.com/en-us/um/redmond/projects/invisible/src/crt/atoi.c.htm

This is about as simple as you can get it.

Did you try googling atoi() implementations after your interview to see how others do it?

For example: http://research.microsoft.com/en-us/um/redmond/projects/invisible/src/crt/atoi.c.htm

This is about as simple as you can get it.

That is beautifully simple, however the question/brief did say it should handle negative values (- prefix) and Josh makes a case for supporting '+' as a prefix (the switch boiled down to fewer assembly instructions than an if else. Taking some inspiration from the link though I've come up with this (which also boils down to fewer assembly statements):

int ConvertStringToInt( const char *string ) {
	char sign = 1;
	switch( *string ) {
		case '-': sign = -1;
		case '+': ++string; break;
	}

	int value = 0;
	while( *string >= '0' && *string <= '9' ) {
		value = ( value * 10 ) + ( *string - '0' );
		++string;
	}

	return value * sign;
}

I like this much more because it solves the two loops issue; it rids me of worrying about having to know which power I should raise 10 to each loop iteration. Anyway, I don't want this to be all about string-to-int (though if the code can be further improved please say), I'm really looking for advice on technical interviews.

Thank you all.

Josh makes a case for supporting '+' as a prefix

I didn't mean you should support it, per se. I just noted that you didn't and asked why. Many times there are choices which are not obviously good or bad, and you'll need to make a decision about how your function will behave under those scenarios, and you should be prepared to define your choice.

When it comes to technical interviews like this the advice I can give is that the interviewer is most likely not expecting one answer, set in stone.

The best solution to the problem might be one the interviewer didn't even consider.

As you code more you will learn more, and you will know more solutions to common problems such as those asked at interviews.

When they say your C++ isn't good enough yet this is probably what they mean, and only experience will fill this gap.

Enlist in projects here on this forum and in the open source community, if you get involved it won't take long before you learn a lot very quickly.

Good luck in future interviews!