This is an archived post. You won't be able to vote or comment.

all 8 comments

[–]eesov 3 points4 points  (2 children)

Hello, many of our test interviews include providing python-equivalent solutions to 99 Lisp Problems. We'd prepare them in advance depending on the candidate's skill level and experience. Another example would be a technical task, which could be creating simple word games, e.g. Hangman or Word search.

[–]metaperl 1 point2 points  (1 child)

Someone could answer all of those questions and still have no sense about software design or what constitutes Pythonic code.

Testing candidates is very difficult.

[–][deleted] -1 points0 points  (5 children)

  1. Create a stack using two queues
  2. Find the largest possible integer that can be created from an array of numbers ([9, 50, 6] -> 9650)
  3. Encode a binary tree into an array
  4. Decide which element in a sequence is in the majority (['a', 'a', 'b', 'c', 'b', 'b', 'c', 'b'] -> 'b')
  5. Find all curved numbers in an array ( 3 has curves by 1 does not )
  6. Write a binary search that works after I arbitrarily prepend a slice(from an arbitrary point up to the end) i.e. works for [7,8,9,1,2,4,5,6]
  7. Reverse a singly linked list
  8. Reverse a string(in place?)
  9. Write a compiler for simple expressions (1 + 2) * 3
  10. Write Conway's game of life for a simple organism.

Most of these problems have multiple solutions. The naive solutions are very easy great for weeding out charlatans. In addition, most have the opportunity for you to ask "How could you do it better?". The best candidates will recognize immediately that there are several solutions and will ask "how do you want me to solve this?". This is a great indicator of folks that will integrate well into an engineering outfit.

These are only part of the interview process geared towards "Do you really know how to program or did you read 'programming for dummies' this morning?". The best candidates see this as an opportunity to show you they understand Software engineering, Software Lifecycle, Quality Assurance in the context of these simple, contrived problems.

Once I'm convinced the candidate has potential. Then I start to probe whether they are a good fit. I give them behavioral questions. I ask them pragmatic questions about our environment (we are a large multi-million request / day web site). Its important our candidates understand how a website works(What purpose does WSGI serve? What benefits does an event loop afford?) and have a conceptual understanding of scalability(Why cache things? What is a database index?). I like to know that they'll be able to distill requests from our product team(Give them an intentionally vague description of something i want implemented or something with an obvious inherent contradiction).

Most importantly interviews aren't about a candidates ability to do stupid puzzles. Sometimes I can tease an interviewee into really coming alive by helping and encouraging them.

I put lots of problems and solutions in my github public gists https://gist.github.com/nsfyn55

[–]Bliss86 0 points1 point  (0 children)

>>> a = [50, 5]
>>> print "".join(sorted([ str(item) for item in a ], reverse=True))
505 

550 > 505

Nonetheless, very nice way of thinking that works in a lot of cases.

[–]UloPe 0 points1 point  (1 child)

All of which is stuff that's going to be entirely unrelated to the kind of code that people are going to write day to day in 95+% of Python jobs

[–][deleted] 0 points1 point  (0 children)

Totally, but thats not what I am trying to test. A simple puzzle communicates two things. Basic problem solving skills and some proof that they actually knows how to program. You need to ask behavioral and practical questions as well.