Of small to mid-size cities. That's like being the best player on a beer league team.

(I live in a small city so I'm allowed to say this).

Is it bad my first reaction was "...Rochester, NY #1 to live?????..."

Congrats!

My guess is they visited in the summer time...

Que Bueno !

I've never been to Rochester, NY before....

Just out of curiosity what kind of assignments would the experienced developers have and what is your development process like? I have read your posts and the work you do seems interesting. Unfortunately I can't do this right now but still wondering.

I wouldn't want to live in any of the top 20 places.

I didn't know it, but Austin is nearing one million residents. It doesn't feel like that many people live here. Feels like a small town.

The guy gets a good job and next thing you know he's showing off with his fizzbuzz.sql. Man.

MOD(t1.nums, 15) = 0
in oracle at least, afaik

Which is a great "old man yells at cloud" thing. Learning php, Java, and sql, I have to remember three different comparison operators for 'equals to'. What kinda bs is that?

@kato

That's a very generous offer and I do appreciate it, but I'll have to look local for the time being.

Rochester sounds really nice. It's ranked at least ten above where I currently am. (And less than 20)

daveT congrats, finding a place that excites you.

As I've said I applied for 497 jobs. I never got a question on any algorithm or data structure more difficult than linked lists, arrays, hash tables, queues, and then DFS/BFS (mainly BFS and just being able to explain why it's better than DFS for the problems I faced). This isn't necessarily typical but that's what I got. Make sure you can implement them all other than arrays (build a queue that will enqueue/dequeue in O(1) time and be able to reference this, offering to build it if necessary).

Most common coding question was "two sum" (given an array of numbers and a number k, select all pairs that add up to k - there are variations of this). Make sure you can do it in O(n) time. I got this question a ton.

Don't know how much algorithm knowledge you have already but you're probably better off spending time on an online course like the Coursera one that just started up again than with diving right into CtCI, if you don't already have a lot of those basics down.

Practice white board style on a literal white board if you have one or on paper if not. Talk things through as if you're on an actual interview. If you talk correctly, most interviewers will guide you through the parts you get tripped up on.

If JavaScript is one of your skills or needs to be, read Effective JavaScript and spend time learning about "gotchas" like closures and prototypal inheritance (most of it is in that book if you can absorb it, look into it more if not).

Some real good advice here. I didn't really understand why until someone explained it to me. Interviewers do not want to see you fail. They do not want to see you standing up there silent for 5-10 mins. It's awkward. So if you can talk out loud, sometimes they can help you out with some silly error.

In my last interview, some similar thing happen to me. I had a silly error and the interviewer was able to bail me out. I didn't get the job, but at least we didn't have an awkward embarrassing moment where I just froze up there for 5 mins.

The other thing to note is that how you approach the problem is just as important as how you solve the problem.

If you get up there and scribble the correct solution almost immediately it didn't tell the interviewer as much as if you had gone up and started breaking down the problem. Even something as simple as "well we need to return all paid that add to k so we'll need to iterate over the list at least once" and then writing that basic loop shows quite a bit.

Good post.

Out of curiosity, I am curious how often O() analysis comes up in the development process where people work. I would think code reviews would be the most likely place. However, that probably is a little late in the process. I would think O() analysis comes up in a design phase but then I guess we're talking about a waterfall type development process. Where I've worked O() analysis like almost never comes up.

For the majority of jobs there are more salient performance considerations than Big O - stuff like caching of results, minification and compression, eliminating server round-trips or HTTP requests, etc etc. Big O considerations only generally come into effect when you are working on projects with serious scalability requirements.

My experience (more from speaking to fellow programmers than personal experience) is that Big O questions are the sort of thing people throw in interviews because they feel like they should, rather than it having much relevance to the job. Sort of like how virtually every single job ad requires experience with unit testing frameworks, even though for a lot of the companies none of their apps have come within a hundred miles of a unit test.

Baltimore,

It seems like you are pretty competent and spent a lot of time studying. That number is pretty shocking... Do you have any idea why you were getting rejected? Do you just not interview well? Don't mean this question rudely at all, I'm just curious...

I mean, practically, I think you are mostly right. On the other hand, would you really want to hire someone who didn't understand basic big O concepts? While knowing that stuff does not imply you are good, productive developer, I think not knowing it is a fairly reliable indicator that you aren't.

I assume entry level coders should be familiar with the concept, and the most-used big O ones, like o(n), o(log n), o(n^2), etc., but I'd be very surprised if newly minted programmers are expected to be able to sort out some extremely complex and accurate big O notations. Correct me if I'm wrong, of course.

How strict do people get in code reviews? Specifically for non whitespace dependant languages. I spent a half hour talking about things like formatting and code quality and then I fail 3/4 tickets that I reviewed the next day. How do you not think about this stuff? Drives me crazy.

Understanding the big O concept is kind of vague in my view. Let's say I have heard the term, understand that a bubble sort is an n squared algorithm, merge sort is an n log (n) as far as time complexity. Not that familiar with space complexity. Good enough understanding of the concept? Or I could just memorize the cheat sheet.

I don't know, I get your point but I was thinking about this today that most of the time in the assignments I encounter O() analysis is pretty useless. What is really useful almost all the time is the ability to design and refactor solutions to increase software reliability at the very least. If we're going to state that the most efficient algorithm is almost always the best approach then I would disagree with that too. Don't get me wrong, as a computer science topic I think it is very interesting, very worthwhile as an area of study,and yes having more knowledge is always a good thing in my view. So I guess your point is that your computer science knowledge is incomplete if you don't understand the concept. Well understanding the concept can involve something as minimal as that algorithms that you develop have a time and memory complexity factor.

Yes this kind of thing deserves a great deal of emphasis in increasing productivity but how much is it emphasized in interviewing?

.

i just mean i can show you some code and you can tell me its order of growth. nothing fancy, just n, nlogn, n^k, and higher.