<spoiler>pre madonna</spoiler> on a ¡Jedi! hunt
-
The problem setter assumed that you'd end up having an if() statement for the overlap and having different executions depending on the overlap which wouldn't be O(1) time given varying inputs.
I... don't think that's how O(1) works...
-
Sure it is.
The point of O(1) is that the function takes a constant amount of time to run regardless of the inputs. As in this case, it takes the same amount of time to run whether there's an overlap or not.
-
The point of O(1) is that the function
takes a constant amount of time to runhas a constant upper bound of time taken regardless of the inputs.
-
The point of O(1) is that the function takes a constant amount of time to run regardless of the
inputssize of the input.Fixed that for you. An O(1) algorithm would be one where you can calculate the total covered area in a constant amount of time regardless of the number of rectangles.
-
The problem specifically calls for two rectangles and the difference in time is based on whether they overlap or not. Most solutions for the problem at hand have an if/else branch where one side takes longer than the other. While one branch is slower, it is consistently slower than the other and can give you a worst-case deal.
I'm reporting how the question was phrased and the intent behind it - not my fault their terminology (they were the ones who used "O(1) space and time complexity" in the spec) is not 100% accurate, but what they were trying to get across is 'we want this to run in the same length of time regardless of if/else branch you're doing, which we don't think can be done in PHP'.
-
not my fault their terminology (they were the ones who used "O(1) space and time complexity" in the spec) is not 100% accurate
YMBNH if you're actually complaining about that.
-
I'm not complaining about it. I'm merely outlining that the problem they set, they thought was impossible and I showed them that it wasn't - and they're retards.
But this is IT, it's hardly surprising
-
we want this to run in the same length of time regardless of if/else branch you're doing
Can't you just fill the quicker branch with pointless busywork?
-
We're talking a branch of (a multiplication plus a multiplication), versus (a multiplication plus a multiplication, minus another multiplication where the numbers are subtractions of variables we already have)
Getting the busywork to match up would be semi pointless. Fun fact: for cases where there's no overlap it actually runs slower than it could - but the same as the slower branch.
-
Here we just ask for basic logic, but the candidates don't even seen to understand that one DateTime being lesser than the other does not mean they represent different days. (they forget about time)
It still bugs me that C# has no separate "Date" and "Time" type. Especially after they were added to SQL...
Our codebase has its own "Date" class we use fucking everywhere. Wouldn't it be nice if we didn't have to create one of our own?
-
I... don't think that's how O(1) works...
That only makes sense if the problem is stated as:
You have N rectangles, N >= 2, which may overlap...
With only 2 rectangles, the Big O is kind of pointless.
-
Note that constant runtime regardless of the inputs (or even whether the inputs are valid) may be a requirement for cryptographic functions.
-
Who would write such in PHP?
-
Only tangentially related, but the login process in Linux used to fail faster if a username didn't exist than if it did and just had the wrong password.
Needless to say, that was an information leak and was eventually fixed.
-
I did say that on one I had literally no idea on. If I'd encountered it in a work situation, I'd have Googled it, but this was a pen-and-paper test.
Write "google.com" in a box with a notation to the side "internet is down".
-
You might be NetHack?
-
You might be NetHack?
I think NetHack is a pretty cool guy. Eh kills ASCIIs and isn't afraid of anything.
-
@Lorne_Kates said:
How do you get only the date portion of the current date? (bonus points for doing this in SQL)
Which version of SQL Server? It can be simple and elegant...
select convert(date, getdate())Or hacky, if you're not on 2008 or above.
select convert(datetime, floor(convert(float, getdate())))What happens when you convert a datetime to a float? You get the number of days since January 1, 1900 as a floating point number, of course!
-
Is Ericsson still even a company any more?
Uh, yeah?
How many jobs do you think there are in the world that he would be a good fit for...
Bunches? He has some non-trivial commits to Redis in a variety of languages. The creator of Redis mentions that Stancliff was working at Pivotal as a core Redis developer. Granted, when Aphyr looked at Redis three years ago, its data safety promises didn't match up with what Antirez actually designed, but it's pretty clear that the problems found are in Redis' design, rather than its implementation. (And if you think designing a non-trivial distributed database is easy, go give it a try and run it against Jepsen. ;) ) EDIT: I guess the Redis work happened after the "Job hunting sucks, guize!" post. That doesn't invalidate my point.
I get that we don't like it when outsiders display their ego, and that this is primarily a gripe forum, but there are numerous forum posts from TDWTFers (as well as FPPs) slagging one potential employer or another for being hostile, clueless, absurdly credentialist, or insultingly stingy with their compensation.
-
It still bugs me that C# has no separate "Date" and "Time" type. Especially after they were added to SQL...
Our codebase has its own "Date" class we use fucking everywhere. Wouldn't it be nice if we didn't have to create one of our own?
If I had to guess, I'd say the foot-dragging on implementation exists because for the majority of use cases, dates and times represent an event, and using just a date or a time means losing precision. Why have an invoice due date of January 13th when you could make it due January 13th at 5pm (or 9am)? Why measure shipping times in days when you can subtract the time a package was scanned at the warehouse from the time the recipient signs for the package?
-
@Lorne_Kates said:
I think NetHack is a pretty cool guy. Eh kills ASCIIs and isn't afraid of anything.
I thought you were supposed to eh at the end of your sentences. Is this weird speech affectation getting worse?
-
I'm not asking for them to REMOVE DateTIme, just add a separate Date and Time.
-
Why have an invoice due date of January 13th when you could make it due January 13th at 5pm (or 9am)?
Sure, but lots of things don't need that granularity, either. If you're storing an expiration date, or an effective date, or a birth date, you probably don't care about the time, so why store it?
-
Correct.
For the record, casting to a string and doing a substring then casting back to a date is also an answer that will accomplish two things:
- Get it done
- Get you fired for not knowing about datetime formats or locales
Filed under:
+ 
= 
-
@Lorne_Kates said:
casting to a string and doing a substring then casting back to a date
I've seen that done with a specified locale to make it unambiguous. There were a lot of weird ways to get a midnight date before sql2008
Also something using dateadd and the current date coasted to an int
-
Because any given instant will fall on at least two dates across different time zones.
-
Hiring is difficult. It's just as hard for companies to find good staff as it is for staff to find good companies. This guy wants to “fix hiring practises”, and that's great, but I'm not seeing anything to indicate that he's qualified to. All of his suggestions seem to revolve around making things better for the job seeker, which is probably why people who've been on the other side of the table might see him as a premadonna.
Rather than thinking about how everybody else should get better at hiring him, it might be better to focus on how he could get better at getting hired. Then next time maybe he won't end up somewhere you only get half a pc. Also notice that pivotal were less than a year old in 2013 — they came up pretty quick. Be interesting to see if their hiring process is still so lackadaisical now that they're more enterprise than startup.
-
If I had to guess, I'd say the foot-dragging on implementation exists because for the majority of use cases, dates and times represent an event, and using just a date or a time means losing precision.
If the data type you use doesn't give the precision you need, then you're using the wrong data type.
I was born at a certain date at a certain time. The appropriate data type is DateTime.
Christmas is an all day long event. The appropriate data type is Date.
I'm going to lunch in 5 minutes. The appropriate data type is Time.Why have an invoice due date of January 13th when you could make it due January 13th at 5pm (or 9am)?
Why indeed? As @FrostCat mentioned, that granularity doesn't make sense for an invoice due date (or an expiration date, as was his example).
Why measure shipping times in days when you can subtract the time a package was scanned at the warehouse from the time the recipient signs for the package?
Subtracting two Date/Time/DateTime things from eachother don't give you a new Date/Time/DateTime. It gives you yet another data type: you're looking for an Interval (or a Duration or a Period or whatever you'd like to call it).
-
Also notice that pivotal were less than a year old in 2013 — they came up pretty quick.
Sure, but they came out of Pivotal Labs (a consultancy firm that has -apparently- been around for at least twenty years (Wikpedia says 1989, the PL about page says that they've been in the business for at least 20 years.)), EMC, and VmWare. When I think fucked-up hiring practices, I generally don't think "EMC" or "VmWare".
I don't know anyone who worked for Pivotal in the early days, but it seems very likely that they were doing enterprise software from day #1: http://bits.blogs.nytimes.com/2013/04/01/emcs-amazon-challenger-comes-out/
-
Sure, but lots of things don't need that granularity, either. If you're storing an expiration date, or an effective date, or a birth date, you probably don't care about the time, so why store it?
Truncating to the date loses precision and creates ambiguity.
Expiration dates for physical products are naturally going to be ambiguous (and the actual date might vary by several days in either direction), but what about an expiration date that, say, controls whether an account can log into a website? When exactly does access expire - at 12:01 AM on the date? 5:00PM? 12:01AM on the following date?
As for birth dates, my birth certificate has a timestamp on it. Why not store the extra precision if it's available? What is there to lose by doing so?
Because any given instant will fall on at least two dates across different time zones.
All the more reason to store an unambiguous date + time + offset for all events!
If the data type you use doesn't give the precision you need, then you're using the wrong data type.
DateTime gives more precision than needed for a date. Why is this a bad thing? Is the project in question on an embedded system with kilobytes of storage?
Christmas is an all day long event. The appropriate data type is Date.
Or, it's an event that begins at 2016-12-25T00:00:00.000 and ends at 2016-12-26T00:00:00.000. What about events that don't necessarily begin and end at midnight?
I'm going to lunch in 5 minutes. The appropriate data type is Time.
The current timestamp is 2016-01-14T12:00:00.000. I'll be going to lunch at 2016-01-14T12:05:00.000. While that 5 minute figure may be useful in a conversational context, it's much less useful when looking at a series of historical events.
Why indeed? As @FrostCat mentioned, that granularity doesn't make sense for an invoice due date (or an expiration date, as was his example).
What if invoice payments are submitted electronically? What if payers are in multiple timezones? Are you going to note receipt by just storing the date? Are you going to determine timeliness by truncating the receipt timestamp to the date before performing the comparison?
Subtracting two Date/Time/DateTime things from eachother don't give you a new Date/Time/DateTime. It gives you yet another data type: you're looking for an Interval (or a Duration or a Period or whatever you'd like to call it).
You'll note that I said nothing about the result of subtracting two DateTimes, so being pendantic about what type the result is is just being pendantic for pendantry's sake.
Whatever you want to call it, it gives much more useful results than just comparing day intervals. If you've upgraded the routing algorithms for your shipping trucks to save, on average, half an hour in transit times, how else will you know if the upgrade is working?
-
As for birth dates, my birth certificate has a timestamp on it. Why not store the extra precision if it's available? What is there to lose by doing so?
Because out there in the real world approximately nobody cares what time of day you were born. Like I said, on your 21st birthday, walk into a liquor store an hour before the time of day you were born and see if they refuse to sell you anything. They won't. The extra precision is of no value unless you're the twin brother, son of royalty, and people need to know if you or he are the heir.
DateTime gives more precision than needed for a date. Why is this a bad thing?
You ever see that episode of TNG where Data tells Picard he thought Picard might like a few extra
digitsnumbers[1]?What if invoice payments are submitted electronically?
What if you're overthinking this?
[1] preemptive anti-
-
Because out there in the real world approximately nobody cares what time of day you were born.
That's because, sadly, most of the real world is not composed of pedantic dickweeds.
Like I said, on your 21st birthday, walk into a liquor store an hour before the time of day you were born and see if they refuse to sell you anything. They won't.
They should! Except that the laws are probably written such that a day is the minimum temporal resolution, so it wouldn't matter.
The extra precision is of no value unless you're the twin brother, son of royalty, and people need to know if you or he are the heir.
Or unless you're a pedantic dickweed who wants to know the precise time.
You ever see that episode of TNG where Data tells Picard he thought Picard might like a few extra
digitsnumbers[1]?TNG is on my bucket list, but I'll take your word for it for now.
What if you're overthinking this?
This is possible, but I see no harm in storing the full timestamp in each of the cases I outlined above, and many potential benefits. Among them is acclimatizing people to the idea that timestamps are opaque numbers so that we can gradually transition off this dumb system where we have 12 months of unequal length within a year of an uneven amount of days that are assumed to be 24 hours* in length.
*shit just got sidereal
-
so it wouldn't matter.
And that, in fact, is why we don't need the extra precision. It is a waste to store something that won't be used.
-
-
-
sadly, most of the real world is not composed of pedantic dickweeds.
Sad, indeed.
However, perhaps it is for the best. By the objective measure of number of
s awarded, I am the biggest pedantic dickweed here, and even I get annoyed by some of the other pedantic dickweeds. If everyone were a pedantic dickweed, I suspect the world would be a less pleasant place.
-
The current timestamp is 2016-01-14T12:00:00.000. I'll be going to lunch at 2016-01-14T12:05:00.000. While that 5 minute figure may be useful in a conversational context, it's much less useful when looking at a series of historical events.
I think the confusion here is that "5 minutes" is a duration. Basically the ptrdiff_t of time.
You do need two types for time-related shenanigans: a timestamp type and a duration type. You are correct that having an additional date-only type is pointless. Go's timestamp type includes a time zone, which is nice.
-
>any given instant will fall on at least two dates across different time zones.
All the more reason to store an unambiguous date + time + offset for all events
...
@Groaner said:>Christmas is an all day long event. The appropriate data type is Date.
Or, it's an event that begins at 2016-12-25T00:00:00.000 and ends at 2016-12-26T00:00:00.000.
Where's your unambiguous timezone offset then?
-
I wouldn't know the first thing about the actual hiring practises of any of those firms; what I was getting at was that they sounded more like Amazon from that old Joel article than a Ben&Jerry's. “I still don't know if the lack of formal real-time testing was intentional or if everybody just thought someone else already did that part of the evaluation” certainly suggests there was some kind of rush happening, to me. Between having plenty of capital behind them, their big ambitions, and the whole pair-programming, 9-to-6-with-minimal-downtime thing, the picture I'm getting is of a company that could afford to be a bit less selective than the rest.
Anyway, while I'm playing devil's advocate, I would like to highlight this commit:
Remove malloc failure checks · redis/redis@8d70218
We trust zmalloc to kill the whole process on memory failure
“We trust zmalloc to kill the whole process on memory failure”. Are null checks really so costly that it's worth it to disregard the possibility of someone doing something like this
redis/deps/hiredis/zmalloc.h at 3.2 · redis/redis
Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs,...
?
-
What's your unambiguous location for the event?
-
It doesn't have one. Just a Date.
-
So how do you store the date unambiguously? Presumably with a duration past a predefined starting timestamp. Let's say 1970-01-01T00:00:00Z.
-
25 December.
-
DateTime gives more precision than needed for a date. Why is this a bad thing? Is the project in question on an embedded system with kilobytes of storage?
Because you get dumb shit like this:
DateTime ExpireDate = DateTime.Now.AddDays(7) SaveExpireDate(user_id, ExpireDate) ' Much later on: ExpireDate = GetExpireDate(user_id) If ExpireDate < DateTime.Now Response.Redirect("Expired.aspx", True) End IfIn that code, if my ExpireDate is set to Jan 7th, 5pm, and I come back Jan 14th 3pm and again Jan 14th 6pm, I get two different results. But I thought I should have access all day on Jan 14th.
Because certain
coders don't know about DateDiff(day), you end up with all the hackyhacks with setting to midnight, or taking off the time portion, so that everything can be compared at the same Time.@FrostCat said:
Because out there in the real world approximately nobody cares what time of day you were born.
That's because, sadly, most of the real world is not composed of pedantic dickweeds.In Ontario, the age of majority to buy liquor is 19.
Let's say I was born at 4:56pm.
If I went to the store on Oct 28th, 1997 at 4:30pm, should I be allowed to buy liquor? Will the store clerk care what time I was born vs. what the day is?
-
@Lorne_Kates said:
Because certain
coders don't know about DateDiff(day), you end up with all the hackyhacks with setting to midnight, or taking off the time portion, so that everything can be compared at the same Time.
There's alwaysDateTime.DateandDateTime.TimeOfDay
-
@Lorne_Kates said:
Because certain
coders don't know about DateDiff(day), you end up with all the hackyhacks with setting to midnight, or taking off the time portion, so that everything can be compared at the same Time.I would hope that your date source would set it to all 0s.
For that matter, DateTime zeroes out the time if you don't specify it.
Filed under: ...unlike Java's Date and Calendar objects, Java's Date has always been a WTF though
-
There's always DateTime.Date and DateTime.TimeOfDay
There certainly is. Which is why I would ask the questions I asked of an interviewer. There's a few right ways of doing it, a few wrong ways of doing it so that it'll sometimes work, and plenty of ways of doing it really wrong.
-
Except he can't help coming off as a spoiled primadona who expected red carpet to be rolled out for him.
I need an example of him being spoiled. Recruitment people need to learn people skills, otherwise people like me, who've seen this bullshit before, stop bothering to be loyal after 4-odd redundancies and numerous disparaging rejections in the very moment it takes longer to recruit us than it does for us to find work.
I realise that sounds like an ultimatum, and it is! Largely because the only way to negotiate seems to be with ultimatums, but for some reason nobody saw coming the day when the fully-grown developer has somebody to go to other than you.
He's expecting to be shown some respect. The interview will be at this time, for this job at this location. Don't waste our time and we won't waste yours. That's the deal. That's civility.
Failure to follow this basic social protocol is the reason I have become mercenary in my career, such that my last manager complained when I didn't negotiate with him before I handed in my notice. I never had a chance to negotiate when I was being made redundant in previous jobs, what makes him think he's so entitled? For that matter, it says a lot about his ego that he can't read the sub-text that I didn't want to work for him.
There is an attitude that "this is the way things are". That's great, but everyone also needs to regard the way things should be, and we need to do that by not automatically assuming we deserve to be put above everyone else, and as far as I'm concerned, the kind of things he appears to be asking for are fair.
The only complaint I really have about the issues he's pointed out is that he didn't make it funnier.
You walk down the street, you meet a jerk - you met a jerk. You meet 10 jerks - you're the jerk.
While generally a reliable model, the first 3 senior people I met when I started my career were ridiculously incompetent. All of them wanted to blame me for issues they had caused, and had their own unique methods of CYA:
- The director of the first company I worked for was poor at time management, and told me I was 'sloppy' as a result.
- The next guy I worked for basically said "you've got nowhere else to go" and paid me less than minimum wage. Then he tried to pay me in some kind of coupons. Then it was apparently my fault I couldn't afford to get to work.
- Then there was the guy who yelled at me for 15 minutes because he couldn't keep his own CRM up to date with the correct contact details.
The model you speak of was sufficient to hurt my self-esteem a lot at the time, but it turns out that the street I was walking down had hundreds of students and few employers. These backwater companies I had worked for had their pick of entry-level graduates, while they grew, shrank and blamed the devs in the process. I met 3 jerks because I was walking down jerk street, where all the jerks go because they've been chucked out of civilised society.
He points out the symptoms of might-makes-right philosophy, which is bad for our species, since "might" usually means "luckily got the big stick, which is not big enough to bat away the meteorite which will wipe us out".
In short, I think he has a point.
-
I need an example of him being spoiled.
Horribleness: Implied interest then never followed up again.
-
I need an example of him being spoiled.
This guy's being flown in, dined and lodged in hotels of his choosing (intentionally the most expensive ones, by his own account), given a fair interview, and then flown out to his preferred destination. FYI that's pretty big expense for the company, the kind of which few people in other industries can hope to incur.
The least he can do is sound a bit grateful for that.
Instead of whining how no one patted him on the head for the little homework he was asked to complete. Or how he was expected to actually demonstrate the knowledge he will need on the job (python stdlib).
Time complexity - Wikipedia
toaster.
