Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Seven Years Is Too Long

lolindrath.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Seven Years Is Too Long

#31

Post by nilkn »

jobu wrote: post #26
nilkn wrote: post #23

If you just want to keep up to date on interviewing skills, make a habit out of doing interview-style problems. I don't think you need to worry about wearing a suit or writing on a white board. Careercup is a fairly consistent source of interesting interview-style problems; I find myself perusing it sometimes even when I'm not remotely interested in another job, because a fair number of the problems are interesting i…

I couldn't disagree more. Interviewing is definitely a skill (beyond solving interview problems), and like anything - if you don't do it often you will not be very good at it.

You're free to disagree, but I don't think you responded at all to the actual point I made regarding "interviewing for practice" in a city where there are only a small handful of companies that suit you. I never said or even implied that interviewing itself isn't a skill.

Re: Seven Years Is Too Long

#32

Post by mmanfrin »

bagels wrote: post #27
fournm wrote: post #20

Earlier quoted context omitted.

It's certainly useful when you find that someone accidentally made something n^5 instead of n and you need to explain to that person why they were very, very wrong.

Yes, this discussion happens with junior engineers. I keep finding O(n^2) code that should have been O(n) or O(n log n), and not just as an academic exercise, because it slows the website down.

You don't code the notation. Knowing how to write optimized code != knowing the notation. I have hardly seen the notation outside interviews.

Re: Seven Years Is Too Long

#33

Post by mmanfrin »

pjscott wrote: post #21
mmanfrin wrote: post #19

Someone convince me that Big-O notation is useful anywhere outside of interviews. Because I don't believe it is.

I've run into plenty of cases where something was unacceptably, brokenly slow for a handful of inputs, and I wanted to figure out why, and then I realized "Oh, this bit of code is O(n^2) and it's running into a weird edge case with a large n", and then fixed it. I've also run into cases of regular expressions running in exponential time, which is always entertaining.

Yes, but you saw code was not optimized, you didn't see the letters "O(n^2)" in the code.

I'm not asking why optimization is important, I'm asking about the notation that only seems to appear in interviews.

Re: Seven Years Is Too Long

#34

Post by jobu »

This article strikes really close to home for me. The company I had worked for nearly seven years laid off a bunch of people and I could see where things were headed. Fortunately I've been doing mobile development and it's particularly in demand right now, so I was able to land a new job in a few months.

> Interview at Least Every Other Year If you struggle to communicate under pressure like I do, then it's important to do this a _lot_ more often. My personal goal is a phone interview at least once a quarter and one or two in-person interviews a year.

I would also add another rule:

Don't apply to too many places at once. (Especially if you're currently working!) Keeping up with the responses, doing the interviews, and solving coding exercises can be a full time job in itself.

Edit:

The other thing I learned to do was to note all of the questions that I didn't have an immediate, natural response for. Some of them I was able to think of better answers later on that helped me in the next interview. Some I asked other people to see how they responded, and I realized I hadn't always interpreted the question correctly.

Re: Seven Years Is Too Long

#35

Post by ccoggins »

nilkn wrote: post #23

If you just want to keep up to date on interviewing skills, make a habit out of doing interview-style problems. I don't think you need to worry about wearing a suit or writing on a white board. Careercup is a fairly consistent source of interesting interview-style problems; I find myself perusing it sometimes even when I'm not remotely interested in another job, because a fair number of the problems are interesting i…

That's easy enough to overcome though. Just have mock interviews. Do it with friends, coworkers, or people from tech meetups. I actually find it much more embarrassing to interview with friends than with strangers also, so that helps with the "jitters" too.

Re: Seven Years Is Too Long

#36

Post by fournm »

mmanfrin wrote: post #33
pjscott wrote: post #21

Earlier quoted context omitted.

I've run into plenty of cases where something was unacceptably, brokenly slow for a handful of inputs, and I wanted to figure out why, and then I realized "Oh, this bit of code is O(n^2) and it's running into a weird edge case with a large n", and then fixed it. I've also run into cases of regular expressions running in exponential time, which is always entertaining.

Yes, but you saw code was not optimized, you didn't see the letters "O(n^2)" in the code. I'm not asking why optimization is important, I'm asking about the notation that only seems to appear in interviews.

