Thoughtsworks Job Interview?

[MarathonMan]

Hi,

Any one interviewed with Thoughtworks for a Java position? Whats been
your experience? And how tough are their coding tests during interview
process. Im thinking about applying to Thoughtworks.

Thanks,
--Anil

 

[Nus]

How was the interview with Thoughtworks?

 

[Anzime]

How was the interview with Thoughtworks?

If you have to worry about "coding tests" you need to code.

 

[Virgil Green]

If you have to worry about "coding tests" you need to code.

The "coding tests" question intrigues me. Since I haven't interviewed for a
job in over 15 years, I'm curious to know what kind of coding test typically
would be used for a Java position. Are the interviewers interested in your
ability to write good code in a timely fashion using the tools of your
choice (or similar), or are they interested in whether you've memorized
every class and every method signature in the standard libraries and can
crank out code in Notepad?

What kinds of experiences have readers encountered?

- Virgil

 

[Eric Sosman]

The "coding tests" question intrigues me. Since I haven't interviewed for a
job in over 15 years, I'm curious to know what kind of coding test typically
would be used for a Java position. Are the interviewers interested in your
ability to write good code in a timely fashion using the tools of your
choice (or similar), or are they interested in whether you've memorized
every class and every method signature in the standard libraries and can
crank out code in Notepad?

What kinds of experiences have readers encountered?

I can't recall ever taking or administering a coding
test as such. I've been asked for samples of code I'd
already written, I've been asked coding-related questions
like "What's a coroutine?", and once very long ago I was
given a "programming aptitude test." But I've never been
asked to sit down and code something, nor have I asked any
interviewee to do so when I was hiring.

The problem is time. Anything that can be coded from
scratch in ten or fifteen minutes is going to be pretty
simple, certainly far short of the degree of difficulty
attached to the prospective job. Discovering that somebody
knows how to code a Heapsort or doesn't know how to code a
Gaussian elimination doesn't really tell you all that much.
Yes, you'll weed out the outright liars who claim to be
experts and truly know nothing at all, but I hope you have
more efficient ways of accomplishing that task -- the poseurs
ought never even to get an interview.

But fashions change, and I haven't been on either end of
the hiring process for some years; maybe tests are now in
vogue, despite their shortcomings. Personally, I used to
prefer asking the interviewee what projects he'd worked on
and then drilling down on a few of them: "That sounds disk-
intensive; were there performance problems? How did you
attack them? What gains did you get? In retrospect, could
they have been avoided with a different architecture? How
did the problems you struggled with on Project X influence
your design and coding decisions on the subsequent Project Y?"
I felt this gave me a better idea of the person's potential
to be helpful than would any number of prime finders.

 

[Gary Labowitz]

We used coding tests ("Programmer Aptitude Test") at IBM many years ago. It
was actually pretty simple and tested logical thinking. However, it ran into
legal problems. A test used to select or reject candidates must be shown to
be predictive of the work to be done; i.e. does the outcome of the test
actually reflect the ability of the candidate to do the actual work? Unless
there is some formal proof, the test can be deemed predujicial and
restrictive. The burden of proof falls on the employer to show that those
persons who do well on the test actually do well at the job.
I have found that chatting with a candidate, his hobbies, and previous
experience was more useful in evaluating several things, only one of which
was how he would do with the work. Work assignments can be tailored,
monitored, mentored, and trained for. More interesting is what personality
traits I could detect -- would this person "fit in," be interested in
solving puzzles, have the temperment to put up with frustration? Granted, it
is hard to evaluate with one sitting; thus, we had several persons do
interviews, and have call-backs to explore deeper. I still think a person
who can solve puzzles and enjoy them can become a good programmer.
Anyway, most job positions are so nebulously defined that many levels of
skill and experience can fit into them if need be. I always laugh at the
"requirements" the HR department puts on openings. Their job is to eliminate
candidates from the mix, but they cover the ground so thoroughly that there
is never anyone who could fit their requirements. They seem to think an
entry level programmer should know C++, Java, Enterprise Editions, XML, UML,
SQL Server, Oracle, SAP, and sometimes COBOL and assembly language. Go
figure.
Here's an example I just pulled from Monster: Requirements for a Java
programmer:
- 2 years experience working with Documentum products (version 5 preferred).
- Knowledge of Documentum APIs, DFCs, DQL, WDK, Application Builder/
Developer Studio, Workflows, and Lifecycles.
- Programming experience in Java, JSP, XML, XSL and COM.
- Web development skills with knowledge of databases.
And this one almost looks possible! Am I wrong?

 

