Over recent (about 12) months I have attempted several coding interviews
- passed a Standard Chartered pure algo test over phone, short questions but non-trivial
- probably passed a big weekend coding assignment given by an e-commerce start-up. I later found out my solution is similar to a published topological sorting algorithm so my algo is probably close to optimal.
- passed another weekend big coding assignment given by Nasdaq
- passed two separate paper+pencil coding tests at two reputable sell-side firms (i.e. banks or brokers)
- passed a speed coding test at a reputable internet company headquartered in Texas.
- probably passed a few bloomberg coding tests, both remote and onsite, on computers or whiteboard.
- (All recent failed coding tests happened at High-frequency trading shops .. very picky.)
All of these positive experiences convinced me that my algo and esp. data structure skills are improving. So I gave myself a rating of “A-minus” among Wall Street candidates. I felt esp. confident with white-board coding — with a real compiler, my proficiency is lower than other candidates.
Then I failed, on technical ground, at two big internet companies (FB and … let’s say company XX). Ironically, these were white-board pure-algo problems involving non-trivial data structures — my traditional strengths. So what’s going on? Unexpected failures deserve analyses.
— First, I think I was still too slow by their standard. One interviewer (at XX) told me they wouldn’t reject candidates because of slow completion, but I believe that’s not what she actually meant to say (She is not native speaker). Suppose a candidate takes a long time to come up with a sub-optimal solution, I actually believe given more time he would find an optimal solution because I am that type of candidate. But interviewers would have to assume he is weaker than those who complete the optimal solution quickly.
Interviewers often say they look out for thought process, but that’s probably something they look out for in-addition-to finding decent solutions in time. I think I tend to show clear (not always correct) thought process but that’s not enough.
I think those interviewers really look for “near-optimal solutions but not because candidates memorized it before hand”, so candidate need to 1) find good solution 2) be able to explain when challenged.
— Second, I think the competitors are stronger (faster) than on Wall St. I call them “west-coast competitors” though they could be working in any country, all competing for west-coast tech jobs. I guess they practice hundreds of problems at Leetcode. Such heavy practice doesn’t guarantee success but increase their winning chance.
— Third, I think my big-O estimate needs improvement. I made multiple mistakes at XX coding rounds, and elsewhere.
Big-O has never been a show-stopper in my Wall St interviews so I didn’t pay close attention on details.
— Fourth, I think I have not tried often enough. If I keep trying similar internet companies I might get lucky and score a technical win.
Given the stiff competition and high standard at west coast coding tests, I now feel it’s extremely important to set intermediate goals
- goal — pass some quick algo quizzes given by west coast interviewers over phone. I used to get those quizzes from Google phone round
- goal — pass some initial (simpler) coding round via webex/coderpad
- goal — impress at least one interviewer at one coding round. I can often sense that an interviewer is delighted to hear my idea
- goal — impress multiple interviewers, even if your solution is not optimal. I achieved this at Bloomberg
- goal — pass all coding rounds at a reputable west-coast tech shop — which is my original goal, never achieved
- goal — 100% technical win i.e. pass all technical rounds including system-design-interviews. Note you can still fail the soft skill test.
- goal — get an offer
With these intermediate goals, the picture is no longer black and white, but grayscale. We might have hit some of the intermediate goals already 🙂