Is it fine to discuss technical issues during the interview?

Question

I don't know how to write the title properly but my question is for start-ups as it wouldn't apply for large corporations.

A start-up has got their service available, however when I tried it, I found it slow.

At the first interview with HR, I did not talk anything technical, however now I will be talking with an engineer about technical aspects.

I was wondering whether If I can comment on their system as "slow" and tell them that I have used faster libraries/APIs/technologies, which are faster and they might use them?

I don't see this being a problem for let's say 1 month start-up as nothing is built properly but what about a start-up like 1-2 year old?

If I can ask, what sort of attitude and behaviour should I have? If I cannot, can I ask something similar that would give the interviewer a positive thought about me?

Answer 1

I was wondering whether If I can comment on their system as "slow" and tell them that I have used faster libraries/APIs/technologies, which are faster and they might use them?

I'd be very careful on this point. Do you know what kind of load they were experiencing at this time? How well can you articulate what you call "slow" here? Are you sure you'd pick other things that would be faster and not what they are using but you just don't see it under the hood? Imagine if you advocate they use, "Quicker.js" only to find out that it is in there already? Now what do you look like?

I don't see this being a problem for let's say 1 month start-up as nothing is built properly but what about a start-up like 1-2 year old?

How well could you articulate all the possible factors of choosing this technology or that one? Understand that you may not have that great of a picture here and that if you do pick something bleeding edge it may well backfire if there is a problem with it.

If I can ask, what sort of attitude and behaviour should I have? If I cannot, can I ask something similar that would give the interviewer a positive thought about me?

While I'd think you'd have the capability to form the words, I'd question if you'd have the diplomatic skills to ask this in a proper manner. Thus, I'd think you can do it but it may well be suicide if it isn't done carefully. How well do you know what went into the decisions of what technologies to use, what hardware is used, how well does it scale and other stuff that may put you into a rather uncomfortable position?

Answer 2

I doubt it's a problem, but it's also not necessarily the venue to bring it up. If I'm interviewing, then my goal for the meeting is to assess your capability to do the job that I'm hiring for.

Very often, the quality or performance of my product isn't a part of the equation... I might be hiring you to fix performance problems, and that would be a great opportunity to mention that you've noticed it and possibly have some ideas for why it's happening and what a potential solution might look like, but otherwise it's off-topic.

Answer 3

I was wondering whether If I can comment on their system as "slow" and tell them that I have used faster libraries/APIs/technologies, which are faster and they might use them?

Tread carefully here.

Make sure that worrying about performance is something relevant to the role you would be performing.

If your role in this company would be as a Performance Engineer and you would specifically be tasked with speeding up the system, you might try to see if the interviewer is open to discussing your observations. "While preparing for this interview, I took a look at your system. Would you like to talk about what I see?"

Then watch the reaction carefully, and try to gauge how receptive the interview might be. For example, you might be talking to someone who has no knowledge of these libraries, and you would be wasting your time. Or this interviewer might be very interested in your findings. Let her/his reactions be your guide as to how deep you want to go.

If I can ask, what sort of attitude and behaviour should I have? If I cannot, can I ask something similar that would give the interviewer a positive thought about me?

Again, be careful here.

Don't accuse. Don't make it sound like the current people are stupid for using the current technologies. The interviewer might be the one who decided that the current technologies were appropriate.

Remember, there are many reasons for using certain libraries/APIs/technologies - performance is only one of the reasons. Ease of implementation, licensing, maintainability, etc - many other factors may have gone into the decision; factors into which you don't have insight. Speed may be only a minor factor in the bigger scheme.

And of course, the company may be too invested in these systems to change at this point, so criticism won't be constructive.

You don't want to come across as someone who will complain about all past decisions. You don't want to come across as a one-trick pony ("I know technology B, so I'm going to recommend it every time I can.")

If the interviewer asks "So what do you think of our technology here?" it's an invitation for careful constructive criticism. But if not, use the tone of the interview to sense if your observations will be well received or not.

Answer 4