The notation just happens to give a good shorthand when discussing bits of code, as it tends to be rather fast to calculate.

Re: Seven Years Is Too Long

#37

Post by lukeschlather »

mmanfrin wrote: post #33
pjscott wrote: post #21

Earlier quoted context omitted.

I've run into plenty of cases where something was unacceptably, brokenly slow for a handful of inputs, and I wanted to figure out why, and then I realized "Oh, this bit of code is O(n^2) and it's running into a weird edge case with a large n", and then fixed it. I've also run into cases of regular expressions running in exponential time, which is always entertaining.

Yes, but you saw code was not optimized, you didn't see the letters "O(n^2)" in the code. I'm not asking why optimization is important, I'm asking about the notation that only seems to appear in interviews.

Big-o is about a specific class of optimization, and a theoretical understanding of it is important.

It is important to distinguish between asymptotic optimization vs. i/o optimization vs. code optimization.

I'd argue if you can't do the first one you're less likely to be able to handle the next two. Yes, you can do it intuitively to some extent. However, I think it's important to be systematic about it so we can have meaningful conversations about it beyond "doing it this way is slow and if we do it this way it's faster."

Re: Seven Years Is Too Long

#38

Post by nbm »

mmanfrin wrote: post #19

Someone convince me that Big-O notation is useful anywhere outside of interviews. Because I don't believe it is.

I'm involved in several (20+?) conversations a year where Big-O is used. It's mostly used as a very efficient shorthand for explaining the source of a performance or memory problem (instead of an algorithm being "slow" or "big", it's that it is an algorithm whose performance is acceptable for certain set sizes), and why a particular change is a good fit for the solution.

(Then again, I also am involved in a few constant-time optimisation discussions a year, where cache coherency beats out complexity as useful in an algorithm.)

I don't expect people to know the notation, but I expect that they can explain the underlying values for a particular algorithm.

Re: Seven Years Is Too Long

#39

Post by brc »

beachstartup wrote: post #11
cachichas wrote: post #2

you lost me at wearing a suit...

at my startup, the dress code is casual/sandals-ok except when meeting with clients. as a rule, you never want to be under-dressed when meeting with people who you want to give you money. being wrong on this even once could cost you money, possibly a great deal of it. if you show up in a suit and tie and everyone else is wearing sandals, the proper etiquette is to say "mind if i remove my tie?" and then remove your t…

The obvious solution is to enquire about dress code at the company at the time of setting the interview. It doesn't have to be awkward at all - 'what do people wear to the office?' is a perfectly reasonable question. If they say 'business casual', then you can go +1 and wear a suit. If they say 'casual' then turn up in business casual. If they laugh and say 'whatever' then just turn up looking smart and confident.

Thinking that you always have to wear a suit is some type of throwback where the interviewer had all the power - I don't see interviews like that. Interviews should be a mutual meeting of people where they work out if they should work together. An inability to even work out what the dress culture is like before the meeting betrays, to me, an inability to get basic background research in place before any meeting.

So just ask, and then dress appropriately based on the answer given.

Re: Seven Years Is Too Long

#40

Post by jobu »

nilkn wrote: post #31
jobu wrote: post #26

Earlier quoted context omitted.

I couldn't disagree more. Interviewing is definitely a skill (beyond solving interview problems), and like anything - if you don't do it often you will not be very good at it.

You're free to disagree, but I don't think you responded at all to the actual point I made regarding "interviewing for practice" in a city where there are only a small handful of companies that suit you. I never said or even implied that interviewing itself isn't a skill.

So look outside your city or your comfort zone and interview with other companies.

You may be an exceptionally charismatic person that can get any job you want, and if so, you can ignore the blog post and my responses. Think about it though, are you working at your dream job? Is there somewhere else you really want to work? Wouldn't it suck to choke at that interview?

For me, part of the challenge with interviewing is remaining calm under pressure (your future depends on how you answer the following question...). After a couple interviews recently, I found it got a little easier to handle.

Interviewing is also a matter of selling yourself, and this is more than just answering questions or solving problems - you also need to be asking your interviewer good questions. If you lead them the right direction they can come up with answers for why you're the best person for the job. (Asking the right questions can also help you determine whether you really do want to work at a company.)

Post reply on HN