Remarks on the Code
 The use of
assert demonstrates the understanding data validation is important. It is a clear strength of the code.
 The line
if pattern == '': is a bit weaker. In part because
if pattern: is equivalent. In part because if the reason for using
pattern == '' is to express intent, then
pattern == '' or pattern == "" more clearly expresses that intent.
 The code phrase:
if pattern == '':
text_index = 0
is probably better as
text_index = 0
if pattern == '':
 Because the specification of the problem does not define what should happen in when
pattern == '', providing an explicit behavior may be a problem. Comments might help people notice that there is an explicit behavior or that the explicit behavior is different from what they expect.
 A docstring would be a reasonable (and probably better) place to describe the behavior when
pattern == '' because docstrings are accessible without examining the source code and ordinarily used by automated documentation tools.
 Although it is possible to iterate through Python strings as if they were arrays, it is generally better to use the methods of
<class str> when possible. Iterating through a string as if it were an array makes Python code look like **old C **code (old because
strstr has been part of the C Standard Library since ANSI C or C89).
 Having unit tests for code that you have written is a strong point of the code. It reflects positively on your approach to programming.
The problem can be solved with the following code utilizing Python's Standard Library. There is no guarantee that the code demonstrates what the question was designed to measure.
1: def find_index(text, pattern):
2: output = None
4: output = text.index(pattern)
5: except ValueError:
7: return output
2: The use of
output provides a clear name for the role of the variable within the function. Assigning it to
None makes the default behavior explicit.
try:except block is "the trick" to using the Python Standard Library and returning
None if the value is not found. Using
try:except blocks is not guaranteed to be what the question was designed to ask (for example if when the question's purpose is to determine ability to iterate on a string).
5: The only way to know that
ValueError when the substring is not found is from the documentation/experiment. Note that this handles no other exception (example:
TypeError raised by
'abc'.index(1)). Additional errors can be handled similarly.
7: The function only returns in one location. That location is at the end, which is at least as good as another location in the code.
Remarks on Interview Coding Questions
Interview coding questions are typically selected for purposes unique to interviews:
Can the candidate write a very simple program? These are FizzBuzz questions. Evaluating the code for anything other than whether it works or not is probably a bad idea: both experienced and inexperienced programmers may attack the problem with brute force and both experienced and inexperienced programmers may write clever solutions that address efficiency, generalization, and so on. Fizzbuzz type questions are useful for producing a Boolean value.
Is the interviewer superior to the candidate? These are trick questions based on a corner case that the interviewer knows about. When trick questions produce a Boolean. Unlike FizzBuzz they do not reliably provide good technical evaluation. They are more about power relations and office politics and hence bad technical questions.
Does the candidate have deep technical knowledge? These can also address corner cases, but can provide information about the process the candidate uses to solve hard problems. They make sense in late-stage interviews after basic technical competence has been established. The same question can be a "trick question" in one context and a "deep technical question" in another. The purpose of the question matters.
How much relevant technical experience does the candidate have? These questions produce values in a continuous range and therefore allow for the ranking of candidates. A potential problem with this class of question is that the pressure of a job interview (job versus no-job) on a candidate is different from normal workplace pressure (except when normal workplace pressure means ordinary mistakes are job versus no-job). This means that these questions can rank candidates according to interviewing skill instead of technical ability. Providing this class of question as a take home problem may avoid measuring interviewing skill.
Unfortunately, it is up to the candidate to guess the purpose for which a question is asked (and that involves interviewing skill more than technical skill). But in general, a take home problem will tend to be designed to determine relevant technical experience. It's also worth noting that companies that are worried about candidates "cheating" do not trust their interview process to produce reliable technical evaluations.
find_index as an interview question
Because the specification of
find_index allows for a range of implementations it is probably not a FizzBuzz. It is most likely a How much relevant technical experience does the candidate have? type question.
One of the features of
find_index is that it will reflect the candidate's knowledge of the Python built-in functions much as a similar question in C might reflect a candidate's knowledge of C's standard library.
Some candidates will start solving the problem by writing code. Some candidates will start solving the problem by looking at Python's
string module. Depending on what the interviewer is looking for, either approach might be preferred. For example,
find_index might be a FizzBuzz type question on iteration in a whiteboard context and a "relevant technical experience" question for Python's Standard Library in a take-home context.