[Ann]

We used coding tests ("Programmer Aptitude Test") at IBM many years ago. It
was actually pretty simple and tested logical thinking. However, it ran into
legal problems. A test used to select or reject candidates must be shown to
be predictive of the work to be done; i.e. does the outcome of the test
actually reflect the ability of the candidate to do the actual work? Unless
there is some formal proof, the test can be deemed predujicial and
restrictive.

There must have been some bad hiring experiences in the past of the large
company I worked for in the 1980s. We were told to not ask any question to
a candidate that could be construed as a test of any kind. We could talk
about their experience, education, and what they might be interested in.

 

[.]

We used coding tests ("Programmer Aptitude Test") at IBM many years ago. It
was actually pretty simple and tested logical thinking. However, it ran into
legal problems. A test used to select or reject candidates must be shown to
be predictive of the work to be done; i.e. does the outcome of the test
actually reflect the ability of the candidate to do the actual work? Unless
there is some formal proof, the test can be deemed predujicial and
restrictive. The burden of proof falls on the employer to show that those
persons who do well on the test actually do well at the job.
I have found that chatting with a candidate, his hobbies, and previous
experience was more useful in evaluating several things, only one of which
was how he would do with the work. Work assignments can be tailored,
monitored, mentored, and trained for. More interesting is what personality
traits I could detect -- would this person "fit in," be interested in
solving puzzles, have the temperment to put up with frustration? Granted, it
is hard to evaluate with one sitting; thus, we had several persons do
interviews, and have call-backs to explore deeper. I still think a person
who can solve puzzles and enjoy them can become a good programmer.

My experience has been questions that are more theoretical in nature.
Typically I was given a test and then later I would have to justify my
answers.

Most the companies that didn't probe me much or were thrown when I
actually had a lot of questions about how they do their job got written
off. The company I now work at seems to use your methodology. I had a
number of interviews with a number of different people.

Anyway, most job positions are so nebulously defined that many levels of
skill and experience can fit into them if need be. I always laugh at the
"requirements" the HR department puts on openings. Their job is to eliminate
candidates from the mix, but they cover the ground so thoroughly that there
is never anyone who could fit their requirements. They seem to think an
entry level programmer should know C++, Java, Enterprise Editions, XML, UML,
SQL Server, Oracle, SAP, and sometimes COBOL and assembly language. Go
figure.
Here's an example I just pulled from Monster: Requirements for a Java
programmer:
- 2 years experience working with Documentum products (version 5 preferred).
- Knowledge of Documentum APIs, DFCs, DQL, WDK, Application Builder/
Developer Studio, Workflows, and Lifecycles.
- Programming experience in Java, JSP, XML, XSL and COM.
- Web development skills with knowledge of databases.
And this one almost looks possible! Am I wrong?

While looking for a new job I talked a lot with others. Someone also
brought up the fact that job descriptions were too restrictive.

Someone noted that if a company wanted to hire a foreign employee they
would take the employees resume, create a job description that matched the
resume PERFECTLY then wait for all the residents of that country to fail.
After a period of time the company could then claim they tried to hire
someone locally but no one was qualified.

Recently, I told a friend working in Dallas, TX I was quitting our company
because the environment at my site (different country) was not good. He
offered to get me transferred to Dallas. I told him there were plenty of
people in Dallas who could do my job; there was no way I could get a work
visa. He told me there were ways around that. Seems like it happens all
the time.

 

[nvenky]

ThoughtWorks interview experience

Hi,

I had a great interview experience with TW and made it through.. Chk venky-techspace.blogspot.com/2009/08/thoughtworks-interview-process.htm
for more details..

Regards,
Venky.

 

[art1go]

Thoughtworks sucks

I applied for a job at Thoughworks, I didn't pass the first step wich was to write a program from a text they gave to me (Kiwikand exercice).
I've done something which was working fine, writing test cases, javadoc, it was well designed even if that is always arguable. I've used maven though when I felt they didn't really know how to use it.
I was surprised to find some obvious none senses in some of the questions. I've finished the program quickly as I couldn't give 3 days working for free as they expected.
Thoughtworks said I didn't pass the test and they didn't give explanations.
Ok, although I felt that a bit rude, I wondered what consideration they would really give to their employees regarding how they manage candidates.
- none senses in the exercices.
- Asking to work on an exercice for 3 days for free.
- No feedback about the result.

Is working for Thoughtwork, just like that too?