Slashdot Mirror
Programming Job Skills Test?
eclecticgeek asks: "I've recently finished a CS/SD degree at uni and the interviews are starting to come thick and fast. I've yet to have a skills test for any of them, and it's only a matter of time before I do. I'm hoping to do one this week and I will get the choice of language. The position is quite broad and they're more after competent programmers in general, rather than any one specific language. So I'm wondering, have you done a developer skills test? What type of things did you get asked?"
For my current job, the test was over C++, Java, Perl, and PHP. Some of the concepts that were covered included Linked Lists, Queues, Stacks, arrays, and general CGI knowledge. I think a lot of test will focus on a mastery of the skills that a person "should" take from a college education in CS.
Not exactly a skills test, but on TechInterviews.com I collected a bunch of questions from recruiters and those who interviewed at tech companies. Since the site was up, there were a bunch of questions coming from people just sharing their job interview experience, but recently a lot of that is coming from India. I noticed that "fresher" type of questions used by some large-scale employers in India are pretty rudimentary, so I am not sure whether the applicant is expected to be a college graduate or just a high school diploma holder. So pick and choose, basically, should be a good way to refresh skills, if not self-test.
You can't prepare for the kind of BS that can get thrown at you in skills tests. I've seen things that you'd have to have the C++ Standard memorized to know, quirky product specific things they want you to know, and one place that set me down with a bug report and a development box with their code on it and wanted to see how I'd approach it...
I once got asked what was on page 71 of the "Camel Book." Most just wanted to see code samples, and asked more about how I would handle certain tasks. I guess they were more interested in how I thought about the algorithm or the problem at hand. The actual language came second.
My
I'm guessing How Would You Move Mt. Fuji would be the definitive book on the subject. It's been covered here before. That review is from 2003, so it's not a stretch to suspect that it's filtered out to all the HR llamas...
[o]_O
"So I'm wondering, have you done a developer skills test? What type of things did you get asked?""
Can you think?
Skills tests are as unique as the interviews that contain them. What interests me, however, is that you say you are getting tons of interviews. Are companies hiring, again? I gave up on the IT industry last year after seeing the rotten low-hanging fruit that was available. It seemed the only open jobs were the ones that no one wanted.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
Sometimes it is not the code that counts, but your approach. Are you applying for a software "design" position? If so, then show some evidence of designing something before you code. Consider the position you are targeting. Application software? Embedded firmware with restricted resources? Is pure speed important? Code size? Maintainability? Portability? Ask for a more detailed spec if what is given is too vague, or just put comments in your code showing where things should/could be changed if your interpretation of the spec is wrong.
If you are competent, you'll be OK. Every coding position I've ever had included a skills test, except one. The one exception was for a position at a company that I had already worked for in the past...
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
Jobs that have required "application" programming have typically set specific tasks. One I did wanted a search engine for web pages.
Yet others have involved very specific technologies. These are usually but not always in the form of a certification-style test. One that I did of this sort involved the real-time aspects of the ACE/TAO implementation of CORBA.
It depends a lot on the company as to what they are actually looking for. Bleeding-edge companies are likely to be more interested in novel solutions, for example, because it shows you can think and not just copy. ROTM companies, on the other hand, want things done fast and never mind the details. Any company that brags about ISO 9000 is likely a stickler for standards, whether the solution is any good or not.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I would be hesitant at C++ or Java. Perl, Python or Riby I would feel more comfortable in (given the concept in a skills test is assessment in a short space of time, a conceptually 'nice' RAD language (that can be programmed quickly as well as designed quickly) would win over stock languages).
However given a choice of language, and a desire to get the job done, did you consider APL or Brainfuck as a method of 1-upmanship?
I got this at my last job as part of my second interview, thankfully it was a take home "quiz".
"You are stranded on a deserted island, thousands of miles from nowhere you are forced to survive with what you have.
You have a handful of nails, a hatchet with a hammer head, 100 feet of rope, a large lens and a few dozen square yards of sail cloth.
The island has a variety of birdlife, fishing and crabs, but mostly inedible seeds, very acidic but edible berries and a large grove of coconut palms.
One side of the island seems to be geothermally active with several hot springs and some sulfer smelling vents, and a large variety of volcanic rock, obsidian and flint along with some hematite and copper deposits.
Now given this very restricted and scientifically unplausible situation, how would you survive?
Please take as much time as you need and give as thorough an answer as possible."
...in MIPS asm.
(You know, where you reverse the bits in a word, so 0x11101000 becomes 0x00010111)
If they give you a skills test, they'll often ask you about the most cryptic-looking functions that are necessary in programming like htonl(), strtoul(), atoi(), and the like. Also make sure you understand how (void *) works and how to pass pointers to functions. People love this crap. Unless they're more into software engineers than programmers. Then you better pull out your C++ books and remember how all of the variations on virtual methods work.
APL wins. APL2 would be best.
In a previous life I gave a lot of interviews to prospective hires. The company had a standard set of interview questions to work from. One of last ones was to have the candidate write a short program fragment to solve a given problem. One of the popular problems was to write a routine to reverse a linked list. So given "a->b->c" return the list as "c->b->a". It was explained that the nodes were singly linked. Very basic. It was amazing the answers I'd get back. I didn't care so much about the code but whether the person COULD solve it. And whether they could solve it without duplicating the nodes, etc...
For java a question that was asked was "What is the proper format for the program main method?" Lots of folks couldn't properly answer that one -- most said "The IDE fills it in." (yes, we can start a flame war about that - but let's not - I'm just giving examples of what this company asked).
One NON-Programming question you should be prepared to answer is "What do you know about our company?" It was expected that you'd visited the website and knew a few basic things -- what the company did was a good start. Nothing in depth -- mainly just seeing if the person had taken the time to look. This was one of the first questions in the interview. If you couldn't answer it that was pretty much the end of the interview. Harsh maybe, but it was considered that if you didn't take the time to know the basics about a company you were interviewing with, well, there wasn't much reason to continue on. You didn't have to memorize the entire site, but knowing the very basics of "What does company X do?" was required to continue with the interview process.
Invalid Checksum. Retrying.
I can't tell you how many times now I've interviewed some little fresh-out-of-school-all-eager-and-willing twat who has every language any one ever mentioned to him in school listed on his resume.
Don't lie about what you know.
If you cannot answer a simple question in a language you've listed on your resume then it shouldn't be there.
If you really think you need to bone up a lack luster resume with lists of useless abilities be smart about it. Make a grid and list the language and your current level of proficency. Then the interviewer isn't appalled when you're asked to answer a simple question in Perl but you can't remember how even declare a scalar in Perl because you only ever wrote one Perl script...
...five years ago...
...but really you just copied someone else's Perl CGI script and changed the HTML output to match your own amateur porn site's look and feel.
In general when I give written tests to try to judge a software engineers skill it is not language specific. I am not interested in seeing if people have memorized all of the constructors that are associated with a HashTable. Rather I am trying to find out where they are as a programmer and as a software engineer. To this end I ask for them to answer all question is pseudo code or their favorite language. I generally arrange the test to get sequentially harder - so it will be arranged something like:
1. Implement a fuction that takes in a string and returns that string with the characters in the opposite order.
2. Implement a function with the same functionality as question 1 but implement it with recursion.
3. Write me two functions, that are meant to run in a thread safe manner, where one function pushes strings on to a stack and the other retrieves data from the stack and prints out the string.
4. Please develop a high level UML-like design for a simple thread pool. Please be sure to include ways to retrive threads out of the pool, exprire threads out of the pool when they have been inactive for a certain period of time, grow as usage increases etc.
Those are the types of questions that I ask. Once they have answered all of the questions I generally sit down with them and grill them on their answers - to me this is the most important part as you get to see how they react to their answers being questioned, see how fast they can think on their feet and see how they pick up new ideas that are given to them and how they can apply that to the problems that are given.
Just my 2 cents.
Skills test are somewhat uncommon, but the majority of those tests are given to people without degrees. Your skill level comes through in the verbal interview. A company wants someone who not only knows what they are doing but can tell you what they can do.
"I would feel more comfortable in (given the concept in a skills test is assessment in a short space of time, a conceptually 'nice' RAD language (that can be programmed quickly as well as designed quickly) would win over stock languages)."
That would be Flowdesigner.
Failing that there's Lisp or Smalltalk.
The test was along test of:
and My answer to the second was:I'll go out on a limb and say that even if I didn't know Fortran, I certainly understood the concepts involved and could figure it out pretty quickly. Alas, I didn't get the job (in retrospect, thank God!). Too bad for them; two years later that ad is still running at least once a month.
Dewey, what part of this looks like authorities should be involved?
You are not expected to know everything or solve every problem. You are expected to prove that you have good enough skills that you could solve every problem given more resources (a net connection for instance).
For my last interview I listed C++, but was honest on the phone interview that I was rusty on it. There were several things on the test that I had no idea where in C++, because they were added between when I learned and when then language was standardized. (these also happen to be things that the compiler they gave me doesn't support correctly because it is old and obsolete) I got the job because I approached the problems correctly, trying a variety of things, Thinking out loud, and eventually got good answers. (In one case I solved a sequence that the interviewer said he had never seen anyone solve before)
Do not stick to just programing skills. Most of the test is likely to be logic puzzles that have little to do with programing.
I ususally ask the most important question first: where can I see your code on-line--which in practice often means: which free software project have you contributed to? It's better than a test because I can see some Real World(TM) problem solving skills, read the mailing lists archives to see interpersonal communication skills, ask other developers, etc. Why is it more important than tests? Because that way I can see how the future code is going to look. Academic questions and tests are good for students, but the Real World(TM) is very different. In the Real World(TM) understanding CPAN and APT is more important than understanding the Turing Machine, even if the latter is otherwise much more important than the former for any serious scientist. Today usually in every group of candidates there are at least few who have their code to show, so it's pointless to waste time on those who don't. Also, it seems important to award those who are productive and useful to the humanity at large, to punish and motivate those who aren't, and to tell the Big Boss(TM) "I told you, embracing the open source paradigm is profitable and good for the economy. Why not be more proactive from the hiring perspective and always demand appropriate portfolio up front?" This is just a common sense. For example, hiring a Debian developer you can expect that he will be able to package his software and install it properly on all of the systems instead of cluttering the filesystem with junk and making the servers expensive to migrate. Similarly, hiring a CPAN author you can expect that he will know how to use standard Perl modules instead of wasting his time and your money on reinventing the wheel and writing one big-arse slow-as-hell monolithic stand-alone CGI script when a nice hierarchy of mod_perl modules would work like a charm. I could go on and on forever, but I guess you get the point already. I never buy a cat in the bag. Neither should anyone else. This is not to say that free software and open source is "better" than its proprietary counterpart, but it surely is more visible.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
I do give a written exam to candidate developers where I work. Most of the questions on the test came about when a developer, who knew the right textbook answer, couldn't apply the concept to the required work. There is stuff like study this SQL script and tell me what it is doing or study this UML class diagram and answer the following questions.
Most of the places that I have interviewed at do not give a written exam. They ask questions during the interview. We do that here is well but I believe that a written exam gives a baseline from which you can compare candidates.
Most certification tests are incredibly innacurate and nearly useless because test making is itself an art. If you want to test how much you learned in college, then take the CS GRE.
Contains concealed links to obscene peverse gay porn (goat.cx) and necrophilia (bucket.cx).
Interviewer: Here finish this product for us and we'll see what we can do. --1 month later-- You: Ok here it is! Interviewer grabs CD with the code on it Interviewer: Oh well we hired someone else, thanks you. Next day you see the company release a headline talking about this revolutionary product you just made for them.
With nails, hatchet, rope and cloth you could probably build some sort of raft but whether that would be sea worthy is another matter.
Probably would be a mistake to eat the berries as they would probably rot your teeth and then you wouldn't be able to eat much of anything. Perhaps, there is some other chemical use for acidic berries?
You could probably build a crab trap with the rope.
You could probably start a fire with the flint.
You might be able to build a sea worthy vessel out of copper. You'd certainly have plenty of sand to form a mold.
Some companies here in NZ use a particularly smart test to find good programmers. After they've established the technologies you are fluent in, they will ask you to code something specific using a language that you've never used. You are given Internet access and a time limit. Since good programming is language-independent, and it is the use of good underlying concepts and technique that is more important, I think this test much better demonstrates a potential candidate's ability to adapt and solve problems without requiring them to demonstrate rote learning of tons of APIs. If you get a skill test along these lines, count your blessings and do your best to get a job with the company that set it. They understand what programming's about.
I was working a job doing Windows apps in C++ by day, but what I really wanted to do was develop games. I had done some small scale stuff on my own, and I wanted a chance to do it professionally.
So I heard through the grapevine that a small computer consulting company I knew was looking to develop a game, and they were looking for a programmer. I decided I would try moonlighting on the game while keeping my day job. I showed up after hours, and was met by the top three people that ran the place.
I was ushered into a small dark office. They sat in a rough semicircle around me. After a brief introduction, they started firing difficult logic problems at me. For about an hour and a half. No paper, no time to myself, I was expected to work out the answer out loud. It was intimidating as hell.
But I'm good at that type of stuff, and although I needed a little prodding on one of the problems I eventually came up with the right answers. They seemed satisfied. I explained what sort of compensation I would require, they agreed, and we decided I would come in after hours the next day to get started.
So the next day rolls around, and I show up. I get setup on a machine, but clearly the president of the company wants to talk to me about something.
So he comes out and says it. "Well, I've talked to my associates, and we've decided we don't want to pay you. We're a little cash poor right now. So what we want you to do is create a prototype, and we'll market it, and cut you in for a percentage of the profit."
I was floored. They wanted to make all the decisions, while I did all the up front work, for the possibility of some of the profit later on. They wanted me to be their bitch.
If they had told me this up front, I would have walked out the door right then, but instead I had to sit through the most stressful interview of my life, fighting for their approval. Blech.
# (/.);;
- : float -> float -> float =
Didya walk out?
Yes, but not just because of the public contribution. Let me rephrase it: I would always hire someone who I know is good over someone who I don't know whether he is good or not. And by "good" I mean both a good programmer and a good citizen.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
I've been on both sides of the table in too many interviews and honestly - the skills part is the most useless part of your interview. I have all but given up on that ever working.
Specific skills are way too easy to study for - you never know what you'll get no matter how well someone passes the test.
In my experience it has much more value if you try to get your answer indirectly... Like I was looking for a new sysadmin for my team. He has to answer questions of a ton of users that just walk up and at the same time get work done... So while doing something that takes long, he has to be able to either get interrupted and then go back to his work where he left off or he has to go tell people to hold on. Someone who gets interrupted and then doesn't know what he was doing will get lost. So while my college asked some questions that took a long time to explain I constantly interrupted (asking for more detail or other related short questions) and then watched the reaction of the candidate. One of the guys I interviewed got thrown off by it and wasn't able to ever go back to the question asked by my college - he would have failed in our environment...
Guess the point I'm trying to make is that you anyway never know what someone looks for - so don't bother studying or worrying what might happen. Relax, do your best and just try be yourself.
Peter.
HR guy told me I had to get 18 out of 20 right or I was done. Then he said I had about 3 minutes per question, and walked out. I finished it, checked my answers, changed about 5 answers...and scored an 18. Turns out the 5 I changed were indeed wrong and I'd changed them to correct answers. Phew!
Most annoying part was when I asked the HR guy why I'd gotten the two wrong. He said he had no idea, he only knew the correct multiple choice letters, not any logic behind them. So being a geek I opened the book back up, rethought the two I'd missed, and came to the correct solution for both of them. Of course at that point he didn't care, but damnit I did.
Compare that with the job where I currently am. I was asked a programming question, I wrote some code, the interviewing manager told me that it was a good "brute force" answer. Well that bugged the crap outta me, so I thought about it all the way home, thought of a better answer, and emailed it to him with a note saying "It may be too late for this to matter but my head will explode if I don't send it." During the next round of interviews I told one of the engineers that story and he laughed and said, "Well, I know two people that did that exact thing, and both of them work here now." make that 3.
www.HearMySoulSpeak.com
It is more and more important for programmers to be able to, when they reach a difficult problem, find out how it has already been solved. People who have worked in the online open source world would be much better at that, and at finding the right tools.
Yes, yes. You could build some sort of very primitive crystal radio using the hematite and copper. Additionally, you might be able to power a transmitter by using the berry acid as a battery. Of course, even if you were able to reach someone by short wave radio or whatever you might not be able to tell them where you are.
"sweet dreams are made of this..."
[posted anon for obvious reasons]
I recently did a programming test for a job at Bussiness Objects and it was a complete disaster. I did the test and walked out feeling confident that I had passed. Imagine then, my horror when they contacted me and informed me that I had failed it.
I was stunned. I had been so sure my solutions were correct. So I immediately sat down and wrote out all the questions and my solutions (there were only 4, so it was easy to remember them). I then tested these solutions, and they worked correctly. I then sat down with someone who had done the same test (and passed) and asked him to go over the solutions with me -- it turns out his solutions were almost identical to mine.
So why did I fail? Well, it turns out that they outsource the marking of the tests, and they get bored, disinterested university students marking the tests. You can guess what happened...
It was an aggravating, humilitating experience which has given me a deep distrust of such tests.
In this world nothing is certain but death, taxes and flawed car analogies.
I was asked to write an algorithm to play a strange version of Blackjack against a human where:
- Red cards are positive, black cards negative
- Aces are 1 or 11
- you only use half the deck each (play one-on-one)
- your score at the end of the round is 20 if your cards total less than 15, 20 minus (cards total) if total is 15-20, and 50 if it is over 20
- Winner is player with lowest score after a few rounds
The trick is in the statistics: the black and red card values cancel out on average, leaving only the aces (1 or 11) as the average source of points.
This was after three hours of written exams, logic tests and IQ tests, so my brain was mush already and I failed majorly.
A few suggestions for how to answer a problem solving- or coding-type interview question:
- Talk as you work through the probem. The interviewer is trying to determine how you go about tackling a difficult problem and the more you communicate, the easier this is and the better it reflects on you. You're going to have to be able to discuss what you're doing with coworkers and this is one good way to show the intervewer that you have those skills.
- Ask lots of questions. Make sure you fully understand the constraints on the problem and what they want. Do this before you start designing and coding. Again, you'll likely get ill-defined problems once you start working and you should show the interviewer that you can ferret out the true work from a poor specification.
- Don't be afraid to make mistakes. Most people don't get the right answer the first time and have to iterate through the problem to figure it out. It's never bad to sketch out a quick brute-force solution first-thing as it usually helps to have a working base from which to derive your eventual solution. It is important, however, that you can explain the strengths and weaknesses of any solution you come up with, especially the time it will take to run. It's also important to keep refining your solution to an even better answer.
- Use appropriate languages and techniques for the question being asked. If you're asked a low-level programming or data structures question then don't start spewing out a bunch of STL-based C++ code; chances are the interviewer is interested in knowing that you actually know how a linked list works "under the covers". Of course, if they're probing your knowledge of STL then an STL-based answer would be appropriate. Ask the interviewer if you have any doubt.
- Always check your work. Walk though your algorithm with some sample input to make sure that you have everything correct. Check every edge case. Make sure that you're verifying that the inputs are correct. This is where you show the interviewer that you have good attention to detail.
- Never give up. Never admit that you're stumped. Simplify the problem if need be, come up with a design then add any complexities back in. If they ask something you don't know then admit it and ask questions to try to figure it out. Deriving the answer from clues is often more impressive than simply knowing the answer up-front.
Your goal for the interview is to show the interviewer that you have the abilities they're likely to need. Such skill tests can be vital in selling yourself to them; figure out what they're likely to want and use the test to show them what you can do.
This really ticks me off to no end. I had a recruiter CALL ME last week. He seen my resume online. He asked for me to send him a copy of the resume in MS Word format. OK. No problem - even though the resume is posted on the job site where you have the option to download it in word format. Anyway, he calls back and wants me to come down for an interview (2 hour drive) and quickly (at the end of the conversation) added "and a few tests."
I get annoyed when asked that to begin with but especially when they're the one that is contacting me! I include a complete skillset with my resume and it leaves no doubt whatsoever as to my abilities. So, it's very insulting when they ask this of me - it's as if they don't believe me - that I've done nothing for the past six years while employed as a system administrator / programmer.
Just my 2 cents...
What is the value of i now? (Hint: it's not 1)
It seems Java behaves differently from other languages in this respect.
In this world nothing is certain but death, taxes and flawed car analogies.
They would probably attract my attention, especially if they were females! But, seriously... Someone helping a charity is certainly a very good citizen, and might be a great programmer, but I have no way to be sure if I cannot see a finished project. Someone active in on-line forums would certainly be a great help to less experienced programmers, but I wouldn't hire those in the first place. The problem with not contributing to open source projects is that it looks very suspicious to me. When someone tells me "this is impossible to do because of a bug in the operating system [or a compiler, library, interpreter, etc.]" I say "So?" because if someone cannot fix a simple bug in open source software than we might use proprietary crap just as well. It is just a common sense to hire someone who has already done it, to avoid possible problems in the future. You are right that a proprietary programmer may be just as good or much better than a free software hacker, but the point is that not being able to see his code, I can never know it. On the other hand, it is quite common to not hire someone when he shows you some crappy mp3 player on sourceforge, or you find some stupid questions on the mailing lists (Google groups is priceless for that sort of investigation--here's an advice: always use a pseudonym to ask questions). The answer to the question "is one a good programmer?" has only one difference between proprietary and free software developers: most of the programmers in both groups are incompetent, but it is easy and fast to determine in the case of free software, and nearly impossible otherwise. The difference is in the level of transparency. The second thing is the experience using open source tools and systems, and the ability to fix them when needed. This is the difference between Microsoft mentality where even the best programmers can only beg Microsoft to fix a bug in their compiler and meanwhile work around it until they maybe fix it ten years later, and the open source community where anyone can send a patch to GCC and have it fixed in the next release, and meanwhile happily use the locally patched version until the patch is present in the main branch after few days. Another thing is the issue with NDAs. It is foolish to hire anyone who has signed any kind of NDA which will interfere with your projects, and it is even more foolish to sign such NDA in the first place. Likewise, it may be unwise to hire someone who has accepted any EULA containing NDA and anticompetition clauses. You don't have said problems when working with GPL, do you?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
The first order of business would be to bring the local population around to accepting the new order of things. This would mostly involve chasing the birds, fishs and crabs around with the hatchet while screaming obscenties at them - I expect the berries and coconuts will acquiesce to my dominion, as they are known to be sanguine in nature.
Once the locals have been frightened into disorder, the next order of business would be setting up a hierarchy of power. The most loyal and strongest of the flora and fauna would be granted titles, such as Marquis, Earl or Chuck. Those that show signs of causing trouble must be controlled, so a prison will be built near the sulfur by hammering four nails into the ground and tying the rope around them to form guard walls. Burly Sgt. Coconuts will be placed at each corner, and a sadistic Chuck Berry in charge. Prisoners will be forced to work in my sulfur mines.
By this point, I shall be undisputed Lord of the Island. So to celebrate that fact, I shall begin construction of a 100m tall effigy of myself in copper and obsidian (for the sake of morale and artistic freedom, certain physical attributes may be emphasized or diminished, as necessary). The sail will serve as a cover to prevent the work from being seen before it is finished.
Of course, during construction, I will begin to create my armed forces. Mostly this will involve drilling the birds (air force), fish (navy) and crabs (marines) until I am satisfied that they show military spit and polish.
After years of rule, I imagine some passing ship will notice a 100m tall copper statue on a supposedly deserted island. By this time my rule will be assured. I will not leave the island, instead declaring my domain a sovereign nation and offering to host affluent guests from around the world - for a fee. I will also create a website, offering the services of the elite of my armed forces as mercenaries for hire, again for a fee. Eventually, I will pass on the throne, and retire to the mainland to live large off of the book deals, and movie revenue.
His Imperial Majesty,
King Indi I of Indiland
It's hard to soar like an eagle when you're surrounded by turkeys.
Ack, that's easy.
void swap(int a, int b) {
a ^= b;
b ^= a;
a ^= b;
}
Of course, that'll discard a and b afterwards. You might want to print them out, or declare int * a, int * b.
void swap (int &a,int & b)
{
a ^= b ^= a ^= b;
}
Yeah, it's the same thing, but you know CS majors... we have to compete to get the shortest, most obscure code.
I mod down pyramid schemes in sigs.
I used to interview for a small company. We were interested in people's technical abilities sure, but also very much in how well they could work in a team.
We used to set a design test which would take about half of the interview. Books and internet access were allowed - this wasn't a memory test. The next half of the interview was all about what would happen if the requirements suddenly changed. We'd work together and explore how we might change the design in different situations.
The worst candidate I ever interviewed could not seem to get it through his head that the whole point of the second half was to work with me on changing the design. He just kept saying "But you didn't tell me that right at the start - that's not how I designed the system" and I kept saying "I know - the whole point of this is to see how you deal with changing requirements working in a team.".
He didn't get the job...
First - survival, but you might have one volatile asset to help with your rescue. Do you have a watch, and is it still running and on time? Do you know the date? If so, the sooner you take a reading of the angle of the sun & combine it with the time, the more accurately your position can be determined. Otherwise, start tracking the arc of a shadow & wait for the solstice, & take a readings then. Include these readings on the messages you toss into the sea. (Pumice, coconut husks?)
Make shoes - you won't live long if your feet give out. Any injury could kill you by way of infection. Make clothes from the cloth, and conserve it. It will deteriorate in the sun, but better it than your skin. If you can clothe yourself with feathers or anything else, you want to do that instead. Depending on how long you are on the island, you may need to make a sail from the cloth. It is also a source of fine thread. You might use it to skin a boat.
Make a prominent distress sign, visible from the air.
You can distill water from the hydrothermal vents, or at least use the heat to distill seawater.
Can you make a compass from the hematite or nails? If the hematite is specular hematite, it may be possible to polish it into a signalling mirror. Try the copper too.
With the copper & nails as a battery (voltaic pile) you could make a spark gap generator to produce radio noise. It's a little Gilligan's Island, but you could probably rig a machine (powered by wind, or gravity by way of ported water or sand) to use this to constantly transmit SOS. Depending on your ability to work the copper, you may be able to make enough wire to make a simple radio receiver & speaker. You may need to use your battery to magnetize pieces of nails.
If the wind is constant enough, you might make a kite to hoist an antenna.
Can the seeds be made edible after making into flour and treating with ashes or the acid from the berries? Acorns aren't edible either, but lot's of people have survived on them. Vary your diet to avoid scurvy, ricketts or worse.
How large is the lens? If it's a page sized fresnel lens, then you can melt concrete with those, so smelting small quantities of iron is not entirely implausible. A blind spot in the center of your vision won't improve your survival odds, so don't look at the hot spot. Hang the lens on a frame.
Prepare a signal fire, & keep coals ready to light it. Don't burn down your coconut trees.
Can the berries be fermented? Not just for entertainment, but alcohol can clean wounds, and could be useful for fuel.
Nothing gets thrown away or tossed into the sea. Make a latrine in a place that won't cause any trouble. Even your waste is a resource. Look out for birdlime. You might just be able to make a black powder flare for signalling from that, the sulfur & some charcoal. Burn as little as you must, as you don't have time to wait for fuel to grow. Besides, you've got free heat from the hydrothermal vents.
As others have said: Obsidian & flint: Knives, spear points. Coppper -fishhooks. You could probably work the nails too. Lots of other excellent suggestions here. With the copper & hematite, you should be able to make a diode, and from that a radio receiver. Good luck making a speaker or earphone. Homemade wire, nail fixed magnet, diaphragm of palm or cloth. Handy, but probably impossible: Triode amplifier.
Finally, use wax from the berries & feathers from the birds, & make wings. Fly away, but don't get too close to the sun, or the wax will melt and you'll fall into the sea, to the dismay of your father.
A related problem is how does one make accurate tools or measuring devices without already having them? One way to start is by making a flat surface by rubbing two things together.
Assembly is the reverse of disassembly.
I've seen them running the gamut, from an IBM programmer's logic test that they gave to everyone, to grueling questions concerning language nits. I think language nits don't accurately gauge on the job performance, as they are 1) The sort of issue you don't deal with. 2) Gotchas that reasonable programming style will avoid. A shop where I was working used to ask simple programming questions, the kind of thing that could be done in twenty lines or less. That seemed pretty reasonable as a lot of the questions were basic programming tasks. It's done interactively, one-on-one as much to see how you think as how well you program. One place I interviewed at, the test was heavily based around the string pasting functionality in the C Preprocessor. Having gotten a heads up on that, with five minutes of preparation it was easy. But without prior warning, given that it wasn't a Preprocessor feature I was using, I would have failed miserably. I've run into Brain Bench on my current job search. They have a large question pool, with the question difficulty supposedly advancing to challenge the test taker. It seemed like a lot of nits to me, some of which I knew, some of which I didn't. A lot of stuff on the Standard Library, which I'm somewhat familiar with, but as I've worked a lot in Windows, I'm more familiar with MFC. They encourage you to use sources, but with only three minutes per question you can only check so much in Stroustrup! Side rant: I've got headhunters asking if I have BrainBench certifications. Given the cost and the fact that the certifications only last a year, why would I do that? I could probably spend over $500 a year staying certified in what I consider are my core skills!
The book Programming Interviews Exposed has a lot of info on some of the skills you might be asked to prove as part of an interview. I highly recommend this book to anybody who expects to be interviewing for a development job.
Even if you don't get asked the specific questions they speak of in the book, the concepts will be of value to you.
// TODO: Insert Cool Sig
This is just the sort of thing I would want job applicants to do, if anyone were foolish enough to trust me to hire people.
http://www.itasoftware.com/careers/eng/job1.php
I've interviewed at places that did have programming skills tests, and those that did not. When I've been in the hiring role, I've occasionally used them. Some people believe they are a good impartial way to evaluate skills. Others believe you can gain the same info by talking to a person informally.
The big thing to remember is that the test should be "shades of grey" rather than "black or white". If you're not sure about an answer, but you can explain why you made that choice, it's better than leaving them with a yes/no answer.
I've seen good tests, with language specific questions (without being syntax nits) like 'What interfaces or classes would you need to extend to implement a J2EE EJB service?' and general questions like 'Describe 2 Gang of Four patterns and where you'd use them?' (Note, you get more points if you admit you don't know which patterns are in GOF than if you guess incorrectly).
I've seen bad tests, like when I was asked to implement a linked list in C. My response of "I wouldn't, I'd use STL", was badly received. Eventually, I got from them that they wanted to see that I could identify boundary conditions and likely places to mess up the pointer manipulations.
The worst are the downright ugly tests. At my previous job, HR asked some engineers why none of the candidates were passing the multiple choice programming exam they were given. It turns out that a third of the "answers" on the key were wrong, and another third were ambiguous because of the wording of the question (ie, both A and C could be argued to be correct).
To sum things up, expect questions related to the skills required for the job, questions related to the skills you've listed on your resume, and questions about general theory and good practices. Often you can get partial credit for a wrong answer if you explain yourself. Always be honest rather than improvising an answer that you don't know. And you can always ask to discuss any questions you get incorrect, so you can explain your thought processes.
When I interview, it depends on the resume and the skillset I need. I tend to cover standard logic problems in psuedocode just to see if they can think. I also cover some light real world applications based off the languages the person claims, but not too many esoteric questions. Well, unless someone says that they know everything about a subject. That is when I find out how long before they go insane over windows api calls and what they do. (We are a systems and programing dept that supports mostly windows clients in a large corporation)
In God we trust, all others require data.
I'm sure that if you ingest a lot of copper then you could get ill but if you cook with a clean copper pan and avoid acidic foods I'm sure you'll be ok.
"sweet dreams are made of this..."
...about a programming project you worked on with me and a couple of other senior programmers.
Do this for 15 minutes or so and people ought to be able to figure out if you are the person they need.
"Provided by the management for your protection."
That's very true. My current employer's interview process was pretty good. The first was a technical interview, wherein I was asked some relevant mathematical questions and to write a fairly straightforward function to do some floating point work without kindergarten errors. Up to this point, I was impressed both with the interviewers' (now my boss and boss's boss) comments and with how they conducted the interview itself.
Then they asked me what I thought of an example function, producing some sample code the function identifier XXXX'd out. My immediate reaction -- and I said this out loud -- was "Well, whoever wrote it should be shot." The formatting was terrible, the variable names were unhelpful, and there were no comments, for a start. There were more egregious things, too, notably the dreaded misused operator overloads. Fortunately, they thought I was just joking about the function name; it turned out to be real code from the project I was going to work on!
After seeing the kind of code they wrote, I nearly walked away before the second interiew. The coding standards are still the worst part of the job, but most of the more heinous crimes have been stomped on by the sheer force of my team's will, and fortunately the remaining aspects of the job are enough to make up for it. But I nearly never knew.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
About 2 years ago, I had an interview with a call-in center that wanted help maintaining a VB application: they had a bug they wanted me to fix, so I did some research, found a tidbit online that looked like someone else asking how to fix the exact same problem, cobbled a solution between their notes & mine, and submitted the fix. Never heard from them again until I called a month later stating they "hired someone already."
Life is irony, and nothing ever goes as planned.
void swap (int &a,int & b){
a^=b; b^=a; a^=b;
}
#include <iostream>
using namespace std;
void swap (int &a, int& b) {
a^=b; b^=a; a^=b;
}
int main(){
int i = 7;
swap(i,i);
cout << "i: " << i << endl;
}
---Output---
i: 0
are you willing to relocate?