6 ms·

"Have you ever used a microwave? Great. Grab your apron and get going. The Big Mac rush starts around 11:30."

Clubber 9y ago
It's funny, back in the Delphi days, we had a famous interview question, "What's the difference between a procedure and a function?" If you couldn't answer that in 5 or so words, we knew you weren't to be hired. You'd be amazed at how many people couldn't. One guy went on for 20 minutes trying to BS an answer.
- wolfgke 9y ago
  > If you couldn't answer that in 5 or so words, we knew you weren't to be hired. I could answer this questions, but have a tendency for long, technical explanations. ;-)
- seanmcdirmid 9y ago
  The difference between a procedure and function is so nuanced, in the 80s maybe it meant something, today it would just come across as a pointless trivia question.
  - Clubber 9y ago
    A function returns a value. It doesn't really apply in C type dialects because everything is a function, but in Pascal type dialects, they were distinct as they are in PLSQL and TSQL. If you wrote anything in Delphi, you would have to know that, thus why we asked it. It's actually declared that way. procedure ShowTime; // A procedure with no parameters begin // Display the current date and time ShowMessage('Date and time is '+DateTimeToStr(Now)); end; function Average(a, b, c : Extended) : Extended; begin // return the average of the 3 passed numbers Result := Mean(a, b, c); end; Edit: thanks for the formatting tip. http://www.delphibasics.co.uk/Article.asp?Name=Routines http://www.delphibasics.co.uk/Article.asp?Name=Routines
    - gt2 9y ago
      seems like a silly gotcha -- a literal technicality. Aren't you worried you passed on some amazing talent because they didn't read the same "bibles" or study in the same "groups" as you?
      - Clubber 9y ago
        You literally couldn't program in Delphi if you didn't know that.
      - Stratoscope 9y ago
        Sure, if you were hiring someone with no Delphi/Pascal experience, for example a programmer who had worked in multiple languages and you expected to be able to learn Delphi quickly, then it would be a silly gotcha. But if you were interviewing someone who claimed to know Delphi/Pascal at all and didn't know this off the top of their head, it would be a big red flag. It would be like asking a C programmer what's the difference between "void foo(){...}" and "int foo(){...}". They had better be able to tell you the difference without having to think about it.
        Clubber 9y ago
        It's funny. Based on the responses, I can tell who has Delphi experience and who does not. Pretty good interview question for Delphi devs, I'd say. :) Sure beats 5 hour interviews about God knows what.
      - marcosdumay 9y ago
        If you were programing in Pascal for 5 minutes, you would know the answer. It is a technicality, but a plainly accessible one. If "knows Pascal" is one of the job requirements, it's actually a good question.
      - mikestew 9y ago
        I haven't touched Delphi in twenty years, and I still remember the difference. It's fizz-buzz for Delphi devs: if you say you're a Delphi dev and don't know this off the top of your head, then you're lying about your experience.
- bitL 9y ago
  Now if you don't come up 5 times in a row with optimal solution to problems like how many possibilities there are for N companies to make mergers until only one company is left without caring about the order using dynamic programming and complicated combinatorics at each step, you won't be hired to write those boring JavaScript apps...
  - gt2 9y ago
    to be fair, there is now the benefit of a wealth of a) readily available info on what works/doesn't work and b) a lot more developers. Ok demand still outstrips supply probably but still, the best paying positions can afford to be choosey and demanding, no?
    - marcosdumay 9y ago
      > no? Very likely, no. Unless those companies somehow got very good on your "a" point and told nobody, their more filters they add the biggest the likelihood of having one that is anti-correlated to competence. And just one such filter can be enough to cut all the extremely few great candidates.
      - Clubber 9y ago
        It's amazing how risk averse companies are when good talent is so scarce. They need to take more risk on people, especially when it is so easy to fire people in the US. I wouldn't do a 5 hour interview, I don't care who the company is. I haven't had to do a cold interview (not referenced by an existing employee) since my first job out of college 20+ years ago. There is no way companies are going to find talent doing those long slog interviews, unless they pay 2x rates or something. Just the thought of 5 hour interviews makes my stomach queezy.
        bitL 9y ago
        I like doing those onsite interviews at Google, Facebook, Microsoft, Apple etc. once a year to keep in touch with what is required these days. Why not testing yourself? In the worst case you'll get just rejected, not blacklisted or sent to a Gulag :D
