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

I had to give a wrong answer to get the job (2017)

dewitters.com

Post reply on HN
Print view View original

331–340 of 409 posts

Re: I had to give a wrong answer to get the job (2017)

#331

Post by exporectomy »

Radim wrote: post #9

Heh. Happens all the time with tests and questionnaires, the choice is always frustrating: * "Does the author really mean what they are asking? Are the mistakes in the phrasing or corner cases intentional, meant to catch me, test my deep knowledge?" , or * "Is the author just not very good with logic / not thinking this through?" I go with the latter in "soft social" contexts. Never regretted it yet. This saved my hi…

The tax forms in my country are filled with this second-guessing. For example if it asks how much income you earned from interest, you're supposed to exclude income that you've already paid tax on and exclude some kinds of investment that are asked about separately in another question but they don't explain this so you have to keep tweaking the numbers until the automatic calculation looks right. There's also a question about having "returned to the country" which really confused me when I was travelling back and forth. I had to talk to the helpdesk to discover that "returned" isn't the same as "arrived after having previously left". I might have got some of the wording wrong but that's the gist.

Re: I had to give a wrong answer to get the job (2017)

#332

Post by munificent »

dcow wrote: post #319
munificent wrote: post #279

Earlier quoted context omitted.

> for being stubborn and drunk on ego. I think you would have a hard time finding someone who knows me describe me that way. Maybe the way I related the anecdote here doesn't present me well. I am pretty meek and easily flustered. I don't think I was any more confident back then than I am now which is, alas, not very. > The fact that you were unable to incorporate this into the conversation In this case, it was an in…

You may be entirely correct in your analysis. There are definitely a fair share of toxic interview setups and interviewers out there. What I found off putting about the way you presented the story was the bit at the end where you gloated about your current employment status and achievements as if they missed out on some great mind. It gives the impression that in your view, your intellectual prowess was more importan…

> What I found off putting about the way you presented the story was the bit at the end where you gloated about your current employment status and achievements as if they missed out on some great mind.

Yeah, that's fair. I'm not one to gloat usually but I never felt like I got closure from what was a pretty unpleasant interview experience so I couldn't resist the urge to get a dig in.

> This is the type of conversation I tend to enjoy during interview problem solving because IMO it most accurately reflects the type of conversation you'd actually have with teammates when building a system.

My Google interviews were so much better in this respect. The interviewers were really candid and fluid. They did a great job of letting me bring up points that I thought were relevant but not get too ratholed. Overall just a miles better experience.

> sometimes personalities just don't gel.

One way to look at it was that the interview was a success because it established that I likely wouldn't be happy working with those devs and that kind of culture.

Re: I had to give a wrong answer to get the job (2017)

#333

Post by emerged »

rytill wrote: post #278
lmilcin wrote: post #266

Earlier quoted context omitted.

Unfortunately, you are wrong. Arrays used as backing for lists are faster than linked list in almost all cases, assuming they are implemented correctly (as is the case in Java, which I bring as an example). Linked lists have a lot of huge downsides that are not easily captured in their naive big-O characterization. Big-O does not tell anything about how efficient things are. Two algorithms can have same big-O complex…

GP basically created a hypothetical situation wherein they were right, and then here you are saying they're wrong. The only case in which you would be right in saying the GP is unequivocally wrong is if dynamic arrays were Pareto-optimal compared to linked lists. Alice: Can you think of any situation where apples are better than oranges? Bob: Well, if someone had a craving for apples, then they would be better. Charl…

Sorry but your analogy makes no sense because Kiwis are better.

Re: I had to give a wrong answer to get the job (2017)

#334

Post by [deleted] »

Buttons840 wrote: post #303
lmilcin wrote: post #290

Earlier quoted context omitted.

> None of the comments above yours in the thread mention any form of the word "fast" or "speed". They mention "performance" in reference to big-O complexity. Big-O is not always about speed. I am sorry, do you want to say "performance" and "big-O" have nothing to with trying to make the program go faster? I think you have lost your way and need to backtrack a little bit. The whole point of big-O analysis is to be abl…

If I ask for something to be done in O(1) I'm not asking for it to be fast, I'm asking for it to take the exact same amount of time every time no matter what. That might end up being slower, but so what, maybe that's what I need. If I ask for an O(1) algorithm and you build something that is as fast as possible, faster in every case, but sometimes it's really fast and sometimes it's a little less fast but still fast…

