questions for programmers interview

category: code [glöplog]

I think that social skill is a misunderstood and badly used term. As long as he gets along with the team.

added on the 2012-06-29 17:47:38 by Lord Graga

if only solving such test was all that is needed to get hired.gave it a try. am i hired?

added on the 2012-06-29 17:48:32 by vectory

Quote:

I think that social skill is a misunderstood and badly used term. As long as he gets along with the team.

I agree. Social skill is a vague term. Perhaps we should talk about communication skills and the ability to work in a team (cooperation skills).

added on the 2012-06-29 17:54:48 by ham

vectory:
Assuming that you didn't use IDE or internet you have done very well.
Couple of points:
- Question 1: You have been asked for binary not octal.
- Question 2:

Why not use standard for loop?
Numbers gets "\n" and fizz/buzz don't
mixed use of "put" and "printf", I understand the logic behind it. but personally, I would would not mix.

- Question 3: Very good! Have you used regex before?
- Question 4: Overall code commenting is great, so does understanding. I don't know if you use the 2nd version of the test that include a question about a potential bug in the code.
- Question 5: This is where my red light would go on. This is by far the most complicated implementation I ever saw for the question.

My conclusion (has if this was a real test) is:
Pro: The person is very experience - no doubt!
Con: Both question 1 and question 5 shows a tendency to over-do things and make things over complicated. Because of that I would invite you to an interview, along the way would give you couple if really simple problems to make sure you go the simple way.

Anyway, as I said, excellent test! I wish I had more like this.

added on the 2012-06-29 18:41:05 by TLM

Quote:

- Question 5: This is where my red light would go on. This is by far the most complicated implementation I ever saw for the question.

You didn't specify if you want a fast version, a version that detects integer overflows, whatever... The use of a second function could have been avoided, but apart from that, it looks like a nice "safe" version with integer overflow check (which will probably not work in all cases, but still). If you remove that check you have a pretty simple version.

added on the 2012-06-29 19:06:21 by Saga Musix

1: i am a bit fuzzy, you see
2: the for-loop is different in every language, maybe thats why i just try to avoid it. though, i heard it would achieve better optimisation in c. is that true? else i dont see the benefit.
fizz/buzz gets \n, too, with pith puts.
3: indeed, i have. still i made a mistake, did you notice? i didn't acknowledge, that [eE][-+]?\d is optional >_<
4: thank you. i used the first version, hadn't seen the 2nd by then. i was a bit confused which language im looking at, maybe thats worth noting, or not, if you want to see what testees make of it.
5: but, but it handles overflow (just for reading las' comment). thoug, technically it's a carry.

i can confirm the tendency to overdo things, only cause i don't see the simpler solutions. that makes me slow, too T_T.

talking about social skills, testing your coworker and then giving the job to some one else, might that turn your coworkers favout against the applicant that gets "his" job? i mean, if he really wanted it and all that?

added on the 2012-06-29 19:15:28 by vectory

vectory:
I didn't know that puts appends \n -- cool.

Regarding the workers being tested, two things: First, I can assure you that they are not interested in the position. Second, they both toke the test knowing it is just for reference.

Saga Musix:
It's probably a personal taste thing, but I don't like assignments inside if statements (or any other statements). I would rather see something like:

Code:

unsigned int faculty(unsigned int n)
{
    // subItems = (n-1)*(n-2)*(n...
    unsigned int subItems = n ? faculty(n-1) : 1;

    // Compute result and check for overflow
    unsigned int result = n * subItems;
    if (result < subItems)
    {
        printf("Overflow!");
        return 0;
    }

    return result;
}

Actually, I would like the KISS version:

Code:

unsigned int faculty(unsigned int n)
{
    return n * (n ? faculty(n-1) : 1);
}

added on the 2012-06-29 20:38:15 by TLM

Quote:

It's probably a personal taste thing, but I don't like assignments inside if statements (or any other statements).

Well, personal taste doesn't really say anything about the objective quality of a piece of code. If you want to have code that looks good in your eyes, you should probably show your company's code style guidelines to the test takers first, so they can get familiar with what looks good to you and what not. ;)

added on the 2012-06-29 21:25:16 by Saga Musix

But yes, the KISS version is arguable the nicest (recursive) version, if you don't need to know about overflows / carrys.

added on the 2012-06-29 21:26:17 by Saga Musix

just for fun, my fizzbuzz:

Code:


for(int i=1;i<=100;i++){
    int b=0;
    if(!(i%3)){printf("Fizz");b=1;}
    if(!(i%5)){printf("Buzz");b=1;}
    if(!b)printf("%i"i);
    printf("\n");
}