- logfromblammo 9y ago
  "Functions return a value." That's only 4 words. It seems like a rather cruel interview question, now that it qualifies as uninteresting trivia.
  - Clubber 9y ago
    That's why I said 5 or so. I was specifically looking for, "a function returns a value," which is 5. If you worked in Delphi, it most certainly isn't trivia. It's like asking what does void mean in C type dialects or what does the = vs == do. It's not trivia, it's trivial.
    - Stratoscope 9y ago
      > It's not trivia, it's trivial. That is a great quote; I hope you don't mind if I borrow it from time to time. The comments that this is "nuanced" or a "silly gotcha" are interesting. I wonder if these commenters have ever programmed in Delphi or Pascal? (No offense intended to those commenters if you have.) I've never used Delphi itself (although a program I wrote was bundled with it for a while, if you remember WinSight). I did write some Pascal code 35 years ago for DOS and the original Mac OS, but haven't touched the language or looked at it since then. But even I knew the answer to this right off the top of my head. It's so fundamental that if you don't know it, you don't know the language at all.
      - Clubber 9y ago
        >I hope you don't mind if I borrow it from time to time. Sure. >It's so fundamental that if you don't know it, you don't know the language at all. That's what we were shooting for. We knew there was no way we would know a rock star without working with them, and we were more than willing to accept good people who had room to improve. We couldn't accept someone who didn't know the language. It worked out really well for us. Because the interviews were short, we could fit a lot more in during a workday and get the process over quickly.
    - logfromblammo 9y ago
      Now that I exercise my memory of things past, I seem to recall that VB6 had "Function" and "Sub", too, which had essentially the same distinction, except there were some further differences if you ever tried to write Office macros. I never did voluntarily, because "real programmers" just didn't do that. But there was always some legacy POS written by a non-software person--who no longer works for the company, of course--that had been embedded into an Excel spreadsheet and never once tasted source control, but it was somehow critical to the business, anyway, and you might have been assigned the task of figuring out what it did and turning it into "real code". While I have a low sample size, it seemed like those reduced from about 10 MB of godawful brute-force spaghettified spreadsheet macro, down to about 10 lines of Java or C#, using algorithms and basic library functions. The hardest part is convincing your boss's boss that they both do the same thing, because the guy who wrote the macro spent so much time on it that there's just no way it could actually be so simple. As I favor considering aptitude in addition to skill, asking gotcha questions about jargon or syntax doesn't seem fair to someone who could hear that 4-word explanation and instantly understand what you meant.

It's funny, back in the Delphi days, we had a famous interview question, "What's the difference between a procedure and a function?" If you couldn't answer that in 5 or so words, we knew you weren't to be hired. You'd be amazed at how many people couldn't. One guy went on for 20 minutes trying to BS an answer.

wolfgke 9y ago
> If you couldn't answer that in 5 or so words, we knew you weren't to be hired. I could answer this questions, but have a tendency for long, technical explanations. ;-)
seanmcdirmid 9y ago
The difference between a procedure and function is so nuanced, in the 80s maybe it meant something, today it would just come across as a pointless trivia question.
- Clubber 9y ago
  A function returns a value. It doesn't really apply in C type dialects because everything is a function, but in Pascal type dialects, they were distinct as they are in PLSQL and TSQL. If you wrote anything in Delphi, you would have to know that, thus why we asked it. It's actually declared that way. procedure ShowTime; // A procedure with no parameters begin // Display the current date and time ShowMessage('Date and time is '+DateTimeToStr(Now)); end; function Average(a, b, c : Extended) : Extended; begin // return the average of the 3 passed numbers Result := Mean(a, b, c); end; Edit: thanks for the formatting tip. http://www.delphibasics.co.uk/Article.asp?Name=Routines http://www.delphibasics.co.uk/Article.asp?Name=Routines
  - gt2 9y ago
    seems like a silly gotcha -- a literal technicality. Aren't you worried you passed on some amazing talent because they didn't read the same "bibles" or study in the same "groups" as you?
    - Clubber 9y ago
      You literally couldn't program in Delphi if you didn't know that.
    - Stratoscope 9y ago
      Sure, if you were hiring someone with no Delphi/Pascal experience, for example a programmer who had worked in multiple languages and you expected to be able to learn Delphi quickly, then it would be a silly gotcha. But if you were interviewing someone who claimed to know Delphi/Pascal at all and didn't know this off the top of their head, it would be a big red flag. It would be like asking a C programmer what's the difference between "void foo(){...}" and "int foo(){...}". They had better be able to tell you the difference without having to think about it.
      - Clubber 9y ago
        It's funny. Based on the responses, I can tell who has Delphi experience and who does not. Pretty good interview question for Delphi devs, I'd say. :) Sure beats 5 hour interviews about God knows what.
    - marcosdumay 9y ago
      If you were programing in Pascal for 5 minutes, you would know the answer. It is a technicality, but a plainly accessible one. If "knows Pascal" is one of the job requirements, it's actually a good question.
    - mikestew 9y ago
      I haven't touched Delphi in twenty years, and I still remember the difference. It's fizz-buzz for Delphi devs: if you say you're a Delphi dev and don't know this off the top of your head, then you're lying about your experience.
