|
Re: On Interviewing and Interview Questions
by spurperl (Priest) on Aug 26, 2005 at 05:58 UTC
|
First of all ++, nice post with useful links :-)
I won't post any questions, there are tons of those, easily found on the web. I just want to stress the importance of one or two *serious* technical questions where the interviewee is required to (1) think and (2) write code.
I've seen quite a few people with glittering resumes and good presentational skills (i.e. they look/sound great on paper and in describing themselves), but who are hopelessly incompetent in writing code. People with "5 years of high-level super-complex C development" don't remember trivial things like pointer arithmetic and the idioms of memory allocation. Others were good in solving a question algorithmically, but when faced with a paper'n'pen couldn't produce anything coherent.
Therefore, I feel that technical questions are very important. An interviewee simply MUST write code. It may be small code, but he must write it. Even trivial stuff like (important especially in Perl) - read every line in a file and find how many times "BUBBA" appears in it, is important. | [reply] |
|
|
but when faced with a paper'n'pen couldn't produce anything coherent
You don't use paper and pen to program in real life, so asking people to do so in an interview is not very useful. We test peoples' technical aptitude by first giving them a little programming task. It's the same task for everyone, they have an hour and a half to get as much done as possible, and we don't expect people to complete it. They have access to the interweb and all the online docs.
Then we go through their code with them, and talk about other relevant stuff.
| [reply] |
|
|
When I'm faced with an unfamiliar computer, with an unfamiliar text / code editor, unfamiliarly configured, it's not too comforting. At least pen an paper are common for everyone :-)
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: On Interviewing and Interview Questions
by Tanktalus (Canon) on Aug 26, 2005 at 14:31 UTC
|
- What is a wiki?
- Assuming you've been exposed to these, it's fine, but personally, they drive me up the wall. ;-)
- What is a Design Pattern?
- It's been so long since I left school, that I don't remember formal definitions. But do you think that I'm a bad fit for your company just because I've been away from school for nearly a decade?
- What is a Code Smell?
- If it weren't for PM, I wouldn't have heard of this term. It's just a bit on the obscure side, IMO
- What are agile methodologies? (for example, Extreme Programming)
- Ask only if you religiously follow them because you want to know that the interviewee will be able to follow them. I'd flunk out of your interview here.
- What is Test Driven Development (TDD)?
- Isn't this exactly what the name implies? ;-)
- What is xUnit? (e.g. SUnit, JUnit, cppunit, NUnit, ...)
- No idea. ;-)
- Have you heard of Subversion?
- Isn't that the VCS that Linux used to use? Do you actually use Subversion? Or do you really only care that the person has been exposed to version control systems, and are willing to retrain for your specific VCS?
- Why do you want to work at our company?
- Because I'm unemployed and need some money?
- What are you good at? Bad at? Enjoy? Dislike?
- I'm good at coding, bad at stopping at 5 when I've got a deadline looming, and I extremely dislike personal time. If this isn't a question screaming for a cover-up, I don't know what is.
- What are your favourite books/magazines/web sites?
- Your company's website is my favourite. Seriously - do you want a perl geek who lives for perl, or do you want a well-balanced individual who has multiple facets to their lives and thus can think in many directions?
- What are your favourite tools? For example, if you start a new job, what tools *must* you install immediately?
- Perl?
- Tell me about the worst bug from hell (e.g. intermittent crashing program) you faced and how you solved it.
- Now we're getting somewhere. This is a question that is much harder to lie on, and will tell you a lot about the person you're interviewing. You'll see what they've done, and how they handled it. Which is important - because theoretical questions are fine, but they don't face the same time constraints as real problems. Asking, "How do you handle a bug" allows someone to wax eloquent on theoretical bugs. Asking, "How have you handled the worst bug you've faced" goes back in time to a point where they had real pressures - other classes if in school, or project deadlines if in a previous job, personal problems at home, whatever. You'll see what shortcuts they took, if any. It's a very powerful question.
- Describe in detail a recent project you developed that you are proud of.
- You may want to ask this before the previous question, and then focus your debugging question on this project. Also, ask about the role the person had in that project, why they had that role, etc.
Just a few points. Remebering that most people lie in an interview, you want to not ask open-ended questions. You want to ask very specific questions that get at the information you need. Most people don't intend to lie. They just do.
Interviewer: Does your mind ever wander during meetings?
Interviewee (to self): I can't remember any such time, so...
Interviewee: No
It's just a mix between trying to put your best foot forward, and not necessarily remembering everything in the heat of a short (30-90 minute) interview that would be easy to recall when the deadline is further away (say, end-of-day).
| [reply] |
|
|
But you have to admit, those triva questions are the best ones. They tell me as a potential employee that this is a fad driven company. It tells me that they're not serious about their craft. They aren't looking for professionals to help them solve problems. It sounds more like they're rounding up a bunch of low-level hacks to help a manager meet a hiring quota. It tells me the pay is low, and that they'll expect you to work 60 hour weeks like a freshly minted college grad. I'd guess that this company has a real high turnover rate, much higher than the industry average. But those are the negatives. On the plus side, if you decide to take the job, they're will be some tangible benefits. You'll be able to browse slashdot for hours on end, and no one will complain. You won't have to work very hard, because A) either this company is small, so it will likely be out of business soon, or B) this company is large and a reorganization will eliminate or vastly modify any project you should have been working on.
| [reply] |
|
|
Being able to answer these trivia questions isn't
necessarily a "pass".
Indeed, for some company cultures, "I don't know" may
well be the "pass" answer. After all, as you point out,
maybe they want to avoid hiring fad-driven
developers and cyber-loafers.
Though these questions are quick to ask (and therefore cheap)
for the interviewer, their drawback is that the act of
asking them may well put the applicant off the company --
as you were. I need to re-think these type of questions.
Update:
As pointed out to me by Rhose, and pontificated
on by Paul Graham in
The Python Paradox,
these trivia questions
may also help identify those people who actually
enjoy programming and computers.
| [reply] |
|
|
Re: On Interviewing and Interview Questions
by pg (Canon) on Aug 26, 2005 at 06:01 UTC
|
About personality, I would first focus on whether the person is a team player.
There are exceptions, but with the scale of today's application, most likely one has to work with others. A comparatively smart non-team player is the worst type of people you want on a team.
- If a person is not that smart, that's fine, there is always tasks for junior.
- If a person is smart and also a team player, great!
- if a person perceives himself as smart and not a team player. There is not much he can do, other than promoting stupid ideas by force.
| [reply] |
|
|
Team player is very important! I've worked on a project where one guy went off for months to work, more or less in secret, on an "interesting" problem, and came up with an "interesting" (but useless) solution - haemorrhaging money in the process. He went away.
| [reply] |
|
|
Yeah, this is what Jim McCarthy calls
Beware of a guy in a room (point 6).
Curiously, it's usually the most brilliant developer who goes dark. Years ago, the top programmer of a company
we were dealing with got away with saying "it will be ready next month" for 18 months without ever allowing
anyone to see his code until it was finished!
All developers, no matter how brilliant, must make their code available for public review in modest (fortnightly, say) increments.
Update: see also: Beware of a guy in a room (youtube)
| [reply] |
|
|
|
|
I understand what you mean but “team player” for many has come to be management code for “yes man.” I like to see a strong independent streak in everyone I work with. That doesn’t mean they can’t work together but that they can work alone.
A couple of the other stories above are horrifying but taking one for example: if the group’s manager lets a prima donna get away without, say, a simple code review/discuss/update at least once a month, it’s not the player that’s the problem.
Update 20210524: typo.
| [reply] |
Re: On Interviewing and Interview Questions
by demerphq (Chancellor) on Aug 26, 2005 at 15:59 UTC
|
Unix: What is the difference between a wild-card and a regular expression? Write the wildcard ls *.c as a regular expression in ls | grep 'put your regular expression here'.
I'd grin and point out that trick questions aren't very nice, then tell you that there is no difference. A wildcard is a regular expression, it just happens to have different syntax from the regular expressions you use in perl or grep. I'd also ask you which version of grep you meant, and enquire as to whether or not it supported PCRE or not.
And IMO this isn't a "unix" question, grep has been ported to just about every OS, and likewise just about every OS has ways of using regular expressions to query the file system.
PS: apologies, I just hate it when people put trick questions into tests. Like many people I'm not particularly good in test situations at all, and I dont need the stress of second guessing the question on top of trying to get the right answer while dealing with the stress of the test enviornment.
---
$world=~s/war/peace/g
| [reply] |
|
|
Howdy!
When I was interviewed for the job I currently hold, my
boss-to-be asked several questions from a list. The first
was "what is grep". The others were similar in their
difficulty.
When I remarked (after the fifth or sixth such question)
that these were not difficult questions, she noted that
they were not easy for everyone!
The questions were meant to smoke out someone whose actual
skills and knowledge were markedly at odds with what the
CV appeared to claim, and some of the candidates for my
position were apparently Not Up To Snuff. The questions
were not meant to be trick questions, or tough questions.
If they were difficult, it was a bad sign for the
candidate.
| [reply] |
|
|
| [reply]
[d/l]
[select] |
|
|
they have different meta characters (*?[] versus \^$[].|()?*+{}) and with different meanings for those meta characters. Moreover, wildcards are used by the shell to match existing filenames, while regular expressions are not so constrained.
Ok, and this is why i consider this partially to be a trick question, Ie one that brings up much more complex issues that it appears you realize.
To me the glob syntax is just an impoverished regular expression language. Even glob uses similar terms to describe it. Ie, a glob pattern can be directly converted to your regex language of choice. It lacks alternation and proper quantifiers, but that doesn't make it any less regular, just less useful (but of more predictable performance).
Anyway, I doubt I would have been so bashful in an interview scenario, I probably would have had to ask you for some clarification. "What is the difference between a wild-card and a regular expression?" to me is a pretty dodgy question. "The" difference? Umm. Which wild-card syntax and which regular expression syntax. Do you mean perl style (ir)regular-expressions or what? The second part of the question I think i would have got :-)
---
$world=~s/war/peace/g
| [reply] |
Re: On Interviewing and Interview Questions
by willyyam (Priest) on Aug 26, 2005 at 13:16 UTC
|
My two favourite interview questions are not specific to programming. I learned these questions in University while screening applicants for a major scholarship. Typically you would ask these questions at the end of the interview with about 15 minutes of time left.
Question 1: "What question are you glad I didn't ask?"
Question 2: "What question do you wish I had asked?"
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
Re: On Interviewing and Interview Questions
by jcoxen (Deacon) on Aug 26, 2005 at 16:49 UTC
|
I'm reminded of an interview I had several years ago for a Systems Administrator position. After I had been on the job for about 6 months, my boss told me why I got hired.
There were 3 strong candidates - any one of us would have been a good fit for the position and the company. During the interview, we each were asked the inevitable "The fecal matter has struck the rotary air impeller, what do you do?" question.
The other two candidates each fired off answers from the hip. When they asked me, I thought about it for a few seconds before answering - not because of any interview strategy but simply because I distrust pat answers and try very hard not to give them. Anyway, all of us answered the question correctly but I was the one that got hired. And all because I took 10 seconds to think before I answered.
What I'm getting at is that it's also important to consider HOW a question was answered, not just whether the answer was accurate. Is the interviewee rattling off prepared answers or is he taking the time to think about your questions and to consider his answers before opening his mouth?
Jack | [reply] |
Re: On Interviewing and Interview Questions
by derby (Abbot) on Aug 26, 2005 at 14:28 UTC
|
Why do you want to work at our company?
I've never really liked this question. What is a decent
answer?
- I need the money
- The commute will be much easier
- I don't know if I do or not, this interview will go a long way in helping me make a determination
- I have friends who work here and think I would be a good fit
- I've researched your company, like the products and think my skillset is a good fit
| [reply] |
|
|
Hm. That's one of my favorite questions. I think it's only a bad question if it's judged as good/bad and viewed independently of everything else at the interview. Here's how I would interpret your answers:
I need the money
The candidate isn't afraid to tell you the truth, even when the truth isn't what you wanted to hear. Still, I vastly prefer working with people who are at least as interested in the job as I am. It avoids the conveyor-belt working environment, and we all have fun and are usually more productive. Probe the candidate to see if that's really the only reason. There's nothing wrong with it as a motivating factor by itself.
The commute will be much easier
Pretty much the same as above. (Though problematic if you're thinking of moving the office a ways away soon!)
I don't know if I do or not, this interview will go a long way in helping me make a determination
Well, I'm biased, since that's pretty much the answer I give. I suppose you should be wary that the candidate doesn't care about the product the company is producing, but anyone who thinks they can predict what a company will be like to work for solely on the basis of the product they produce is fooling themselves anyway. A company might be producing the coolest, most fun thing ever, and yet internally it could be run as a military dictatorship by the CEO and the candidate will end up spending 90% of the time on support or distribution or documentation.
I have friends who work here and think I would be a good fit
Same as the first two, with an added positive that friends tend to work well together and an added negative that people who tag along after their friends may not care about the job much; they just want to work with their friends. (And they're following, not leading, so odds are they aren't as strong as the ones you've already hired. Okay, weak odds. Just something else to dig into.)
Be sure to separate out what the candidate did at previous jobs, rather than what the candidate's team did.
I've researched your company, like the products and think my skillset is a good fit
Possible BS alert. First, check how good of a job the candidate did at the research. And make extra sure that this isn't one of those candidates that knows how to produce the right answer to any question, but can't actually produce. (It's the "smart but can't get things done" type.) Any serious design or coding question should highlight those types pretty quickly, though.
If none those red flags turn out to be true, however, then this answer is a good sign that the candidate will add energy and morale to the team.
I will kill you if you don't let me have this job.
Always a good argument.
I have 20 years of experience doing exactly the sort of thing that you're hiring me for.
This is a good thing, but again raises red flags -- why does the candidate want to keep on working on exactly the same thing? Is the candidate flexible, or are you going to end up in endless arguments about why you can't do it in exactly the same way as the candidate has done it before? The specific needs of your company should be considered adequately.
I will sleep with you if you hire me.
The candidate is your spouse. (And in the long run your sex life will probably be better off if you keep your work relationship and personal relationship separate.)
| [reply] |
|
|
I'm curious what you'd think of the answers that I'd give.
The last 2 times that I successfully interviewed my answers would have been, (1) because I hate my current job and (2) because X (the person who referred me) said that this is an awesome group to work with, and if he lived here, this is where he'd work.
Both cases I got the interview through someone who the employer knew. In both cases the reference could confirm my reason, and in both cases the employer had tried to hire the reference.
| [reply] |
|
|
|
|
|
|
|
I'm looking for a job and this is one of the companies on my list. And just like you don't know yet whether you want me to work here, I don't know yet whether I want to work here either. Convince me.
Well ... "I will sleep with you if you hire me." doesn't sound like a response from a spouse. At least not the spouse of the interviewing person. Which means that at least in the short run the interviewers sex life might get a lot better. Especially if the interviewer is a programmer :-}
I wouldn't consider it a good answer though. At least unless you are interviewing someone to become nothing more than a coffee-cooking secretary.
Jenda
|
XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented. |
| [reply] |
|
|
My expectations for answers to this question are not high. I tend to be happy with almost any answer that indicates that they know at least a little bit about what we do and about what they want.
Wrong answers include:
- silence / *shrug* / other non-answers
- the recruiter I'm working with set this up, but neither he nor I could be bothered to prep me for the interview at all.
- I have no idea what I'm looking for in an employer / job. (This might be acceptable for a new college grad, but not for anyone with any real job experience.)
| [reply] |
Re: On Interviewing and Interview Questions
by Your Mother (Archbishop) on Aug 27, 2005 at 05:01 UTC
|
The one I always ask is:
What's the worst mistake you ever made at work and what did you do about it?
And I expect something pretty bad from anyone who's innovative or star material. I expect the type who has difficulty with integrity to not have any answer and dance around it till something lame occurs to him or her.
There is no right answer, of course. It's a chance to give a short character essay on oneself. The best replies I've heard for it tended to involve the most catastrophic kinds of mistakes. How the candidate discuss it and its result is the meat.
Update: Oh, ++, of course for the OP; and my own worst was pretty bad and I paid for it with an 85hr week and a crash course in Oracle queries; you won't get the story because even with the successful penance quite a few customers paid for it too.
| [reply] |
|
|
i bet someone once that the command:
cat /dev/urandom > /dev/hda1
wouldn't do anything. i was very wrong... on a production server. amazing the things that happen when you're *really* sure you're right :) | [reply]
[d/l] |
Re: On Interviewing and Interview Questions
by samizdat (Vicar) on Aug 26, 2005 at 14:09 UTC
|
I think it's very important to ask an applicant to describe something on paper or with a whiteboard. Is he|she capable of explaining a concept in words and pictures or is he|she just a code wonk? This simple exercise separates out a lot of people who can sound smart but are just throwing up a screen of bs, and it's a critical skill in team environments.
Pick a task that has several levels of detail to describe and see how your applicant deals with it. For example,
- Describe how a 'little language' is handled.
- How does a webserver handle FORM scripts and their data?
- How does the Internet transmit data?
- Describe the process of creating a new program as a team effort.
You want to observe them as they do it. Do they launch in, do they think for a minute, do they spew nonsense for a while while gearing up to make sense? My interviews are typically more about how a programmer operates than they are about what he|she can or has done. It's easy to separate out the technical losers, but it's more important to assess how someone functions and where they fall short in the process of getting the job done. | [reply] |
Re: On Interviewing and Interview Questions
by delegatrix (Scribe) on Aug 26, 2005 at 14:39 UTC
|
I look for enthusiasm for technology and the use of it to solve problems. I look for people with a curiosity to see what's out there and what's new.
I like to ask:
What project have you worked on that made you jazzed to come to work every day?
What project that you've worked on are you most proud of?
I want to see people speak enthusiastically about the work they've done. If you can't do that, what have you been wasting your time on?
| [reply] |
|
|
To answer the last question: looking for a job I can be proud of? ;-)
Seriously, joining your company (without actually knowing what company you work/hire for - it doesn't matter, this is true for all companies) isn't going to be all roses and sunshine, either. Knowing how a candidate works on bad days is probably just as important, if not moreso, as the good days.
| [reply] |
|
|
ad 1) Jazzed? Erm? Sorry? What's that word?
Anyway if I understand you right ... projects last. Sometimes months. I don't think you can remain jazzed all the time for so long. If you can, I'd like to know what do you take ;-)
ad 2) Yeah, this is a nice one. Let him/her boast about something and see what it is. Of course the problem is how much are they exagerating and how much of the project was their work.
Jenda
|
XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented. |
| [reply] |
Re: On Interviewing and Interview Questions
by radiantmatrix (Parson) on Aug 26, 2005 at 19:53 UTC
|
I've been on both ends of interviews of this type for a long time (ah, contracting). I was asked a question once that I liked so much I started asking it:
- What's one thing you're proud of accomplishing in the past year?
This helps answer the second question: I have interviewed people that were proud of so much they had done (and rightly so) that they had trouble picking something. That is a good sign. I've also had people who had trouble thinking of an accomplishment in the past year -- that's a bad sign.
Other than that, the interview questions I like best (that aren't covered in the OP):
- Why do you want to do this type of work? (I don't care why they picked my company, but why do they want to develop this type of software/whatever?)
- How do you resolve disputes over design? style? (Best answer to date: "I get a copy of the other's .perltidy.rc and run it before I check my work back in." -- good pragmatic approach.)
- What editor do you prefer? Why? (There's no wrong answer, but the why gives insight into thought processes and problem-solving. Most interesting answer to the 'why' so far: "because all of the preferences defaulted to the exact choices I'd have made: I figured I'd be well off to use an editor written by a guy who thinks like me.")
- (If applicable) What do you know about the product you'll be working on? What's its biggest flaw, in your opinion?
- What would you do if someone with authority asked you to do something you considered unethical?
IMO, these give an insight into how the person deals with tough situations, how much they cared to research the job, and if they are capable of adapting and problem-solving. If they are smart, productive, and adaptable, they are usually a shoe-in.
<-radiant.matrix->
Larry Wall is Yoda: there is no try{} (ok, except in Perl6; way to ruin a joke, Larry! ;P)
The Code that can be seen is not the true Code
"In any sufficiently large group of people, most are idiots" - Kaa's Law
| [reply] |
|
|
What's one thing you're proud of accomplishing in the past year?
"Not strangling the living **** out of marketing, product management, and others who have been obviously promoted past their competencies. Why do you think I'm looking for another job?"
(Hmmm ... maybe I should be posting this anonymously.)
Translation: there can be valid reasons not to have accomplished anything in the past year. Yes, it can be a red flag, but it has to be taken in context and may not actually be a bad thing. But that's why interviewing is an artform still, and not a science. :-)
| [reply] |
|
|
I take your point. However, I didn't say "professional accomplishments." I've hired a guy who answered "I bought my first house", as well as one who said "it may not seem like much, but I managed to finish Moby Dick".
See, what I'm interested in is twofold: first, whether the candidate actually gets things done; but, more importantly, that the candidate actually realizes their own accomplishments and feels pride in them. I'd imagine it's pretty rare for people to really have accomplished nothing in the past 12 months -- but it's very common for people to think they've accomplished nothing.
<-radiant.matrix->
Larry Wall is Yoda: there is no try{} (ok, except in Perl6; way to ruin a joke, Larry! ;P)
The Code that can be seen is not the true Code
"In any sufficiently large group of people, most are idiots" - Kaa's Law
| [reply] |
|
|
|
|
| [reply] |
Re: On Interviewing and Interview Questions
by hakkr (Chaplain) on Aug 26, 2005 at 08:55 UTC
|
Hi,
Not sure I would get the job;)
What is a Code Smell?
Is this a techinical term? I have no idea what the answer is.
Smell being slightly negative I would guess it means bad code?
| [reply] |
|
|
| [reply] |
|
|
I don't know what Code Smell is either but I know someone who does...
The serious point to this is that trivia questions are all very well but unless its targetted at the job being interviewed for then its useless. It's far better to ask questions in general terms about the subject matter that the job will involve and then ask more probing questions to get at the detail.
Nobody has all of the knowledge that they will ever need to do their job. The best people to have on your team are the ones that can 'work the problem' regardless of what the problem is. A good employee doesn't need to know the answer but should be able to relate to the problem and have a pretty good idea how to go about finding the answers.
| [reply] |
|
|
No, in no way do these questions say "Yes this person can do the job." But I think general trivia questions are being used to find out if the person is a good fit for the team. I think you can learn a lot about a person by looking at their frequently visited online sites.
For example, most of my coworkers look at me with a baffled expression when I mention a lot of the sites I visit. Though just about everyone I work with is a programmer, I think I'm the only one who has been to Joel Spolsky's site. I'm pretty sure I'm the only one in the company to visit Perlmonks (though there are a few people who claim to know Perl (I say claim because I've shuddered at some of their Perl code)).1
I spend a fair bit of time online, I like to work with others that also spend a lot of time online -- or reading. If I say "Pragmatic Programmer" I expect that a programmer should have some clue what it is (and hope that they've read it, but my personal reading list is already huge, I can only read so much in a day -- so I can understand if they haven't read it).
1 Update to add: I'm not claiming that visiting Perlmonks is a prerequisite for knowing Perl. Nor is visiting Perlmonks going to indicate that you know Perl. But having some vague notion of the things that I find to be very common online is a definite plus.
| [reply] |
Re: On Interviewing and Interview Questions
by dws (Chancellor) on Aug 26, 2005 at 18:18 UTC
|
Also
I'm not a hiring manager now, but I still use the technique, and still find it to be a very effective filter.
| [reply] |
|
|
I'd fail the specific example: I don't know how to play minesweeper. :-( And I doubt I'd get a good spec during the interview, since the interviewer would probably leave out all sorts of "obvious" details, since "everyone" knows how minesweeper works. Except me. :-( And that's assuming the interviewer is even a coder, and not some HR flunky getting me to fill in the blanks. :-(
*sigh*
I hate interviews. :-(
| [reply] |
|
|
| [reply] |
Re: On Interviewing and Interview Questions
by merzy (Scribe) on Aug 28, 2005 at 16:45 UTC
|
My favorite interview question:
"You've got a file on machine A and want to get it to machine B. Give me ten ways to do it."
You'd be surprised at how many people stall out at 3 or 5. It gives you a nice feel for both how their mind works and what they've been exposed to.
("Pigeons", for instance, would pretty much get you the job on the spot.)
| [reply] |
|
|
Pigeons are a lousy answer. It takes way too long to train them to memorize the file, and they usually make significant mistakes when asked to recite it back. :-)
Seriously, you never said machine B was more than ten feet away, and if all it takes it ten transport mechanisms to count as ten distinct answers, then the question can be answered trivially. ("Send a floppy by car/bus/train/pigeon/horse/elephant/ etc")
Here's my list:
- Retype it, using a hex editor if necessary.
- Put it on floppy/CD/zipdrive.
- Ethernet.
- Print the file, and scan it back using OCR. Use something like a uuencoding if necessary.
- Nullmodem cable across the serial/parallel port.
- Modem.
- Text to speech => tape recorder => voice recognition (like a modem, but more inefficient).
- Power down machine A, yank the hard drive with the file on it, re-install in drive B.
- Print bar codes & read back with a bar code reader.
- Hot-swap raid drives from A to B until the file is copied over. Keep replacing drives on A so that the system never goes down.
How's that? Do I get the job?
--
Ytrew
| [reply] |
|
|
> How's that? Do I get the job?
If I had a req, sure! :-)
(The sad thing is that we've used 5 of those in our production environment.)
| [reply] |
Re: On Interviewing and Interview Questions
by Bod (Parson) on Oct 23, 2021 at 23:29 UTC
|
I've started using some of these questions, especially the meta questions. They really do elicit some interesting and revealing answers.
At an interview this last week I got asked a difficult question by the candidate. I was reasonably sure that I wanted him in my team. After he asked that one question, I was certain that I wanted him on my team. One of our Four C's is Curiosity.
We had been discussing the range of languages on his CV. Then I gave him an overview of the technologies we use including that we use native Javascript instead of frameworks. He questioned why that was...
| [reply] |