I recently had a rather odd interview with a fintech company. The main goal was to figure out what my React skills are. It was a online live coding session.

Providing the assignment via zip download

The session started out that they provided the source code for this small coding session via google drive download link.

This should be a first red flag. It indicates that management / culture at the company does not allow the usage of GitHub or public repositories. There is not even an exception for the interview process where the code is sent out to the public.

This is something I would clarify during the interview process.

What does the code do?

First step was to get familiar with the codebase and the application. The source code did not provide a Readme.md.

The app generated a large amount of random data and displayed it in a table and added a switch.

My first question was: “What should the switch do? What is the purpose of the application?”

The interviewer could not explain what the purpose of the application is. Or why there was a switch. The simple answer to my questions was: “It is an artificial problem to see your react skills”

At this point, I thought “This is stupid - this will not adequately test my skills. I do not know what is the point of the application. Then there is nothing I can do to fix it.” - I should have listened to my gut feeling and stopped the interview immediately.

The Task - “How would you improve the code”

Oddly the first task was quite a good question. “How would you improve the code” - it is an open question and you can take the interview in any direction. You can see what the candidate values, you can have an open discussion about syntax, libraries, things that are. missing.

In this case there were a couple of obvious improvements:

Using TypeScript instead of JavaScript

You could improve the codebase by using TypeScript. Any long running project would benefit from using TypeScript vs JavaScript. It makes the code easier to read and would at least provide a minimum of documentation.

Interviewers response : No that is not the task for today.

Missing Tests

The application was created using create-react-app. However the ‘tests’ were removed from the code.

This is a very important aspect especially for financial applications. There is usually a high focus on bug free code. The only way to ensure that is to write tests.

Interviewers response : No that is not part of the tasks for today.

Cleaner Syntax

A couple of functions could be written using the arrow syntax.

Interviewers response : That is not the task for today. What is the benefit of using an arrow function?

Here I must admit I stumbled a little bit, because I have been using arrow functions for such a long time - I only remembered that you do not need to think abut the this keyword. (The correct answer would have been: “Does not have its own this bindings.”

The actual Task - “Look at the Performance of the Table”

The interviewer was not interested in an open discussion. He wanted me to find the obvious elephant in the room. The performance of the table is slow.

I failed the first test, that I could not identify the ‘correct’ problem to solve. - My argumentation that the foundation should be fixed first (especially in such a simple app)

Interviewer : When you click on the switch it is slow. How would you fix it?

Me : I would have less items

Interviewer : No, look at how the change handler is written.

I did not expect this answer, I expected that something like pagination should be introduced. Something that is realistic to solve in an interview 30min context.

However there was nothing wrong with the change handler. The problem was purely with the amount of items that are being rendered. I followed the interviewers wish and moved the change handler from the Table component into the Table Row component. - I did not expect to see any improvement. However it actually worked.

Interviewer : No, it only worked because you have a fast computer

Me : Fine then we throttle the CPU.

I had to google then how to get the Chrome dev tools to trottle my CPU, and the solution still worked. However scrolling was still an issue.

The interview goes even more sideways

The interviewer suggests that there is a simple fix for this issue. - Basically adding more stress, as I still cannot see the obvious ‘solution’.

I tried to explain that the underlying problem is the amount of items being rendered - you would have to reduce them by only rendering the items currently visible on the screen. Libraries like react-window does exactly that - its a very complex problem.

There is a reason why every major UI-Library provides its own large dataset table component. It takes a lot of effort to get this right - they expect me to solve it in a live-coding session.

The interviewer reluctantly allowed me to use a library, and wanted to watch me how i select a library and implement my solution.

Aborting the interview

It is an artificial problem that should be solvable with basic React skills - Not by using an external Library. I do not know the answer to this question - this interview is in any case over.

At this point, I stopped the interview. I was being pushed to do things I was uncomfortable with. I still had no understanding of what the actual problem is and the interview was becoming more and more antagonistic.

The final short discussion

I am so glad I ended the interview at this point. I explained that I cannot do this in this short time frame. I only can solve it with more information, clearer requirements and creating a table component to handle large amounts of data would take a month or so to do.

And the interviewer finally revealed what they are looking for: Developers that can solve problems quickly, and create custom solutions.

We are a financial company - we cannot use libraries.

The interviewer revealed a range of problems at this company.

• This small company does not leverage open source libraries for their product.
• They have outdated concepts of how software development should work.
• They are not open for improving the processes at the company.
• Instead of working on a solution to have a better way to evaluate libraries they develop everything from scratch.

What was probably the correct solution to the problem?

After the interview I looked at the problem again, without the stress of having two people staring at you and evaluating you.

Probably the answer the interviewer was looking for was that instead of using the Table-component from ‘material-ui’ you should have used the DataGrid-component of ‘material-ui’.

I have never used the ‘material-ui’ library and that solution has nothing to do with my knowledge of React.

In a live-coding session you usually write vanilla-js or some simple React Hooks, something that demonstrates your knowledge. Not a simple switch this component with another component. That does not demonstrate anything really.

Lessons Learned

I should not have ignored the first red flag. The interviewer could not communicate what problem is suppose to be solved. He did not answer any clarifying questions. I never had a chance to provide a satisfying answer.

In an interview the participants have to treat each other with respect. If the interview is starting to become hostile - just end the interview. There is no point in continuing. Just imagine how bad he will treat you when you actually work for him.

I could have saved myself 30min of awkwardness by aborting the interview earlier.