but it could be more interesting if you'd do it with square numbers, say, 4 and 2. That way you can find those who know modulo and those who know bit masks.

and again, for fun, here without modulo, cuz modulo can be slow:

Code:


for(int i=0;i<=100;i++)
{
    static int i3=3;i5=5;
    i3--;i5--;
    if(i3|i5)printf("%i",i);
    if(!i3){i3=3;print("Fizz");
    if(!i5){i5=5;print("Buzz");
    printf("\n");
}

Also, I've never done hiring, but what's described here seems pretty relevant.

added on the 2012-06-29 21:29:50 by BarZoule

Lovely thread!

At the firm I work at (a software consultancy, focusing on embedded software), we concentrate on three points when hiring:
- Attitude
- Personal skill / 'soft skill'
- Technical skill

We value them in that order, because attitude is nearly impossible to change through training. Also, if someone is smart and able to learn fast (which, for us, falls under 'personal skill' - the willingness to learn new things is attitude) but doesn't know, say, the difference between a class and an interface, we might hire anyway, because someone with the right attitude and good personal skills can pick up the technical stuff fast enough.

We never hire for a specific position, so people have to be generalists at least to some extent. This makes the whole attitude thing even more important - if you know you need a COBOL expert for the next 10 years, you might live with a stubborn jerk if it's the only one you can find. We never know that we can fill a particular spot for any longer than a few months, so we can never hire such people.

The disadvantage of this approach is that sometimes enthousiastic and passionate engineers slip through who, despite appearances, would fix null pointer bugs by wrapping said code in "if(var == null) { .. }" clauses, instead of understanding the reason for the var being null. And similar atrocities. Team members don't always catch this in time, and often feel that it's not big enough a problem to discuss the engineer's functioning. But deep inside, it's an attitude problem. I'd love to find a way to test for this part of attitude doing an interview process (not just 'how do you fix bugs' - i have the feeling there's a more general thing at work here, but i can't put my finger on it. something with thoroughness, maybe).

added on the 2012-06-29 22:55:18 by skrebbel

skrebbel: don't you have something like a 3-month trial period? We do in Norway.

added on the 2012-06-29 23:51:12 by gloom

skrebbel: WOW, What a great insight!

Our company structure is very similar, and apparently so does the things we're looking for in our the people we wish to hire. I just think you manage to put in words what I had in mind the entire time.

I totally agree with you that "attitude" (as you describe it) is top priority, and when thinking of it, it also the hardest to test.
Actually, I think that the higher you go (technical>personal>attitude) the harder it gets to test for.

I think that the test I have put together does an OK job for testing for personal skills. But I totally agree that we should find a way to map attitude.
To my opinion, even an interview isn't a great tool for mapping attitude.

In your description of attitude you mention "willingness", personally, I think this is a better name for it. I can think of few sub-types of willingness.
For instance, one could be "Technical willingness" such as:
- The willingness to observe bugs as you go (in your own code or others)
- The willingness to provide a deep/true solution to issues, bugs and requirements
- The willingness to question high level design and invoke meta thinking
- The willingness to understand code (and refactor/cleanup along the way)

Than there could be something like "Social willingness" that can be:
- The willingness to accept new ideas from co-workers/boss
- The willingness to work in a team
- The willingness to share ideas & codes

And than there could be "Personal willingness" that can be:
- The willingness to improve
- The willingness to learn new things / technology
- The willingness to build a career / become a pro.

If I had to sort by importance I would do the following:
- Technical willingness
- Personal willingness
- Personal skill / 'soft skill'
- Social willingness
- Technical skill

This is getting interesting!

added on the 2012-06-30 00:01:36 by TLM

gloom, good point - yes, we have a 2 month trial period. It is seldomly used, luckily. We do also sometimes offer someone a 6 month contract instead of an indefinite one, if we're not entirely sure aboud something. I know of one case where someone's 6 month contract did not get prolonged, because of attitude problems (basically, a genius coder and a real nice guy, but 100% dogmatic about coding practices, so impossible to work with).

TLM: Hmm, nice take. I do find, however, that a big part of 'attitude' can be discovered well in a set of interviews. It works best if the interview is more like a cozy talk, and less like a police questioning. For this reason, we split the interview in three parts, with different people. Only one part contains technical questions, and even that one uses only have the time for it. People tend to get most nervous (and thus least like themselves) during the technical questioning, so by taking that apart from the rest, they open up a bit more on average, or so we hope.

For example, we'd never send people a form with tech questions like the one you've made - it might give some people the police questioning feeling even before they've entered the building.

added on the 2012-06-30 09:45:36 by skrebbel

s/have/half

added on the 2012-06-30 10:01:26 by skrebbel

My fizzbuzz:
void FizzBuzz()
{
for ( int i = 1 ; i < 100 ; )
{
printf("%d\n", i++);
printf("%d\n", i++);
puts("Fizz"); i++;
printf("%d\n", i++);
puts("Buzz"); i++;
puts("Fizz"); i++;
printf("%d\n", i++);
printf("%d\n", i++);
puts("Fizz"); i++;
puts("Buzz"); i++;
if ( i > 100 ) return;
printf("%d\n", i++);
puts("Fizz"); i++;
printf("%d\n", i++);
printf("%d\n", i++);
puts("FizzBuzz"); i++;
}
}

added on the 2012-06-30 11:46:58 by MsK`

MsK: hired!!!

added on the 2012-06-30 13:45:10 by TLM

Application denied. Way too few Factory and Singleton patterns.

added on the 2012-06-30 14:06:11 by kb_

MsK: That's too unDRY... :)

added on the 2012-06-30 15:18:22 by xTr1m

nice unrolling the loop, MsK`

added on the 2012-06-30 15:29:39 by vectory

obviously,

Code:


#include <stdio.h>

int main(void)
{
   puts(
     " 1  2 Fizz  4 Buzz Fizz  7  8 Fizz Buzz 11 Fizz 13 14 BuzzFizz "
     "16 17 Fizz 19 Buzz Fizz 22 23 Fizz Buzz 26 Fizz 28 29 BuzzFizz "
     "31 32 Fizz 34 Buzz Fizz 37 38 Fizz Buzz 41 Fizz 43 44 BuzzFizz "
     "46 47 Fizz 49 Buzz Fizz 52 53 Fizz Buzz 56 Fizz 58 59 BuzzFizz "
     "61 62 Fizz 64 Buzz Fizz 67 68 Fizz Buzz 71 Fizz 73 74 BuzzFizz "
     "76 77 Fizz 79 Buzz Fizz 82 83 Fizz Buzz 86 Fizz 88 89 BuzzFizz "
     "91 92 Fizz 94 Buzz Fizz 97 98 Fizz Buzz"
   );
   return 0;
}

added on the 2012-06-30 20:54:55 by rrrola

added on the 2012-06-30 22:30:09 by orby

rrrola: hired as well!

added on the 2012-06-30 22:38:16 by TLM

Ever played the drinking game of this? You go around in a circle, and change direction on Fizz, skip a person on Buzz, and then I can't remember what you do on FizzBuzz (maybe just a combination of the two). Whoever fucks up has to drink (this can be by saying the wrong number/Fizz/Buzz, or by saying something when it's actually not your turn). Usually people don't get higher than like 20-30 iterations before someone fucks up, and usually a lot less.

added on the 2012-06-30 23:38:17 by Lord Graga

Code:


    public interface INumberGenerator
    {
        string GetNumberForIndex(int index);
    }
    
    public class SimpleNumberGenerator : INumberGenerator
    {
        public string GetNumberForIndex(int index)
        {
            return index.ToString();
        }
    }

    public class DivisibleByNumberGeneratorDecorator : INumberGenerator
    {
        private readonly INumberGenerator parent;
        private readonly int divisibleBy;
        private readonly string substitute;

        public DivisibleByNumberGeneratorDecorator(int divisibleBy, string substitute, INumberGenerator parent)
        {
            this.parent = parent;
            this.divisibleBy = divisibleBy;
            this.substitute = substitute;
        }

        public string GetNumberForIndex(int index)
        {
            if (index % divisibleBy == 0)
            {
                return substitute;
            }
            else
            {
                return parent.GetNumberForIndex(index);
            }
        }
    }


    class Program
    {
        static void Main(string[] args)
        {
            var generator = new DivisibleByNumberGeneratorDecorator(
                15,
                "FizzBuzz",
                new DivisibleByNumberGeneratorDecorator(
                    3,
                    "Fizz",
                    new DivisibleByNumberGeneratorDecorator(
                        5,
                        "Buzz",
                        new SimpleNumberGenerator())));
            Print(generator, 1, 100);
        }

        private static void Print(INumberGenerator generator, int startIndex, int count)
        {
            Enumerable.Range(startIndex, count)
                .Select(i => generator.GetNumberForIndex(i))
                .ToList()
                .ForEach(Console.WriteLine);
        }
    }

added on the 2012-07-01 10:53:48 by skrebbel

pouët.net

questions for programmers interview

login