As part of the, Why do you want to work for this company? or What research on the company have you done? type questions, you can bring up the website. Be careful how strongly you discuss the slowness of the site because it can sound too critical. Focus on wanting to take the challenge of making it better. The technical interviewer may ask you for suggestions or what you would do to help, so then you can talk about ways to improve performance.

Ideally, you want someone else to acknowledge the performance problem of the site before you do, but you can steer the conversation in that direction. Just don't push too hard.

Too often technologist come in at the end of a project with these great ideas without any regard for those that suffered through getting something done on time. It's easy to cherry pick a small area for improvement when you're not responsible for making the whole thing work.

Answer 5

If you are asked to comment, then comment. I was asked to comment during an interview at a startup, and I told them what I thought using examples/evidence while we looked at the system in production. It's part of the reason I got the job.

If they don't ask, then don't go there. From a hiring perspective, if an interviewee starts telling me how our system(s) are sub-optimal I'm going to smile and show them the door - people drawing conclusions about our systems before they get the facts are not going to get a second interview.

Answer 6

Personally I would rather discuss my knowledge of how to improve performance as a strong plus for selling me as their candidate without stating that their site is slow. You are making the point you have the knowledge and experience they might need without saying outright, your site is slow. You can get fairly technical in this by describing how you might approach or have approached solving this type of problem. They know if their site is too slow, no need to rub it in, just make sure to make the points about your skills. If they don't bring it up directly in any of the questions, most interviewers ask you at the end why you should be hired or if there is anything you want to add. Bring up your skills and experience in this area at that point.

Answer 7

Always be careful in any new endeavor. Look and listen for much longer than you think is necessary before you speak. They say a good lawyer never asks a question he doesn't already know the answer.

What are you going to say if they're already using some of those technologies? Is it possible they're aware of the situation, but are waiting for additional funds to upgrade hardware or bandwidth?

I'm guessing during the interview process, someone is going to mention needing a developer who can improve performance. If you find yourself answering technical questions before this is mentioned, you may want to give additional support for your technical suggestions by including performance as your reason. Many technical depend on "it depends" so you can use this as a way to justify your recommendations.

Unless you know what API (as an example) they're using and the context it's being used, you may find your suggestions aren't very helpful and shows you are not tactful or easy to work with. If you're not careful, they may conclude you lack expertise in this area.

I'd wait on this one.

Answer 8

Couldn't you turn your comments into a positive? You never know if you are going to insult one of the interviewers who is quite proud of the work they did on the current site.

Instead of criticizing the site for being slow how about you say that you looked at the site and had some ideas for optimizing performance and explain them. That said, if you came to an interview with a silver bullet solution (this library/API would be faster), I'd think you are a n00b or a platform snob and take a negative opinion of you. Proceed with caution.

Answer 9

Bringing up the issue will tell you a lot about the company's personality - but do so carefully.

In a small startup, people take on many roles, so someone who has useful skills for improving the product is a win. So is showing enough interest in the product to have played with it and to have taken the time to think about ways it could be improved.

At the same time, it's a much smaller group of people who have to work together cohesively. So how you bring it up and how you participate in the conversation will tell them a lot about whether or not they want to work with you. While one startup may love that you are willing to bluntly and clearly bring up a design flaw in their product, another may feel very protective of the implementation choices they've made, and you may do better with an asking format ("do have any needs for faster performance?") rather than a telling format ("your performance is slow, I can fix it").

The only thing that's been a deal breaker for me as an interview is when a candidate walks in with a preconceived notion of how things should be and can't be enlightened on why we do things the way we do things. That's a bad sign for future collaboration, because it suggests the candidate can't or won't listen.

At the same time - for you - there's going to be a lot of useful information in how they react. Ideally, your feedback might be a start for a great discussion on design tradeoffs and optimization. Conversely, getting abruptly shut down and basically told to be quiet will tell you that your input probably won't be valued after you are hired, either.

In the sense that interviews are like first dates - this is the equivalent of telling your date that they've tucked only half their shirt into their waistband - certainly if it was you, you'd want to know, but do it wrong (pointing and laughing) and you probably won't get a second date.