My 'almostIncreasingSequence(sequence)' code is too slow for lists that have 10000+ elements. [CodeSignal]
Checking if a list is strictly increasing
The inner loop checks if a list (in this case newList) is strictly increasing:
j = 0
in_order = True
while j &lt; len(newlist) - 1:
    if newlist[j+1] &lt;= newlist[j]:
        in_order = False
        break
    j += 1
if in_order == True:
    return True


In general variable names should use underscores, so newlist becomes new_list. PEP 8.
It can be simplified with a for-else:

for j in range(len(new_list) - 1):
    if new_list[j+1] &lt;= new_list[j]:
        break
else:
    return True

Or using all:
if all(new_list[i] &gt; new_list[i - 1] for i in range(1, len(new_list))):
    return True

Optimization
As you said, the solution is too slow for large input due to the inner loop that runs every time, making the overall complexity \$O(n^2)\$.
The current solution follows this approach:

For each element of the input list
Build a new list without such element and check if strictly increasing

Consider simplifying the approach like the following:

Find the first pair that is not strictly increasing
Build a new list without the first element of the pair and check if it is increasing
Build a new list without the second element of the pair and check if it is increasing

For example:
def almostIncreasingSequence(sequence):
    def is_increasing(l):
        return all(l[i] &gt; l[i - 1] for i in range(1, len(l)))

    if is_increasing(sequence):
        return True

    # Find non-increasing pair
    left, right = 0, 0
    for i in range(len(sequence) - 1):
        if sequence[i] &gt;= sequence[i + 1]:
            left, right = i, i + 1
            break

    # Remove left element and check if it is strictly increasing
    if is_increasing(sequence[:left] + sequence[right:]):
        return True

    # Remove right element and check if it is strictly increasing
    if is_increasing(sequence[:right] + sequence[right + 1:]):
        return True

    return False

I believe there should be an approach that doesn't build the two additional lists to reduce the space complexity, but I'll leave that to you.