First, you should "google" with relevant keywords to read about other folks' experiences. There are many tips and practice runs you can use without coming in to the test cold. You have the privacy of your home/work environment. Definitely you should have the environment set up comfortably for a quick search for the problems being presented to you. If you are coding daily in your work, the famous LonelyInteger and Print-Odd-Numbers should definitely be easy for you. Nevertheless, force yourself to polish your skills in an environment with a limited time window.
Seriously, in a one-hour or 90-minute setting, they should not expect you to come up with a working implementation from scratch for the Bellman-Ford algorithm or the like. However, I suggest that you do practice the quick online search, and solve/learn/copy a few simple ones to get the hang of it. Almost all well-known algorithms can be found online. When you go in for an in-person interview later, it is totally reasonable for the company to ask for pseudo or real code of common algorithms required by your job.
Now, let us get back to my own story. I ended up spending most of my one-hour in C++ googling for simple iostream class and examples. To my dismay, this customized test did not give me language choices. My limited raw knowledge on simple "cin" and "cout" was not enough to cut it. Dealing with variable length input line, one needs to use the istringstream paradigm. Furthermore, detecting syntax error needs to know the public member function fail() and how to swallow bad inputs as you go. There was no way to learn and polish all this in the one precious hour exam time for me :-).
Here is the example I present to you:
Event Set Processing
TEST INPUT/OUTPUT: stdin and stdout
First line: number of lines to be processed (N)
Second line and onward till the N+1'th line:
permutation of positive integer numbers between 1 and M, inclusive
Success : received "M"
Failure : expected "M", but received "X".
Failure : syntax error
(including non-integer, negative integers)
All lines should be processed, and each line should produce a "Success" or "Failure".
- Example Input and Output
- 1 5 4 2 3
- 4 3 1
- 5 x 4 3 2
- 1 6 5 -4 3 2
- Success : received 5
- Failure : expected 4, but received 3
- Failure : syntax error
- Failure : syntax error
Before the exam -
Practice input-output coding for the language(s) you can be tested with.
Don't just do "Hello, world!" as it is simply not enough. Read the input line-by-line with an unknown number of fields in each line. Do some syntax error check, including non-integer input and negative integers. You should have working example handy, to simply re-type them as required. Note that copy-and-paste is normally disabled during your test session.
Very often, the required logic in the exam itself is very simple due to time constraints.
During the exam -
Run a simple test early on, and see the test cases and input patterns. Focus on getting those processed correctly and no more. Skip the nuances and details, just pass the test cases provided. Save those high standards you might have for the software you normally write.
For example, you don't need to detect duplicates in the input line in the example I provided earlier. Use a simple large array for the input processing without dynamically allocating the storage space, assuming this method is sufficient to pass all given test cases.
Finally, for the testing organizations and employers
1) Repeat a similar test in person to defeat impersonation.
2) Randomize testing cases to be non-deterministic.
3) Perform some simple randomization of testing input line content to defeat outrageous correct output echoing by the code.