[deleted]

Re: I had to give a wrong answer to get the job (2017)

#335

Post by stirfish »

munificent wrote: post #127

I bombed an interview at a game company because I gave a right answer that I couldn't get them to understand. I don't remember the exact problem they wanted me to solve, but the answer involved a dynamic collection and they wanted it to grow with constant time complexity. They were probably looking for a linked list. But I said I'd use a dynamic array because those have constant time when averaged over a series of ap…

Game Programming Patterns is one of my favorite books btw

Re: I had to give a wrong answer to get the job (2017)

#336

Post by dcow »

emerged wrote: post #333
rytill wrote: post #278

Earlier quoted context omitted.

GP basically created a hypothetical situation wherein they were right, and then here you are saying they're wrong. The only case in which you would be right in saying the GP is unequivocally wrong is if dynamic arrays were Pareto-optimal compared to linked lists. Alice: Can you think of any situation where apples are better than oranges? Bob: Well, if someone had a craving for apples, then they would be better. Charl…

Sorry but your analogy makes no sense because Kiwis are better.

Worth the DVs (;

Re: I had to give a wrong answer to get the job (2017)

#337

Post by CuriousCosmic »

lmilcin wrote: post #316
benibela wrote: post #315

Earlier quoted context omitted.

Linked lists are better for immutable/persistent structures

If your data structure is immutable, then an array is always faster than a linked list.

Immutable doesn't necessarily mean unchanging in the context of data structures.

An immutable data structure can support adding, removing, and/or changing the data but the way it does it is in such a way that once data is created it isn't modified until it is completely unused and unreferenced.

So an immutable data structure has the benefit that data stays the same and stays the same in memory so it can be shared where duplication exists. You can copy said data-structure but it won't actually modify the underlying data and will just allocate a new tag/head that holds some reference to the underlying data. Now this new copy can be modified and it will instead just allocate a new block of memory for the changed portion and stitch it in to the head/tag structure as if it was just some diff/delta.

Here immutable means that the underlying data is unchanging and can be reused/shared by multiple instances, not that it is unchanging at all from an external point of view.

Now in the case of your comment, an array is extraordinarily bad in most cases for an immutable data structure as it is extremely difficult to sub-divide and let go of unused/old parts without breaking that immutability for the in-use data. Linked lists have their own issues as well but can be a valid trade-off for certain types of immutable data structures. Generally though trees will be the primary underlying structure for these immutable data structures as they are easy to use for this purpose, have reasonably good lookup times, have reasonable worst time complexity, and most importantly decent average/amortised time complexity.

Re: I had to give a wrong answer to get the job (2017)

#338

Post by wrnr »

endymi0n wrote: post #237

To be honest, one of the best predictors I have for job performance is learning something new in a job interview. Sometimes I get the feeling there are far to few people like this in the industry, but if I want to hire great colleagues, that just works the best. Then again, I'd never ask a vanilla architecture question like the company in OP's post, as I've found that the best predictors for job performance are also…

Thats my favourite answer to my favourite question

Re: I had to give a wrong answer to get the job (2017)

#339

Post by thayne »

lmilcin wrote: post #266
dcow wrote: post #259

Earlier quoted context omitted.

I bet they weren’t as dumb as you think and you were passed on for being stubborn and drunk on ego. Of the many scenarios where amortized complexity is not okay, code in a tight loop where predictable performance is key, e.g. code running game logic, jumps immediately to the top of the list. The fact that you were unable to incorporate this into the conversation makes me suspect you were more interested in putting on…

Unfortunately, you are wrong. Arrays used as backing for lists are faster than linked list in almost all cases, assuming they are implemented correctly (as is the case in Java, which I bring as an example). Linked lists have a lot of huge downsides that are not easily captured in their naive big-O characterization. Big-O does not tell anything about how efficient things are. Two algorithms can have same big-O complex…

> That is because to find insertion/deletion place you must first run linear search on linked list and that costs a lot.

That isn't always true. If you already have a pointer to the position in the list, and the list has an API that supports it (which a good implementation would), then with a linked list you wouldn't need to traverse the list again.

That said, in most cases that probably isn't worth the downsides of a linked list, especially if the size of the list is small.

Post reply on HN