function deepest_pit(B) {

The JavaScript style guide here indicates that camelCase is recommended for functions. JavaScript is not that Java like really, but it has got that in common.

// write your code in JavaScript (Node.js 8.9.4)

That's not needed anymore in the code.

var M = B.length,
    depth = -1;

I'd strongly recommend to put variable declarations on separate lines, so:

var M = B.length;
var depth = -1;

Furthermore, I'd try and avoid "magic values" such as -1 (try and use a separate boolean to indicate state, for instance). And if I use them I prefer to make them a constant, e.g. NO_DEPTH_RECORDED = -1. This could declaration would also be helpful for the user of the function.

if (M < 3) {
    return depth;
}

var X, Y, Z;
var i = 0, j, k;

This kind of variable declaration on top of the function is required for C-style code, but not for higher languages such as JavaScript. Just define the variables where they are required. This makes it easier to humans as variables have a better defined scope. It also helps when refactoring the code, e.g. for method extraction.

// console.log("i = ", i, "X = ", X)

This is not a good idea, never leave commented out code in your application. If you have to do this, prefix it with a "DEBUG: " tag so the lines that need to be removed before release can be found more easily.

Generic remarks

Although X, Y, Z and M have been defined in the challenge, I would still use lowercase due to the code conventions, and possibly reference the challenge so that people can understand the variable names.

while (i < M - 2) {

A for loop seems more reasonable here, i starts with zero, and M is known in advance. Both continue statements are prefixed with i++ and so is the end of the while loop.

As you seem to increase i every step I wonder if this is the most efficient algorithm. Once you've found a pit, it will continue 1 place and find the same pit all over - at least I think that is what happens.

As indicated by the other answer the main issue is that the code doesn't explain the algorithm used, and thus is it very hard to maintain or grasp. Additionally it is also difficult to find any performance related issues with it.

function deepest_pit(B) {

The JavaScript style guide here indicates that camelCase is recommended for functions. JavaScript is not that Java like really, but it has got that in common.

// write your code in JavaScript (Node.js 8.9.4)

That's not needed anymore in the code.

var M = B.length,
    depth = -1;

I'd strongly recommend to put variable declarations on separate lines, so:

var M = B.length;
var depth = -1;

Furthermore, I'd try and avoid "magic values" such as -1 (try and use a separate boolean to indicate state, for instance). And if I use them I prefer to make them a constant, e.g. NO_DEPTH_RECORDED = -1. This could declaration would also be helpful for the user of the function.

var X, Y, Z;
var i = 0, j, k;

This kind of variable declaration on top of the function is required for C-style code, but not for higher languages such as JavaScript. Just define the variables where they are required. This makes it easier to humans as variables have a better defined scope. It also helps when refactoring the code, e.g. for method extraction.

// console.log("i = ", i, "X = ", X)

This is not a good idea, never leave commented out code in your application. If you have to do this, prefix it with a "DEBUG: " tag so the lines that need to be removed before release can be found more easily.

Generic remarks

Although X, Y, Z and M have been defined in the challenge, I would still use lowercase due to the code conventions, and possibly reference the challenge so that people can understand the variable names.

while (i < M - 2) {

A for loop seems more reasonable here, i starts with zero, and M is known in advance. Both continue statements are prefixed with i++ and so is the end of the while loop.

As you seem to increase i every step I wonder if this is the most efficient algorithm. Once you've found a pit, it will continue 1 place and find the same pit all over - at least I think that is what happens.

As indicated by the other answer the main issue is that the code doesn't explain the algorithm used, and thus is it very hard to maintain or grasp. Additionally it is also difficult to find any performance related issues with the algorithm used. That kind of thing needs to be documented either inline or in the documentation of the class / functions.