bitL 9y ago
Now if you don't come up 5 times in a row with optimal solution to problems like how many possibilities there are for N companies to make mergers until only one company is left without caring about the order using dynamic programming and complicated combinatorics at each step, you won't be hired to write those boring JavaScript apps...
- gt2 9y ago
  to be fair, there is now the benefit of a wealth of a) readily available info on what works/doesn't work and b) a lot more developers. Ok demand still outstrips supply probably but still, the best paying positions can afford to be choosey and demanding, no?
  - marcosdumay 9y ago
    > no? Very likely, no. Unless those companies somehow got very good on your "a" point and told nobody, their more filters they add the biggest the likelihood of having one that is anti-correlated to competence. And just one such filter can be enough to cut all the extremely few great candidates.
    - Clubber 9y ago
      It's amazing how risk averse companies are when good talent is so scarce. They need to take more risk on people, especially when it is so easy to fire people in the US. I wouldn't do a 5 hour interview, I don't care who the company is. I haven't had to do a cold interview (not referenced by an existing employee) since my first job out of college 20+ years ago. There is no way companies are going to find talent doing those long slog interviews, unless they pay 2x rates or something. Just the thought of 5 hour interviews makes my stomach queezy.
      - bitL 9y ago
        I like doing those onsite interviews at Google, Facebook, Microsoft, Apple etc. once a year to keep in touch with what is required these days. Why not testing yourself? In the worst case you'll get just rejected, not blacklisted or sent to a Gulag :D
logfromblammo 9y ago
"Functions return a value." That's only 4 words. It seems like a rather cruel interview question, now that it qualifies as uninteresting trivia.
- Clubber 9y ago
  That's why I said 5 or so. I was specifically looking for, "a function returns a value," which is 5. If you worked in Delphi, it most certainly isn't trivia. It's like asking what does void mean in C type dialects or what does the = vs == do. It's not trivia, it's trivial.
  - Stratoscope 9y ago
    > It's not trivia, it's trivial. That is a great quote; I hope you don't mind if I borrow it from time to time. The comments that this is "nuanced" or a "silly gotcha" are interesting. I wonder if these commenters have ever programmed in Delphi or Pascal? (No offense intended to those commenters if you have.) I've never used Delphi itself (although a program I wrote was bundled with it for a while, if you remember WinSight). I did write some Pascal code 35 years ago for DOS and the original Mac OS, but haven't touched the language or looked at it since then. But even I knew the answer to this right off the top of my head. It's so fundamental that if you don't know it, you don't know the language at all.
    - Clubber 9y ago
      >I hope you don't mind if I borrow it from time to time. Sure. >It's so fundamental that if you don't know it, you don't know the language at all. That's what we were shooting for. We knew there was no way we would know a rock star without working with them, and we were more than willing to accept good people who had room to improve. We couldn't accept someone who didn't know the language. It worked out really well for us. Because the interviews were short, we could fit a lot more in during a workday and get the process over quickly.
  - logfromblammo 9y ago
    Now that I exercise my memory of things past, I seem to recall that VB6 had "Function" and "Sub", too, which had essentially the same distinction, except there were some further differences if you ever tried to write Office macros. I never did voluntarily, because "real programmers" just didn't do that. But there was always some legacy POS written by a non-software person--who no longer works for the company, of course--that had been embedded into an Excel spreadsheet and never once tasted source control, but it was somehow critical to the business, anyway, and you might have been assigned the task of figuring out what it did and turning it into "real code". While I have a low sample size, it seemed like those reduced from about 10 MB of godawful brute-force spaghettified spreadsheet macro, down to about 10 lines of Java or C#, using algorithms and basic library functions. The hardest part is convincing your boss's boss that they both do the same thing, because the guy who wrote the macro spent so much time on it that there's just no way it could actually be so simple. As I favor considering aptitude in addition to skill, asking gotcha questions about jargon or syntax doesn't seem fair to someone who could hear that 4-word explanation and instantly understand what you meant.