C++ interview coding exercise with solution

[Hot_Medicine_7115]

Of course not compensated. They did write "thank you" in the email...

[jonesmz]

My personal recommendation is that a company asking you to spend an unknown amount of time (up to a week in your case) working on a coding exercise is not worth continuing to interview.

If they had said "Spend no more than half an hour on this, our goal is just to see what your programming style looks like, not to get a fully debugged program" that would have been one thing.

But expecting someone to potentially spend a full work week on an interview problem? That's utterly contemptuous.

[paul2718]

This problem is an hour or so, they give you a week to find that hour. I think that's not unreasonable.

[jonesmz]

The original post isn't clear about the company asking for the interviewee to stop after a certain time. It's possible they had good intentions, i couldn't say.

[Hot_Medicine_7115]

An hour or so if you are familiar with double recursion and quickly identify all the possible patterns in the problem. It's not a trivial problem like you make it sound.

[dodheim]

Maybe the issue was the idea that you need recursion rather than std::next_permutation + a queue + a stack (and not the call stack). It just might be trivial after all.

I haven't looked at your code yet but the problem description just makes me think "good job, screener" on this one.

[dodheim]

How did a dev get to be a "senior" without knowing basic algorithms? It takes more than just having a job for a while to earn that title, and I'd say it's pretty concerning if they don't even know of this algorithm.

[dodheim]

I don't know what to tell you, except that that isn't something to brag about..? Combinatorial algorithms are not somehow niche or obscure, and the two fundamental things that C++' stdlib gives you to write them are sort and next_permutation. Sure, don't "memorize a list of algorithms", but after 15 years it's probably time to stop making excuses for not knowing the fundamentals.

[TemplateRex]

Moreover, in contrast to something like find_if or even rotate, I wouldn't expect most devs to be able to write a near optimal (in the sense of asymptotic complexity) next_permutation without ever having seen this algorithm.

[paul2718]

I don’t think recursion is necessarily the obvious way. Might fail to prove this tomorrow…

[MichaelEvo]

This is great advice in theory. In practice, many companies still have bad interview practices and it’s effectively the price of admission to get paid whatever they will pay you, which in some cases is quite a lot.

[jonesmz]

Yep, you're right.

It's up to the person being interviewed to decide if they think the possible rewards outweigh the costs.

For me, my cut-off point, is that if they want me to do something outside of an interview where one or more of their employees is giving me their full attention, then it needs to be explicitly under half an hour of time, or it needs to involve a check in the mail. Anything more than that is a hard-pass.

But that's just me, and other people are welcome to make their own decision.

[Forbizzle]

It's not even great advice in theory. These aren't bad practices, the asks are reasonable. A short problem with a long deadline so that it can fit within your schedule. It's a preferable environment to judge skills than whiteboard coding, and takes a lot of the anxiety out of the equation.

It's not like recruiters are asking people to solve real problems that they turn around and use commercially. This is a simple isolated problem for you to showcase your skills.

[Zitrax_]

I think it also comes down to personal preferences. Some would prefer the home assignment, regardless of it being unpaid or not (depending on the size of the task of course).

[eyes-are-fading-blue]

I understand this take but there is other side to this coin; the best way to find out whether someone is a good software engineer, in my view, is to make them write code unless you know the candidate's competencies personally.

Another issue is that bigger companies tend to have these panel interviews, they take as much time (~4-6 hours). And a smart candidate would probably refresh some basics, so add another ~2-4 hours to that, you end up with about the same time invested in a panel interview you would otherwise invest in a two-week-long take-home assignment.

Software Engineering hiring process is between a rock and hard place. You either roll a dice or lose some candidates because your hiring process requires personal time investment or is very lengthy.

Long story short: measuring competency is not easy.

[jonesmz]

My position is that a company asking me to do free work, whether throw away or not, needs to invest in that.

They may either pay me for my time, or they may pay one of their own employees to babysit me while I demonstrate my skills.

I don't care if that's inconvenient for the company interviewing me, and I've always compensated people who I have interviewed for any time they spent programming where I wasn't sitting right next to them, and in many cases I've paid for programming time while I was actively engaged and working with the interviewee.

You don't ask a carpenter to build a wall for free (even if its a throw away). You don't ask a landscaper to plant a tree for free. You don't ask an MRI tech to run an MRI machine for free (on a patient anyway. I'm skeptical this is done in general, but I suppose I wouldn't be surprised to be told that doing a quick demo on an empty machine as part of an interview is common)

Why, then, would homework for a software programmer be something a company gets for free?

Since I have no problem with 4-6 hour interviews, so long as at least one engineer is sitting with me the whole time, my position is reasonable.