As above you probably don't have source code, and it is not one I recognise on
https://osgameclones.com/ or
https://en.wikipedia.org/wiki/List_of_commercial_video_games_with_available_source_code . If it is a Java game, C# game or similar then you stand a reasonable chance of doing some decompilation. If you are asking this question then I would not really expect much to come from you trying your hand at C decompilation (some things have been discovered here -- Kirby N64 having something found the other month by those engaged in decompilation).
If you did have the source code then read the source code as it will tap into whatever code handles the menu. There is a possibility such a thing would be obfuscated (though we tend to see this more in open source world to allow devs to have donator features for open source games such that you can't just read the source and learn it trivially) but eh.
To that end we are back with more traditional methods. As it was a trend with some interest in it (see stuff like the hidden xbox menu easter egg, as well as a kirby thing above) I have a guide about 60% done on the matter and general background for finding hidden cheats, however the remaining 40% I have not done is the tedious assembly aspects with examples so I will hold off on sharing that one.
Do check there is no simple dictionary within the game if you look at its files -- if you can enter codes and know a bunch of them then searching for that within the game (might be ascii, might be hex, might be something else, relative search can help here) is not a bad way to open up such a hacking effort.
After this we get to talk about how menus are coded and what to expect there; 15 IF type checks in a row (be it character by character or for the complete entry) is bad coding but it is not likely to bother anything in the average game so you might encounter it being programmed as such. Said IFs will likely correspond to codes as well so if you have that you are laughing. If it looks things up in its own dictionary then the code will look a bit different still. All this will need to be done in a debugger and as you will want to have a broad appreciation of the methods the game might employ.
Option 2. Savestates, macros, computer vision and brute force.
If a failed attempt will always look the same whereas a success does something different you could relatively easily make a script to enter numbers for you. Depending upon how many inputs and how many numbers this may become impractical though. People have done this for everything from catching shiny pokemon to general number pad brute force efforts. Start with a savestate (virtual machines are good for this if you have no other means) you can restore, get the computer to enter button combos (should not be too hard to make something that iterates over the entire space) and compare results/wait for something different on the screen (
https://www.youtube.com/watch?v=D75ZuaSR8nQ for a funny example of using that) and log everything that it detects as outside normal failures, or if it does audio cue then you have that as well.
Assembly has a fairly steep learning curve, this sort of thing you could probably pull off in a macro language like autohotkey (but I would probably still keep the macros for macros and use something like python to underpin it all).