Below question was asked in IBM, as per Daily Coding Problem article -

Given an integer, find the next permutation of it in absolute order. For example, given 48975, the next permutation would be 49578

Below are my options & don't forget to check till the last option in the end-

Given an integer, find the next permutation of it in absolute order. For example, given 48975, the next permutation would be 49578

Below are my options & don't forget to check till the last option in the end-

Obviously it is

So not better solution you can give like shown below. And I believe any approach during the interviews depends on what strikes you first but most interviewers don't understand this.

**Brute-Force**solution & to this the interviewer,*who might have see a better solution over the internet while searching for the interview questions*, will point that this is slow & can you make it better. These people are generally**headless**& like to show themselves more intellegent than the candidates. So never give the better approach first, always give some**naive**or**brute-force**approach to these interviewers so that they can have their**ego**.So not better solution you can give like shown below. And I believe any approach during the interviews depends on what strikes you first but most interviewers don't understand this.

To the above solution even, your interviewer doesn't stop as s/he has see some other solution. So s/he will again ask saying that can we improve the code, as it is highly possible that s/he doesn't know about the performance in it so just checking for the code improvement. But you know that its performance can be improved even.

Below is improved version with little tweaks & it works more than 10 times faster.

Below is improved version with little tweaks & it works more than 10 times faster.

Now you have seen above solutions

Did you understand these?

Did these work for your test cases?

If these work for your test cases then we are on same page & have to agree that proper test cases are not created in first attempt.

Check below code for slow version & see the difference -

Did you understand these?

Did these work for your test cases?

If these work for your test cases then we are on same page & have to agree that proper test cases are not created in first attempt.

Check below code for slow version & see the difference -

Next is its

**fast version**- Next is the

**fastest version**- Above kind of solution is fine for

**Integers**, but what if we have a very long number far greater than an integer or long & this number we will represent with**String**& will do the processing like above & below is that implementation - I hope you checked all the above options.

Did you understand the logic?

Did you find any issue there?

But at least you got few thoughts about how the performance is improved by little tweaks & how we move to better solution gradually..

But did you see that above logics don't work for every scenario to get the right answer, even the slowNext gives the incorrect result due to obvious reasons. And while writting the efficient logics we do make such mistakes, even I make such mistakes many times.

Above are those examples. So what is correct way? It is given below which I think should give correct results, if you get it failing for any valid case then do let me know, I will appreciate that.

Did you understand the logic?

Did you find any issue there?

But at least you got few thoughts about how the performance is improved by little tweaks & how we move to better solution gradually..

But did you see that above logics don't work for every scenario to get the right answer, even the slowNext gives the incorrect result due to obvious reasons. And while writting the efficient logics we do make such mistakes, even I make such mistakes many times.

Above are those examples. So what is correct way? It is given below which I think should give correct results, if you get it failing for any valid case then do let me know, I will appreciate that.

Now you see the above way, do you think we can make it more efficient?

Try & let me know, as I am looking to have good performance for huge numbers outside the range of Integer, Long, Double etc.

Try & let me know, as I am looking to have good performance for huge numbers outside the range of Integer, Long, Double etc.

**One implementation for huge number which is sent as String with O(nlgn) complexity -**