Comment by benbristow | Hacker News Reader

Comment by benbristow | Hacker News Reader

Parent Full thread

Definitely can't be helping.

I saw an ad on LinkedIn a few months ago for Coinbase and applied out of curiosity. Was very intimidating as a British 'commoner' who went to a very average university to be being grilled on Leetcode/Hackerrank questions by fresh male-Asian Stanford/MIT/top-US-university graduates (not being stereotypical - this was true!). Didn't stand a chance really as I don't do well with algorithmic questions although the interviewers were friendly enough and I did somehow manage to stumble to the last stage of 1 recruiter interview and 3 coding interviews. One answer I was expected to answer the complexity of my code to which the answer was something involving logarithms which I genuinely don't have a clue. I consider myself to be a pretty good developer and constantly get praise/compliments from my colleagues.

Dodged a bullet really after all the news I've seen recently about staff having their applications revoked due to hiring stoppages.

> One answer I was expected to answer the complexity of my code to which the answer was something involving logarithms which I genuinely don't have a clue.

Being asked the logarithmic time complexity of some code you just wrote is literally one of the most common interview questions in Software Engineering, no? I'm assuming at least this is what you are referring to. All the well known interview help books in the industry ("Cracking the Coding Interview" etc etc) and websites like Leetcode spend a lot of time teaching it for a reason!

I've never had a software engineering interview where I wasn't asked to discuss something related to time complexity of a given bit of code, and given the regularity in which it will crop up its worth just spending the time to learn.

Yes, it was about the time complexity. I have a very primitive understanding of big-O notation from back in sixth form but I never did logarithms in maths (never did maths to a high enough level really).

My fault for not dedicating a bunch of time to read loads of books to pass an interview and instead spending my time making a living at a full time software engineering job.

The heuristic for this, FWIW, is to think about reducing the number of things you're messing with (such as a search set) by a factor (usually 2, not always) on every iteration. A binary search is a logarithmic algorithm because you chop off half of the (sorted) search set on every pass. That's all you really need to know about it to identify one (and thus realize you have a sublinear-time algorithm).

You don't need to read a ton of books or know any math at all really - the basic answers they are typically looking for are patterns you can spot with no knowledge of logarithms what so ever.

Spend a few days and you will just recognise, "oh hey I've a nested loop here, it's likely O(n2)!" That's really all it takes, and there are only 4-5 main classifications most interview code falls into, all of which can be spotted without knowing what a logarithm is. If I had interviewed you, I would not be impressed you hadn't understood this at such a basic level either, personally. The rest of us making a full time living at software engineering have to learn it to pass interviews at top companies too!

I'm comfortable enough with time complexity, and I like to think I'll sniff out a logarithmic-class solution when I've written one, but I don't think I've ever had a problem with a candidate bucketing a problem into sublinear/linear/superlinear.

I don't know if that is helpful but logarithms are quite an easy concept that helps with thinking about code complexity.

It's an inverse of exponent which translates to " grows very slowly with input size. 10 for a thousand, 20 for a million etc.". It helps to quickly ballpark feasability the same way exponential complexity usually means "doesn't scale above 30"

Log(n) is a

- number of digits required to write a number

- depth of a balanced tree of size n

- running time of any algorithm working on input of size n which does fixed cost operation to cut input in half (e.g binary search). If your code has cost function f(n) = 1 + f(n/2) then it has logarithmic performance.

Reply on news.ycombinator.com