Testing Interviews for Applied Scientific Computing

Question

Do you know a good and objective question / test for studying applicants for scientific computer work?

(Actually, this test comes after the candidate has passed the interview.)

1) They must be smart. (Edit, thanks for the words from Trent)

2nd). They would have mainly to do programming (C ++ and Python, using scientific libraries), numbers and math, but also with technical and physical topics. Also, a C-like or Fortran-like style is not needed ... using an OO concept would be nice.

The applicant may have access to compilers, tools, libraries and the Internet. The duration of the test should be no more than 4 hours.

Answer 1

Well, the simple problem is to ask someone to solve a simple ODE system using any libraries that they want to use. None of the libraries that I know of are simple enough to be studied during the test. For example, solve this system for x=1:10 : dx/dt = -k (x^2/x) .

A tougher task is to ask someone to solve a rigid ODE system. Here, the choice of algorithm becomes important, and the “hunch” probably will not work. For example, most Michaelis-Menten equations are rigid.

 dS/dt = - vmax * S/(Ks + S) 

where dS is the rate of substrate depletion, and vmax and Ks are constants (which you can give to the candidate). Choosing the wrong solver here leads to rather disastrous results, as I learned first hand.

None of the problems is a good problem in itself, since almost everyone can solve one of them by trial and error, given 4 hours to solve this problem. But, as part of a larger test, they can be helpful.

EDIT: What does this prove? Well, ODE is everywhere in scientific computing. If at least you did not treat them at some point, this is a big hole in your knowledge. I was just trying to answer the question, how did I ask the question. "What are the specific questions to ask the applicant for scientific computer work?" To solve the problem, the applicant must know

1) The basic calculus.

2) Some kind of scientific computational library (MATLAB, SciPy, GSL).

3) If the question is asked properly (for example, if they were asked to calculate the acceleration speed), then domain knowledge is also checked (physics in this case).

I think this checks all fields :)

Answer 2

Find smart people and they will be able to adapt to your specific requirements. This is much better than trying to find someone to meet all of your “flags”.

Answer 3

but you should still check if they are infected. There are many reports of testing tests for interviews. Don't worry about your particular domain, just see if they can even code.

It is always open to the eyes; never bored. And it’s better to give a smaller test and discuss it with them, rather than a big test. Ask them why they made different options, etc. Then you will find out if they can clearly explain themselves.

Answer 4

I will probably regret it, but here is my general FWIW tip

1) Observe the interview for the candidate, not the specifics of the job.

You have a minimal set of Essential's in your specification that you will not compromise on, then look at the candidate and see what other skills they will bring to their place - they may even bring skills that you did not know what you needed.

2) Test the candidates

A test may consist of several verbal questions, a written test, etc. It doesn't really matter, but you definitely need to understand what the candidate knows and what they don't know.

3) Have candidates write code

You will learn more about someone, how they approached the problem, how they implemented it and more importantly, how they explained what they did to you than anything else. Remember that this is what you hire for them, this is what they will spend most of their time on

4) Do not ask a lot of questions about memory

Asking someone to remember the exact format of std :: algorithm or all methods in System.Xml.XmlDocument has no purpose. People use documents and Intellisense overcome this.

5) Ask open-ended questions.

Ask a few questions that do not have a “right” or “wrong answer” - this way you give the candidate the opportunity to offer their opinion, and you have a conversation, rather than an illustrious “tick list”. Two-way conversation helps because it allows the candidate to relax and just as importantly, it allows you to relax. The discussion can tell you a lot about the candidate, and they listen to your opinion about how they react to the counter-arguments.

6) See if they did their research

Always ask a candidate if they have heard about your product / team / game / company. If they cannot tell you just a little about the company they are contacting, then you do not want them to be in your company. It will take 30 seconds to type on Google, so be cruel about it. Believe me.

7) Do not interview yourself

You can be super smart, you can know what you want, you can think that you can read people, but software development is primarily a collaborative effort to get into a couple of people and just not get into another manager or senior coder - bring your team and listen to their opinions. The main thing is to catch up later and discuss the candidate while he is still fresh in your mind.

8) Do not rush to interview

The time spent on the interview depends on the type of position that you spend for the younger, experienced, senior, but always give yourself an extra hour for how long you consider necessary. It gives you the opportunity to breathe, and if you do it early, then good. If necessary, go to a second interview. I often do two interviews - the first is technical, and the second is more focused on the individual and the team.

You may not feel that it is suitable, or you do not have time, but do not discount it. If you feel that you did not have enough candidates for the first time, and still have the potential, then return them back. If they want to work in your company / team, they will return.

9) Ask for evidence

If the candidate says that “made a significant contribution to development ..... then ask them what they did, in detail, what they learned from experience and what they will do again. If they cannot give you evidence and details, most likely they didn’t make a significant contribution. Beware of candidates who use “we have been doing all this time.” Of course, development is done in teams, but they should be able to say what they have done and describe the team’s efforts.

10) Be prepared to be honest and frank.

Most candidates resell themselves slightly. That's great, their resume is what gives them an interview. However, if you think that the candidate is not completely in your own experience, then say so. Make sure you learn the strengths and weaknesses. Too many interviews end up being a continuation of the exchange. Yes, it’s great that the candidate knows what UDP is, but does he know when they made a bad decision and how they handle it? Ask them the last time they were wrong or the last bad decision they made. Be careful not to be too heavy or judgmental, although mistakes in use are absolutely natural, and most of us do all the time how we deal with this is important.

