Remarks on the specification
Though the example pattern uses strings as the argument, the possibility of other input types such as lists is left open. This suggests further development of the test suite to cover a variety of cases. In the context of a technical interview, an example test case using lists may be enough to suggest the candidate has thought about the problem as generalized pattern matching.
General Notes on the code
indexes is a good name.
text is not for because it biases the approach to pattern matching toward only strings.
Variables: Declaring more names such as
text_len = len(text) might make the code easier to read and understand. It tells the reader that the length of
text is important and it un-nests trivial code from within the more complex and important logic. Sometimes that reader is you.
Code shape: One of the benefits of Python's semantic indentation is that it provides visual evidence of logical complexity by pushing code to the right as it becomes more convoluted. Deep indentation suggests refactoring (no matter how wide the programmer's monitor is). Think of deep indentation as a Python code smell. The deeper the indentation the harder it is for the reader to maintain the context of its execution.
Comments: Please. Most code is not self explanatory to someone reading it six weeks from now. That someone could be you. Comments are a way to root out assumptions implicit in the code. For example
if pattern == '': implies that the input is a string. Without the assumption it can be
Main: A great idea. Providing well formatted text makes working in the interpreter much better.
Using Python features
Though I like C, I usually prefer Python. The code looks a lot like C. Python makes it easy to write code that looks like C. That doesn't mean code that looks like C is a good thing.
Python has slices. Unfortunately, C does not. Slices will simplify the Python code. Slices will make the logic less complex.
Python has documentation strings.
docstrings provide high level access to the descriptions of the code you write. See remarks on commenting above.
It is worth noting that this implementation was written at leisure. There was not the pressure of a technical interview. It was not written while the primary concern was getting a job. There was time to drink coffee and think. There was time to take a walk and think. There was time to refactor in my favorite editor.
1: def find_all_indexes(source, pattern):
2: output = 
3: length_source = len(source)
4: length_pattern = len(pattern)
5: for i in range(length_source):
6: if source[i] == pattern and source[i:i+length_pattern] == pattern:
8: if i + length_pattern > length_source:
10: return output
1: The name
source is as type agnostic as
pattern. I would have used
input but it is the name of a built in Python function. This can affect syntax highlighting in the editor.
2: I don't believe in self documenting code, but calling the output
output is an exception.
and short circuits. The slice covers all the logic of what to do when
pattern is matched in the source.
8: This bit of cleverness is why the absence of comments makes code harder to understand.
Remarks: The code does not have a code path for a null/false pattern. Based on the specification, I consider it undefined behavior. There are some things I like about C. Practically speaking, in the context of an interview, "What happens with null pattern?" might be an interesting request for more information...then again, what happens if the pattern is not iterable suggests that treating it as undefined behavior might be reasonable in the context of a technical interview.