Is this common with today's interviews?



  • Greetings,

    It's been a *long* time since I've interviewed, but thought it would be wise to see if I am still marketable. Thus far it appears the interviews have gone well, but I've yet to hear back. It used to be at least one would get a canned, `sorry, but we'll keep you in our files.' Now it's simply crickets? It's probably just as well because I don't want to work for some company with this kind of basic communication problem.

    On an unrelated note, one of the interviews included a three page multiple-choice technical test. What does one do when none of the answers are correct? Pick one that's close? Write in the correct answer? I understand the need for these, and have used them in the past, but if you're giving one you really should make sure the answers exist (or better yet, don't use multiple choice).

    Finally -- this had me stumped -- I maintain a couple of open source programs in my spare time. This is useful as if someone requests a code sample, I can point to these programs. I've been under the impression this shows that (a) I really like to program, and (b) I understand the full lifecycle of a program. At one interview the director of engineering was rather hostile to this saying he wasn't sure I would be a good fit as I spend some time on (not during work hours) my own project. Weird.



  • @zmafoox said:

    At one interview the director of engineering was rather hostile to this saying he wasn't sure I would be a good fit as I spend some time on (not during work hours) my own project.
     

    This sounds like a sign that he's going to want you to spend a lot of your nominally non-work hours on work. 



  • @zmafoox said:

    I maintain a couple of open source programs in my spare time. ... and (b) I understand the full lifecycle of a program.

    You're working on some pretty unique open source programs.



  • @Someone You Know said:

    @zmafoox said:

    At one interview the director of engineering was rather hostile to this saying he wasn't sure I would be a good fit as I spend some time on (not during work hours) my own project.
     

    This sounds like a sign that he's going to want you to spend a lot of your nominally non-work hours on work. 

     Or the company has issues with the idea that they don't own everything you produce, but knows better than to say so out loud.

    Or maybe he's afraid you'll steal their proprietary code for open source use, which reminds me of the old adage that we see in others what we see in ourselves. He sees dishonesty.

     Either way, it's a reminder that an interview is a two way process. You dodged a bullet.



  •  Remember, they're not just interviewing you, you're also interviewing them. If someone's an asshat, well... bummer, move along to the next interview.


  • 🚽 Regular

    @zmafoox said:

    At one interview the director of engineering was rather hostile to this saying he wasn't sure I would be a good fit as I spend some time on (not during work hours) my own project. Weird.

    At least he was honest about it. Some employers are under the impression that if you do any side project, it's distracting you from your work. Some people have the self-discipline to keep their private projects separate from their paid-for projects, while others struggle and eventually find themselves out of a job because they weren't as productive. I think it's a big mistake to pre-emptively reject anyone who enjoys software engineering enough that they even do it in their spare time, though. If the director of engineering, point blank, rejected to offer you a job based on what you do on your spare time, then he can screw off as far as I'm concerned.



  • When I was young, you used to get a rejection letter, or one saying we'll keep you in our files. These days, most companies don't bother. Rude? Yes, but don't take it personally.

    The test is a typical  filter for folks who can't discern someones' skills by simply talking with them. Falacy: it gives them a relative numeric rating by which they can order the "quality" of the candidates. When the questions don't provide the correct answer, it tells YOU something about them, and the skill level of their senior developers (who most likely made up the test). If the test is a plethora of questions that can't be correctly answered (as opposed to an obvious typo), then you've learned something about your potential coworkers. Generally, I'd just write in what I think is the correct answer, why, and why none of the given choices are correct. If they have any brains, they'll see that you know your stuff (assuming you are correct). If they seem offended, then take that as a sign that what comes out of their mouths is always right, and anything you say is assumed wrong and must be justified, and even then...

    I agree with everyone that the director would expect you to live for his project at the expense of everything else - in and of itself a reason to walk away.

     



  • @blakeyrat said:

    You're working on some pretty unique open source programs.
     I give up, why do you say that? Take requirements, design, implement, test, bug fix, maintain with the occasional new feature. Is this not how most programs are done?

     

     

    mod: added quote bit because threaded views are for chumps! :D :D —dh



  • @taustin said:

    Or maybe he's afraid you'll steal their proprietary code for open source use, which reminds me of the old adage that we see in others what we see in ourselves. He sees dishonesty.

     

    I'd considered the, `steal their code,' but the job was in networking and my project is a compiler -- not a lot of overlap there :)

     



  • @zmafoox said:

    Thus far it appears the interviews have gone well, but I've yet to hear back. It used to be at least one would get a canned, `sorry, but we'll keep you in our files.' Now it's simply crickets? It's probably just as well because I don't want to work for some company with this kind of basic communication problem.

    With my current employer, I attended two interviews then a work day to see what I was in for (and for others in the company to weigh me up) and yet received no notification. After a week, I rang to find the outcome, and the person I spoke to seemed genuinely surprised I hadn't heard back. I later on got a letter inviting me to join the firm.

    Fast forward to several years later, and I interviewed some people for the role of my assistant. I was impressed by one such lad, and his second interview involved him joining me, the MD and the (then) team leader for a meal one night were we could talk in a more relaxed environment and I could observe the more subtle characteristics of my potental assistant. When we bid him goodbye, I agreed that we'd take him on and my team leader said he'd get the paperwork together.

    The next week when I was away on business, the lad called me up and wanted to know the outcome. I was embarrased and explained that he should have received an invitation to join us by now. I called up my team leader to  ascertain why the paperwork hadn't been processed. "oh, that - not had a chance to do it yet. It'll have to wait until you return." I was fuming at his callous attitude, especially when the lad had made it clear during the meal that his contract with his current employer was up for renewal and he needed a speedy decision - and yet my dickhead of a team leader sat on the paperwork.

    So, what does all that mean? Sometimes it's not good to judge an organisation by one or two individuals within it. Sometimes it's worth contacting them back to determine why you didn't get the position (on the assumption that if you've received no further communication, you didn't get the job). I know of some situations where people have done just that only to find they HAVE been invited to join but the letter got lost and HR assumed a non-response meant the candidate lost interest - at least a phone call or email ought to put you (and them) in a clearer position.

    @zmafoox said:

    On an unrelated note, one of the interviews included a three page multiple-choice technical test. What does one do when none of the answers are correct? Pick one that's close?

    Some tests have deliberately incorrect answers to judge what a person would do in this position - picking an incorrect answer is worse than not picking one. Usually this is something discussed post-test as part of the interview - how does a person react when all options offered are unsuitable? I think there was a tale on here of an interviewee point out that many answers on an interview test were incorrect, and the interviewer frostily cut the interview short (perhaps because they wrote the test). In the position you were in, I'd write something on the answer sheet to reflect that I didn't see a correct option there - at least distinguish that from giving no answer, which could indicate not even putting in any effort to think.

    @zmafoox said:

    At one interview the director of engineering was rather hostile to this saying he wasn't sure I would be a good fit as I spend some time on (not during work hours) my own project.

    I find that an odd response, too - perhaps he felt that you would prioritise your project over your working day and neglect your paid duties, despite the fact you made it clear it's a spare-time thing, or maybe he felt there was a conflict of interest.  Either way, I'd see you contributing to an open-source project as a plus point.



  • @zmafoox said:

    I give up, why do you say that? Take requirements, design, implement, test, bug fix, maintain with the occasional new feature. Is this not how most programs are done?

    The vast majority of open source products do not take requirements, design*, test**, or bug fix***. They maintain, but only because they have to because library versions are constantly changing and they have no choice.

    *) Or they do an initial cursory design, then live with it even when it's obvious it has problems, then come up with a lot of bull to justify it-- for example, Linux's lack of a stable ABI. Or Linux's allowing virtually any character in a filename. Or Linux's pig-headed insistence that "everything is a file". Or... pretty much all of Linux is an example of this, frankly.

    **) Unless you're really liberal with the word "test". "Works on my machine" is technically a test.

    ***) They'll usually fix bugs that get a lot of publicity or bugs that one of the developers notices while writing code. They generally will not actually read their own bug tracker, triage the bugs in it, or fix them unless they happen to be rewriting that component anyway.



  • @blakeyrat said:

    Or Linux's allowing virtually any character in a filename.

    That's a legacy hangover from the Unix days. I don't have an issue with it, actually - I was bought up on *nix and AmigaDOS so I found DOS/Window's restriction on the range of permissible characters odd. It still catches me out from time to time when transferring files back/forth between Win and *nix.

    @blakeyrat said:

    Or Linux's pig-headed insistence that "everything is a file".

    Again, that's come from Unix, which came from the C programming language (I believe). It's not that different from Windows interpreting things as a directory.



  • @Cassidy said:

    I don't have an issue with it, actually

    Even the unprintable characters? Like you can have a file named "[backspace]" (like, it's actually named the backspace character)? The only reason it's not a complete disaster is because people, by convention, don't give files names like that.

    I have a page bookmarked on my home browser that enumerates all the hundreds of reasons that it's a terrible design decision, too lazy to google it now. That said, I do agree with you: Windows and OS X are way too restrictive on filenames. I'm used to Classic MacOS where you could use any printable character except colon.

    @Cassidy said:

    Again, that's come from Unix, which came from the C programming language (I believe).

    ... and? Because it comes from Unix, you should NEVER second-guess it? I don't get your point here, or how it addresses my point which was "Linux developers never re-evaluate design decisions from the past".

    @Cassidy said:

    It's not that different from Windows interpreting things as a directory.

    Nobody's saying Windows doesn't have some questionable design decisions. But at least Windows doesn't take things that, and let's be honest, can not POSSIBLY be reasonably treated like files (say, a HDTV Tuner) and attempts to use them like files.


  • BINNED

    @zmafoox said:

    I'd considered the, `steal their code,' but the job was in networking and my project is a compiler -- not a lot of overlap there :)

     

    In that case, don't walk away -- run.



  • @blakeyrat said:

    Even the unprintable characters? Like you can have a file named ""? The only reason it's not a complete disaster is because people, by convention, don't give files names like that.

    I don't have an issue with it because I chose not to use unprintable characters in filenames. I agree that a stupid choice of character in the filename will make things more difficult and convoluted in future, but I've been brought up in a world where you're given enough rope to hang yourself.

     @blakeyrat said:

    That said, I do agree with you: Windows and OS X are way too restrictive on filenames. I'm used to Classic MacOS where you could use any printable character except colon.

    Didn't know that about MacOS (even though missus has a MacBook). I recall reading that it's not possible to create a file called "prn" under windows - something to do with legacy reasons, but I don't fully understand them.

    @blakeyrat said:

    ... and? Because it comes from Unix, you should NEVER second-guess it? I don't get your point here, or how it addresses my point which was "Linux developers never re-evaluate design decisions from the past".

    Aha. I initially interpreted your words as though this was an active design decision by the Linux developers, rather than the.. well.. reason you've just given there. Ignore my last.

    @blakeyrat said:

    Nobody's saying Windows doesn't have some questionable design decisions. But at least Windows doesn't take things that, and let's be honest, can not POSSIBLY be reasonably treated like files (say, a HDTV Tuner) and attempts to use them like files.

    Yah, I see your point there - just that the Linux/Unix approach is to have the device appear as a "file" so that it's addressable but it isn't manipulatable as a standard file: you don't edit it or back it up like an ordinary file, but you can interrogate it to obtain characteristics of that device, or direct output to that "file" to stream data through it in some way. In some ways it's just hiding the underlying OS operations from the end user - *nix people are used to copying files to the "/dev/dvdburner" file rather than fire up Nero or so.

    Windows has a similar approach in many cases - managing hardware used to be a case of dropping into a "folder" called Control Panel where each "file" was an applet that configured hardware; zip archives appear as an expandable folder in newer Windows Explorer. Granted not everything can be treated in the same way, as you say, but given end-users' familiarity with the concept of dropping items into a container, making many operations appear that way makes them more intuitive to the masses.


  • BINNED

    @blakeyrat said:

    Or Linux's allowing virtually any character in a filename. Or Linux's pig-headed insistence that "everything is a file". Or... pretty much all of Linux is an example of this, frankly.
    Have you read the Unix Hater's Handbook? People have actually been complaining about these things for decades.



  • @PedanticCurmudgeon said:

    @blakeyrat said:
    Or Linux's allowing virtually any character in a filename. Or Linux's pig-headed insistence that "everything is a file". Or... pretty much all of Linux is an example of this, frankly.
    Have you read the Unix Hater's Handbook? People have actually been complaining about these things for decades.

    Yes, but the real WTF is that the culture is so broken that none of the issues ever get fixed.



  • @zmafoox said:

    I'd considered the, `steal their code,' but the job was in networking and my project is a compiler -- not a lot of overlap there :)

     

    You have clearly never heard of the new WTF-language: GLOBOL



  • @blakeyrat said:

    @PedanticCurmudgeon said:
    @blakeyrat said:
    Or Linux's allowing virtually any character in a filename. Or Linux's pig-headed insistence that "everything is a file". Or... pretty much all of Linux is an example of this, frankly.
    Have you read the Unix Hater's Handbook? People have actually been complaining about these things for decades.

    Yes, but the real WTF is that the culture is so broken that none of the issues ever get fixed.

    It's not really something you can easily change. E.g. filenames: what if ext4 in kernel 3.5 suddenly decides to impose additional restrictions? Probably it will prevent hunderds of thousands of systems to never upgrade past that point. If something like that ever made it into the kernel it would be legitimately called a regression bug.

    I don't really see a problem with the everything-is-a-file philosophy. It's not like there aren't alternative methods (in kernel-space). Granted in user-space your alternatives are limited but that's the same on e.g. Windows.



  • @snoofle said:

    Generally, I'd just write in what I think is the correct answer, why, and why none of the given choices are correct. If they have any brains, they'll see that you know your stuff (assuming you are correct).
     

    Remind me some crappy UML test i had once. An unreadable diagram (unreadable as "draw in darkgray on a dark gray background, like the kind of shit you get when you can't user properly a copier). Two pages of questions were about analysing this diagram and suggest changes in it. My answer was that considering this diagram looked like a piece of shit drawn on toilet paper, probably while waiting the train or the tube, it failed it's most basic purpose: being a communication medium, and i suggested they just use regular paper as a start.

     

    Don't know why, i succeeded... Probably because considering the number of complaint they ignored this part of the test.

     



  • @dtech said:


    It's not really something you can easily change. E.g. filenames: what if ext4 in kernel 3.5 suddenly decides to impose additional restrictions? Probably it will prevent hunderds of thousands of systems to never upgrade past that point.

    People will not care if you impose restrictions that they are already following on their own.

    Don't start filenames with -

    No newlines

    No tabs

    Printable characters only

    No bloody colons ($PATH separator, remember?)

    Possibly none of <> ; | $ &

    A stupidly huge amount of scripts that people write these days assume most of those restrictions exist anyway, because it's bloody impossible to write scripts without it.
    Hell, just correctly dealing with spaces takes way more effort than it should.



  • @blakeyrat said:

    @PedanticCurmudgeon said:
    @blakeyrat said:
    Or Linux's allowing virtually any character in a filename. Or Linux's pig-headed insistence that "everything is a file". Or... pretty much all of Linux is an example of this, frankly.
    Have you read the Unix Hater's Handbook? People have actually been complaining about these things for decades.

    Yes, but the real WTF is that the culture is so broken that none of the issues ever get fixed.

    Oh, come on. Unix is a perfectly good OS for PDP-11s.



  • @Salamander said:

    A stupidly huge amount of scripts that people write these days assume most of those restrictions exist anyway, because it's bloody impossible to write scripts without it.

    Hell, just correctly dealing with spaces takes way more effort than it should.

    Since I'm at home right now, here's the link I mentioned. His point 2.1 is (basically) the same as Salamander's: since programs already assume "sane" filenames, restricting filenames at the OS level would fix more problems than it creates.



  • @Cassidy said:

    I recall reading that it's not possible to create a file called "prn" under windows - something to do with legacy reasons, but I don't fully understand them.
     

    In MS-DOS PRN is the character device file for the printer, similar to /dev/lp0 on *nix.  Since subdirectories didn`t exist until MS-DOS 2 it works in any directory.  The other common ones are CON (console), COMx (serial ports) and LPTx (parallel ports).



  •  @ShawnD said:

    In MS-DOS PRN is the character device file for the printer, similar to /dev/lp0 on *nix.  Since subdirectories didn`t exist until MS-DOS 2 it works in any directory.  The other common ones are CON (console), COMx (serial ports) and LPTx (parallel ports).

    And AUX, which I'm guessing is a more commonly-desired filename than those others. (At least, I've encountered tarballs that try to upack an "aux" directory, but have yet to meet an archive that included one called "con".)

     



  • @zmafoox said:

    It used to be at least one would get a canned, `sorry, but we'll keep you in our files.' Now it's simply crickets? It's probably just as well because I don't want to work for some company with this kind of basic communication problem.

    It takes two to communicate. Perhaps you should have done a follow up call with them to see what they thought. As I recall, that's one of the "rules of the interview" for the interviewee; Always follow up.

    If working freelance has taught me anything it's that silence isn't malicious. People get distracted or uncertain. So I keep on top of my clients with frequent emails and calls, you should do the same with your prospective employers, regardless of what you may think of them. Not every company has an HR department and if the lead developer is in charge of hiring, he or she may be busy with their primary job.


  • Discourse touched me in a no-no place

    @Cassidy said:

    I recall reading that it's not possible to create a file called "prn" under windows - something to do with legacy reasons, but I don't fully understand them.
    It's a device name. For the same reasons that blakeyrant disses linux for still using old behaviours, Windows won't (usually) allow you to create directories with certain reserved names - prn being one of them.


  • Discourse touched me in a no-no place

    @Salamander said:

    People will not care if you impose restrictions that they are already following on their own.

    [...]

    No bloody colons ($PATH separator, remember?)
    Have you looked in /sys/devices recently?



  • @Watson said:

     @ShawnD said:

    In MS-DOS PRN is the character device file for the printer, similar to /dev/lp0 on *nix.  Since subdirectories didn`t exist until MS-DOS 2 it works in any directory.  The other common ones are CON (console), COMx (serial ports) and LPTx (parallel ports).

    And AUX, which I'm guessing is a more commonly-desired filename than those others. (At least, I've encountered tarballs that try to upack an "aux" directory, but have yet to meet an archive that included one called "con".)

     

    You forgot arguably the most useful one, NUL.



  • @blakeyrat said:

    since programs already assume "sane" filenames, restricting filenames at the OS level would fix more problems than it creates.

    I feel the fault there lies with the developer of said programs not observing defensive programming, leaving input (filename in this case) unchecked or unsanitised.  I know enumerating characters in filenames at OS level will prevent this situation from arising, but a developer making that assumption is dangerous.

    @Soviut said:

    Not every company has an HR department and if the lead developer is in charge of hiring, he or she may be busy with their primary job.

    So they've taken the time and effort to interview someone who could relieve the workload and make them less busy, but they can't spare the time to follow up on the results of those interviews.  I've had to deal with people that have peculiar priorities like that ("I'm too busy to meet with anyone that can tell me how to work more efficiently and be less busy!")



  • @blakeyrat said:

    Nobody's saying Windows doesn't have some questionable design decisions. But at least Windows doesn't take things that, and let's be honest, can not POSSIBLY be reasonably treated like files (say, a HDTV Tuner) and attempts to use them like files.
    Isn't the only difference between Windows and *nix here that one puts all the devices in user-visible /dev directory, while the other one hides them in \.\ namespace (but which is still accessible with CreateFile API)?


  • ♿ (Parody)

    @blakeyrat said:

    Nobody's saying Windows doesn't have some questionable design decisions. But at least Windows doesn't take things that, and let's be honest, can not POSSIBLY be reasonably treated like files (say, a HDTV Tuner) and attempts to use them like files.

    You're begging the question here. I have no experience with interfacing with an HDTV Tuner, but I'd enjoy hearing you make up reasons why you're convinced that a common and useful interface paradigm cannot reasonably apply to some new device like an HDTV Tuner.



  • @PJH said:

    Have you looked in /sys/devices recently?

    Then you can have an exception to the rule just for /sys
    Frankly, I'd rather have kept colons in filenames, but that was made impossible by $PATH.
    We can at least restrict the use of the colon in as many places as possible to minimise WTFery.
    Or perhaps even better- smack the dopey gits who came up with two conflicting pseudo-rules for the filesystem.



  •  @Cassidy said:

    zip archives appear as an expandable folder in newer Windows Explorer.

    Unfortunately that only works with Windows Explorer, and doesn't appear to be made available across the rest of the OS. For example, I'll regularly package up an HTML email as a zip file to include the images and send it around the various people who need to preview it before we send that same file to the client (hence why I don't just send out the email, as it has to be sent to the client so that they can send it out themselves, and a forwarded email won't work)

    The natural thing to do would be to open the .html file within the .zip archive in a browser, any web browser, but because the images are still within the archive they don't display, which I then have to explain that even though a zip archive looks like a regular directory, it's not, and everything needs to be unpacked first before viewing. I wouldn't mind, but the browser is well aware that it's accessing a local file (the lack of http:// or similar in the address is a give-away) so it's not that the browsers are borking it every time, Windows just didn't do enough to make zip archives accessible.

     



  • @blakeyrat said:

    since programs already assume "sane" filenames, restricting filenames at the OS level would fix more problems than it creates.
     

    You'd destroy one of my favourite past-times; creating files on my Linux box with filenames that won't work on Windows, and then watch as Windows users complain when I email them or commit them to a versioning system. Shame on you for being such a spoilsport!



  • @ASheridan said:

     @Cassidy said:

    zip archives appear as an expandable folder in newer Windows Explorer.

    Unfortunately that only works with Windows Explorer, and doesn't appear to be made available across the rest of the OS. For example, I'll regularly package up an HTML email as a zip file to include the images and send it around the various people who need to preview it before we send that same file to the client (hence why I don't just send out the email, as it has to be sent to the client so that they can send it out themselves, and a forwarded email won't work)

    The natural thing to do would be to open the .html file within the .zip archive in a browser, any web browser, but because the images are still within the archive they don't display, which I then have to explain that even though a zip archive looks like a regular directory, it's not, and everything needs to be unpacked first before viewing. I wouldn't mind, but the browser is well aware that it's accessing a local file (the lack of http:// or similar in the address is a give-away) so it's not that the browsers are borking it every time, Windows just didn't do enough to make zip archives accessible.

     

    That's because a zip isn't a directory, it's a file.  If you want a directory, make a directory.  If you want a zip, make a zip.  They're apples and oranges.

    And lets assume Microsoft did what you suggest, how do you propose the OS figure out what you want to do when it accesses a zip?  If you try to open an HTML inside a zip, or have a hyperlink take you to a zip file (on a download site), how does Internet Explorer know the difference?  And do you then extend that behavior forcibly to other browsers, or should they stay "broken?"

     


  • BINNED

    @blakeyrat said:

    @PedanticCurmudgeon said:
    @blakeyrat said:
    Or Linux's allowing virtually any character in a filename. Or Linux's pig-headed insistence that "everything is a file". Or... pretty much all of Linux is an example of this, frankly.
    Have you read the Unix Hater's Handbook? People have actually been complaining about these things for decades.

    Yes, but the real WTF is that the culture is so broken that none of the issues ever get fixed.

    The key word here is culture. Cultures generally have customs that may seem horribly broken to outsiders. Have you considered the possibility that there's a good reason the issues never get fixed: they're not unmanageable problems for people within the culture?



  • @Master Chief said:

    That's because a zip isn't a directory, it's a file.  If you want a directory, make a directory.  If you want a zip, make a zip.  They're apples and oranges.

    I'd argue that it's a directory masquerading as a file.
    Fundamentally, what is an archive? A collection of files? I'm pretty sure I've seen something like that before.
    It's not that big a stretch to imagine fopen("C:\SomeZipFile.zip\Foo", "r") working identically to fopen("C:\AnOrdinaryFolder\Foo", "r")
    Slap that in so it's supported by the operating system, and the browsers will work perfectly. They won't even know its a zip file- they'll just think its an oddly named folder that takes fractionally longer to read.



  • @Master Chief said:

    That's because a zip isn't a directory, it's a file.  If you want a directory, make a directory.  If you want a zip, make a zip.  They're apples and oranges.

    And lets assume Microsoft did what you suggest, how do you propose the OS figure out what you want to do when it accesses a zip?  If you try to open an HTML inside a zip, or have a hyperlink take you to a zip file (on a download site), how does Internet Explorer know the difference?  And do you then extend that behavior forcibly to other browsers, or should they stay "broken?"

     

     You're right of course, a zip is a file and not a directory, so why doesn't Windows Explorer suggest that? I mean, it even gives it an icon that looks like a directory, and opens it up as if it were a directory, and as Windows hides file extensions by default, a lot of people get confused, and don't understand that there is a difference.

    If Microsoft did manage to make it work across the whole OS, I guess it would work the same way as it does on KDE (generally my preferred window manager, just because of features such as this) which uses KIO slaves to handle things like zip files (and other archive formats) as if they were local files. Very convenient and one of the main features I wish would make its way into Windows at some point. The current .zip archive situation in Windows is a bit broken in my opinion.

     


  • ♿ (Parody)

    @Master Chief said:

    That's because a zip isn't a directory, it's a file.  If you want a directory, make a directory.  If you want a zip, make a zip.  They're apples and oranges.

    You should totally let Microsoft know, because as ASheridan said, Explorer really blurs the distinction.

    @Master Chief said:

    And lets assume Microsoft did what you suggest, how do you propose the OS figure out what you want to do when it accesses a zip?  If you try to open an HTML inside a zip, or have a hyperlink take you to a zip file (on a download site), how does Internet Explorer know the difference?  And do you then extend that behavior forcibly to other browsers, or should they stay "broken?"

    I think you've misunderstood the scenario. The way I understood it, the user is looking at the archive in explorer, which he opens, and it appears in explorer as a folder. He opens up the html file into his browser, but the relative links to the other stuff in the archive doesn't show up. So you've got something that kinda sorta works as it seems like it should, but not completely. This seems like a great example of the sort of thing that blakey often rants about where features appear to the user to be more difficult than they should / need to be.



  • @ASheridan said:

    If Microsoft did manage to make it work across the whole OS...

    Peculiarly, they did at one point: not with ZIP archives, but with file compression. Files/dirs appeared blue (if that option in WinExpr was ticked) and dragging them to/from automagically compressed/decompressed as they entered/left the container. Let's not get into discussions of how it hammered the CPU and defeated hardware compression when doing backups - I think that's been done to death - how it appeared and worked seamlessly to the end user was quite good.

    @ASheridan said:

    The current .zip archive situation in Windows is a bit broken in my opinion.

    That. Without it, people would install 7-zip or winzip, both of which could read other archive files (tar, rar, bzip, gzip, tgz etc).  Now it seems those formats are overlooked because they're not natively supported by WinExpr



  • @ekolis said:

    You have clearly never heard of the new WTF-language: GLOBOL
    oh my god.... yet another esoteric one that I didn't know of.

    I don't think you deserve being thanked.



  • @Cassidy said:

    So, what does all that mean? Sometimes it's not good to judge an organisation by one or two individuals within it. Sometimes it's worth contacting them back to determine why you didn't get the position (on the assumption that if you've received no further communication, you didn't get the job). I know of some situations where people have done just that only to find they HAVE been invited to join but the letter got lost and HR assumed a non-response meant the candidate lost interest - at least a phone call or email ought to put you (and them) in a clearer position.

     

    Apologies to all who pointed out I should have followed up -- I did. This produced a single canned response. Had the lack of follow up occured  at a single company I'd have assumed something specific to that one. It happened multiple times which made me wonder if it had become the industry standard.

     



  • @Cassidy said:

    I feel the fault there lies with the developer of said programs not observing defensive programming, leaving input (filename in this case) unchecked or unsanitised.  I know enumerating characters in filenames at OS level will prevent this situation from arising, but a developer making that assumption is dangerous.

    Read the article I linked.

    You're technically correct-- in fact that's why git doesn't use any of the standard shell commands in favor of writing their own. BUT when you have a system that can have a carriage return in a filename, and none of your shell tools to enumerate filenames can cope with that that is a problem. And your little pronouncement then becomes, "you MUST write EVERYTHING in C or C++ because none of the built-in tools can handle filenames correctly" which is fucking ridiculous. What's the point of even having shell scripts in that case?

    If you read his essay, you'll see that with minor changes (making all non-printing characters illegal in filenames; changing the IFS separator list; decreeing that all filenames must be stored as UTF-8 all the time), all of the currently broken shell scripts suddenly start working as if by magic, with no change to the shell language.

    @Cassidy said:

    I've had to deal with people that have peculiar priorities like that ("I'm too busy to meet with anyone that can tell me how to work more efficiently and be less busy!")

    There's a certain class of people who spend all their work time pretending to be 5 times more busy than they actually are, to avoid getting more work assigned to them, or in a misguided effort to make themselves appear more critical to the business. He could just be one of those people.



  • @Cassidy said:

    Peculiarly, they did at one point: not with ZIP archives, but with file compression. Files/dirs appeared blue (if that option in WinExpr was ticked) and dragging them to/from automagically compressed/decompressed as they entered/left the container. Let's not get into discussions of how it hammered the CPU and defeated hardware compression when doing backups - I think that's been done to death - how it appeared and worked seamlessly to the end user was quite good.

    If you're talking about NTFS compression, that's done by the filesystem, not Explorer. And the entire point there is that the files are only compressed while on disk-- you can't send a NTFS-compressed file to another person over email. You can send a .zip file over email. That is the difference. And your griping about the performance issues are pretty out-of-date, when did you try it, Windows 2000?



  • @boomzilla said:

    @blakeyrat said:
    Nobody's saying Windows doesn't have some questionable design decisions. But at least Windows doesn't take things that, and let's be honest, can not POSSIBLY be reasonably treated like files (say, a HDTV Tuner) and attempts to use them like files.

    You're begging the question here. I have no experience with interfacing with an HDTV Tuner, but I'd enjoy hearing you make up reasons why you're convinced that a common and useful interface paradigm cannot reasonably apply to some new device like an HDTV Tuner.

    Wow I was about to answer that, then I saw the username attached to it: "Boomzilla." Oh that idiot again.

    Fuck off and go away. You do nothing but troll me on this board. If you're interesting in having a serious conversation, let me kn-- actually don't because you'd be lying about it to troll me some more. Let's stick with "fuck off and go away."


  • ♿ (Parody)

    @blakeyrat said:

    Wow I was about to answer that, then I saw the username attached to it: "Boomzilla." Oh that idiot again.

    Fuck off and go away. You do nothing but troll me on this board. If you're interesting in having a serious conversation, let me kn-- actually don't because you'd be lying about it to troll me some more. Let's stick with "fuck off and go away."

    Well, I was actually interested to hear your rationalizations about why no one should do something that you wouldn't do, but I'm equally happy to get you to shut the fuck up about it.


  • 🚽 Regular

    @zmafoox said:

    Apologies to all who pointed out I should have followed up -- I did. This produced a single canned response. Had the lack of follow up occured  at a single company I'd have assumed something specific to that one. It happened multiple times which made me wonder if it had become the industry standard.

    This could even be just a sign of the economic times. Thanks to the unemployment rate I'm sure, on average, you're pitting yourself against more candidates than years past, the "value" of human resources is lower than before, thus they don't feel like giving every candidate the mere consolation prize of a "thanks but no thanks" note. If you are back on the market a few years from now when (hopefully) the economy is a bit more healthy you might find friendlier employers who are more willing to give candidates the time of day whether or not they're interested in you. Either that, or google yourself and make sure you don't share your name with some guy who might not deserve any respect, such as a registered sex offender or a neo-nazi skinhead. :)



  • @Master Chief said:

    That's because a zip isn't a directory, it's a file.  If you want a directory, make a directory.  If you want a zip, make a zip.  They're apples and oranges.
     

    I disagree. You may've been brought up with the idea that zip files are files, but conceptually, they're closer to folders than files.

    The problem is not that zips are treated as folders, it's that they're almost treated as folders, instead of completely and transparently.

    @Master Chief said:

    If you try to open an HTML inside a zip, or have a hyperlink take you to a zip file (on a download site), how does Internet Explorer know the difference?

    I don't see a problem with the hypothetical situation. Browsers don't need to do anything.

    file:///bla.zip -> opens the ZIP file in the associated application

    file:///bla.zip/compressedfile.bmp ->opens the bmp file

    http://domain/bla.zip -> displays the download dialog for the zip

    http://domain/bla.zip/compressedfile.bmp -> displays the download dialog for the bmp

     

    The implementation for this resides on the server that returns the data, not the browsers. Browsers just need to interpret the response's content-type and mime-type as they always do, so nothing changes for browsers and nothing breaks.



  • @ASheridan said:

    a lot of people get confused, and don't understand that there is a difference.
     

    What are the use cases where the difference becomes a problem?

    @ASheridan said:

    The current .zip archive situation in Windows is a bit broken in my opinion.

    Agreed! It is almost but not quite entirely like transparent handling.

     


Log in to reply