Optimizing Dijkstra on grid Python (Microsoft Interview)
Actual time complexity
As you correctly state, the expected time complexity of Dijkstra's on a square matrix is O(n^2 log n). However, your algorithm has a complexity of at least O(n^4) due to the way you locate the minimum vertex.
for _ in range(n):
    for currj in range(n):
        # &lt;--- executed n^2 times here
        mini,minj = self.minimumVertex(distMat,visited)
        ...

def minimumVertex(self,distMat,visited):
    minVertexi = 0
    minVertexj = 0
    max1 = INT_MAX
    for i in range(n):
        for j in range(n):
            # &lt;--- takes n^2 time
            ...

In fact, the algorithm you implemented isn't purely Dijkstra's, but a blend of Dijkstra's algorithm and Floyd's algorithm.
You should read through the links above, particularly the Pseudocode sections to understand how each of the algorithms works, and the parts that you're mixing up.
Dijkstra's algorithm
The key data structure which allows Dijkstra's algorithm to work in O(n^2 log n) time is a priority queue which allows you to insert elements and remove the top element in O(log n) time.
This data structure is commonly implemented using a binary heap, and has a standard implementation in Python as the heapq library.
You should adapt your code to use this data structure instead of the distance table as shown below.
It is important that the first field of the tuple is the distance, since this determines the sorting.
def minimumCostPath(self, grid):
    # definitions of n, visited, drow, dcol

    queue = [(grid[0][0], 0, 0)]
    while queue:
        dist, i, j = heapq.heappop(queue)

        if visited[i][j]:
            continue
        visited[i][j] = True
        
        if i == j == n - 1:
            return dist

        for k in range(len(drow)):
            ni = i + drow[k]
            nj = j + dcol[k]
            if 0 &lt;= ni &lt; n and 0 &lt;= nj &lt; n:
                heapq.heappush(queue, (dist + grid[ni][nj], ni, nj))

    assert False, &quot;queue is exhausted but we haven't reached the destination yet&quot;

Benchmarking surprise
After writing all of this, I decided to quantify the improvement by benchmarking.
This is the code I used to see how my implementation compares against the original.
if __name__ == &quot;__main__&quot;:
    import time
    N = 100
    grid = [[j for _ in range(N)] for j in range(N)]
    solver = Solution()

    start = time.time()
    print(solver.minimumCostPath(grid))
    end = time.time()
    print(f&quot;Solved grid with size {N} in {1000*(end - start):.3f}ms&quot;)

To my surprise, your version was actually faster, but more importantly it gave incorrect results.

My logic is alright

No, it's not.
The issue is the usage of n in the minimumVertex function. Because you define n = 4 as a global, this value is used instead of the actual size of the grid. This makes your algorithm appear fast, but actually be incorrect for n &gt; 4.
Conclusion
As it turns out, while the algorithm you (I imagine) intended to implement is O(n^4), your code was actually O(n^2) all along. If this really resulted in TLE, Python is not going to be able to handle this question.
What I find much more likely is that your code failed due to an incorrect response - using the correct implementation of Dijkstra's above is likely to fix this.