11) Do not take into account.

Theres a fine line between knowing your things and thinking youre better than everyone else. In a knowledge-based profession such as programming, this is always a temptation for all of us. I agree with Jeff Atwood on this. A good programmer knows that coding is complicated, and that they make mistakes, and their code sucks a lot of time. Bad programmers don't think - they think every elses code sucks. Caveat Emptor.

Answer 5

I can think of a few points that you can touch on:

• knowledge of floating point calculations and how an internal floating point (for example, see What every computer scientist needs to know about floating point arithmetic )
• some familiarity with approximation algorithms (for example, Newtonian approximation of roots, Reiman sums)
• general software for graphic display and visualization.
• efficient management of large amounts of data
• confidence intervals and uncertainty
• statistics and probability

Answer 6

I think that you should try to discuss the problem with a person to understand how they reason when faced with this problem. What algorithms do they think they are familiar with? What are the possible pitfalls they see?

By allowing a person to discuss with you, you can adapt to your specific skills, as well as be less likely to reject candidates who are nervous about tests. You can also get a good idea of ​​whether the person is suitable for your team - you do not want someone to really understand problems such as interviews, but you should not be bothered by discussing other ways to solve them or something else.

Answer 7

Test their math. A few simple questions regarding any mathematical knowledge that they should have are objective and can quickly reveal that 90% of applicants who do not have a business, even being in the field.

We often start our applicants with some basic questions of linear algebra. If someone does not know what a cross product is, there’s not much point in the interview.

One (good) boss I used to like to start an interview on the screen with the question: "What is two to eight?" It was amazing how many people were wrong. (Flubbing it would not end the phone screen, but it was a very strong predictor of a candidate who had serious problems at all.)

Answer 8

None of the previous answers seemed to mention domain knowledge - what part of the science (which was pretty big in the 21st century) that you work in? I work with a group of geophysicists working on computational EM problems. There are a lot of good scientific calculators that we would not look at twice because their domain is so far from ours.

I would suggest that it’s easier to train someone with the right domain knowledge and the wrong programming knowledge than vice versa.

Answer 9

"Convince me that you are the right person for this job"

With this question, you can test all the necessary skills for a good programmer:

• Intelligence
• Creation
• Communication
• Self motivation

... the only thing that has not been verified is the ability to work in a team, but it is difficult to verify.

PS as for knowledge, you can always ask a person to implement a circular ring buffer in the "most reusable way he knows", without access to the Internet, both in python and C ++. Real “useful” code speaks more about people and their coding culture than about tons of questions.

Answer 10

Here one scientific problem is quite interesting and complex, but it can be solved in four hours, if your candidates are really good. If not, you can ask them to describe the solution instead of implementing it or judge incomplete decisions. In addition to good programming skills, high school physics is needed.

The central heating system has a water circulation network consisting of pairs of pipes connected as a tree structure. The leaves have radiators, each of which must radiate the same heating power P (constant). At the root, the water entering the network (hot pipe of a pair of pipes) is heated to a temperature T1 (constant). The internal nodes of the tree are pairs of pipes, each of which is considered a certain length (constant len).

The heat is dissipated (lost) in the hot pipe U * len * (T1 - T0), where T0 is the room temperature (constant), U is the heat transfer constant (W / (m * K)). Due to this loss of power, the water cools until the radiators reach (even a slightly lower temperature means much lower power emitted by the radiator).

Each radiator has a valve that controls the flow (kg / s). Flow and temperature together determine the power emitted by the radiator. You can use the following function:

 radiatorPower(flow, temperature) -> power 

Implement a data structure that describes the network as a tree, and an algorithm to determine the required flux for each radiator, so that the Power emitter (flux, temperature) is P.

Please note that the temperature of the returning cold water is controlled by the radiated power and cannot be controlled or measured directly. Also note that on each branch of the tree, water carried by a pair of pipes is shared between all node children (radiators or other pipe pairs). The pipe heat loss equation uses the initial T1 on all pipes, since it is assumed that the heat loss on the pipes higher in the tree is not important for calculating heat loss (T1 → T0, and the losses are small).

 Water specific heat: c = 4190 J/(kg*K) 

Answer 11

I think you should ask him about your experience. About the questions: do not ask about language issues (for example, a = b ?? c ?? d), the programmer should have an idea of ​​the algorithms, problem solving and good communication skills in the team (this is very important, really)

Answer 12

I do not think that for something like this special tests are needed. Just bring smart people who are already working in this area and talk to the applicant. Perhaps there is also something like the one proposed by Kornel Kisielewicz. Ask him or her about previous projects, technologies used, what he liked, what not, etc. If the interlocutors are smart, they will be able to say whether he is right for this job or not.

I once gave an interview for a common position as a software developer. After a short chat message, they said something like: “In your resume, you say that you know C ++ and Java quite well. Tell us all the differences that you know between the two, not limited to the languages ​​themselves.” From there it flows beautifully, and you can easily ask questions when they come up. For example, when I said that C ++ is usually translated into machine code, and Java into byte code, they ask what is byte code, what are the advantages and disadvantages of any approach, etc.