151–160 of 547 posts
Earlier quoted context omitted.
The "better" recursive solution computes fib(n) and fib(n-1) at the same time. Linear time recursion! def f(n): if n
You have a bug for the case of fib(0).
Earlier quoted context omitted.
We always tell our candidates in advance what algorithms we'll be quizzing them on. And it's pretty much always: + fibbonacci + a sort + a linked list I like having candidates write out these problems on paper because it shows that they know how to think about code. Fibbonacci allows us to see that they have basic recursion understanding, and basic iterative loop understanding. Linked lists shows us that they underst…
I think someone's ability to understand and explain recursion like am a child is very undervalued. It's not about testing whether you know the base case or the fact that you write less lines of code in recursion but the fact that there is a built-in stack for you to use without creating one. What are the practical applications of recursion though ? Other than sorting and DFS ( well even DFS can be done iteratively wi…
Traversing and transforming nested data structures.
Just last month I had to write code that maps flat data from one system into a nested structure required by another system.
We wrote mappings as map literals and the code traverses them creating a new instance of the map filling the leaves with data from the input row and running some business logic on it.
Earlier quoted context omitted.
It's a great showcase of how a flashy looking solution is the wrong approach. A good candidate will know it can be written in 2 lines recursively, but that the stack will explode with a fairly low term number, and that iterating with a for loop is more efficient.
Fibonacci has a closed-form solution! Forget writing loops, you can write one damn equation. Runs in constant time.
There is a O(log(N)) solution involving matrix exponentiation though, if you really need to get the big numbers.
Earlier quoted context omitted.
We always tell our candidates in advance what algorithms we'll be quizzing them on. And it's pretty much always: + fibbonacci + a sort + a linked list I like having candidates write out these problems on paper because it shows that they know how to think about code. Fibbonacci allows us to see that they have basic recursion understanding, and basic iterative loop understanding. Linked lists shows us that they underst…
If you use recurssion for Fibbonacci, you do not understand neither recurrsion nor Fibbonacci.
I've used Dijkstra algorithm for calculating distance in a graph once. It was a highlight of that month. Of course I had to look it up(despite learning it and implementing it at university). Who remembers this stuff exactly after years of glueing libraries together? And even if you remember - won't you check it anyway just to be sure? It's OK to ask people general questions (what's algorithmic complexity, what kind o…
We always tell our candidates in advance what algorithms we'll be quizzing them on. And it's pretty much always: + fibbonacci + a sort + a linked list I like having candidates write out these problems on paper because it shows that they know how to think about code. Fibbonacci allows us to see that they have basic recursion understanding, and basic iterative loop understanding. Linked lists shows us that they underst…
* linked lists shouldn't be used anyway. and if they are used, you should use the standard implementation
* directly applying fibbonacci is trivial.
* sort: This is just a memorisation task, what's the point? (99% of the time, you shouldn't implement your own sort)
although, I agree with the open-book approach in the problem solving part.
I recently had an A-ha moment when I realized that the problem I was trying to solve admitted a simple solution with dynamic programming, something I had never used outside programming competitions. The problem was to divide a text into a number of tweets to make it a thread, with the obvious constraint that no tweet should have more than 280 characters, but you still wanted to minimize some cost based on how far you…
> no tweet should have more than 280 characters, but you still wanted to minimize some cost based on how far your tweets were from 280 chars That immediately brings Tex box badness to my mind. And the related line wrapping algorithm: http://www.tug.org/TUGboat/tb21-3/tb68fine.pdf
I'm not sure how people in the comments are saying that the "advanced stuff is never used", when the author used the A* search algorithm at work! I'm especially fond of this passage:
> You should also know about basic data structures that are pretty common, like hashtables, queues, or stacks. But specific algorithms like Dijkstra or A* are not ones you'd need to memorize: you'll have a reference for this, just like I had when implementing crypto.
Everyone complains about the lack of applications for these interviews, but there's not really an expectation to go beyond the fundamentals.
For example if you use dict a lot in Python, that’s not at all the same as writing your own hash table with a custom chaining or probing algorithm for collision resolution.
The original quote from the whole homebrew saga is talking about needing to seriously implement these algorithms entirely yourself for a task. It was not talking about casually knowing a few fundamentals you loosely keep in your mind while using built in libraries.
Whiteboard hazing trivia interviews are also all about obscure implementation specifics, and they are not at all about knowing the coarse fundamentals. That was the entire point of criticizing Google’s parochial barrier to entry hazing crap.
While this author’s stated experience is cool, I think they entirely missed the point of what they are responding to.
Earlier quoted context omitted.
I already don't want the job because of the interview process. Talking to someone about code they have written and the decisions and thinking around their own code is so much more respectful and gives better signal. You should be doing everything you can to put the candidate on their own turf and letting them shine. I have a lot of advice about interviews but one of the best I've heard over the years: whatever impres…
I agree with this 100%. I'd also like to add that because of this I adapted the traditional whiteboarding exercise at my current company to be about problem solving and design, and not about how many data structures you've memorized. When a candidate comes in, I give them a fake-yet-realistic product requirement (like count elements in a real-time stream from field sensors) and let them run with it however they see f…
> I adapted the traditional whiteboarding exercise
Lots of engineer types freeze when they have to make a presentation. I remember a meeting early in my career with literally three people in a conference room and I almost had a panic attack. No white board. People I already knew. All I had to to do is explain my ideas to three people. I did improve. I've given many public talks sometimes to hundreds of people and today I like public speaking. But I'll never forget where I started and that the person I'm interviewing might be very nervous. Putting them up on a whiteboard and into presentation mode only amplifies that nervousness. Just talk to people. Get them into that flow that comes from talking about something familiar that they are excited about. For most people a whiteboard test is not exciting. But if you give me a paid take home coding exercise, that's exciting. I like code, and I like to get paid for it. So if you really think you need a test, consider a very high signal test that is the exact work they will be doing.
> I make sure to ask for feedback on the exercise and I've gotten all positive feedback from candidates.
In an unequal relationship like that you are going to get a lot of false positives. If I really needed a job my response would be "loved the exercise, looking forward to talking to you more and discussing next steps if I'm the right candidate".
Earlier quoted context omitted.
We always tell our candidates in advance what algorithms we'll be quizzing them on. And it's pretty much always: + fibbonacci + a sort + a linked list I like having candidates write out these problems on paper because it shows that they know how to think about code. Fibbonacci allows us to see that they have basic recursion understanding, and basic iterative loop understanding. Linked lists shows us that they underst…
I already don't want the job because of the interview process. Talking to someone about code they have written and the decisions and thinking around their own code is so much more respectful and gives better signal. You should be doing everything you can to put the candidate on their own turf and letting them shine. I have a lot of advice about interviews but one of the best I've heard over the years: whatever impres…
Personally I'm way too anxious in interview settings to produce decent code. In interviews I find myself trying to get everything right first time, but in reality that's not how I work. I prefer to develop iteratively and debug as I go.
I'm also quite a slow and deep thinker. It's not uncommon for me to think about a problem for a good 15-20 minutes before writing any code. In this case I guess you would have some time to prep the night before, but I'd still be very nervous about coding on the day.
I prefer home assignments and that's typically what I'll do when interviewing people. I like to keep it simple and open ended. Simple because I don't want to waste their time and open ended to allow them some room for creativity because often we don't have explicit requirements in the real world. This has always worked quite well.