8

I am software professional having enormous experience of software development (viz. in C++) and have worked in many prominent multi-national software companies and in various domains.

Few years back I came out of job. Then out of my own passion I developed a server framework in C++ (which is more than 65 thousands of lines of code). I've designed it, coded it, tested it for high performance and released it. I've done it all by myself. It is all single handed work done sheer out of my own passion. Now I have made it all open source where-in I have created its detailed design documentation as well (available on GitHub). I also launched a website and an Android App based on this framework.

Despite of doing all this, whenever I face interviews (currently I am looking for job) interviewers sounds completely disregarding the work that I have done. They do not even seems caring to look at my source code or documentation, and simply ask me questions like:

Can you please tell us how can you design XYZ using C++ ?

(This XYZ can be like anything for e.g. "XML format", "Vehicle parking system", "Files processing software", "Cache storing application" etc)

I am finding this is truly annoying and painful. How can someone design something in quick few minutes right in front of them & there itself? I mean I surely can design it all, but I need some time to design (And I believe many do). But here I cannot buy time or space for myself. They want me to design there itself right in front of them while they are staring at me. Then helplessly I go on telling them anything what comes to my mind at that moment. Sometime I experience nervous breakdown also. And as a result get rejected in the interview.

I must note: It also has happened that I came up with perfect design as an answer for such questions but after interview is over. For example, in one interview I was asked "How would you design parking system when given there are multiple parking slots and for various types of vehicles?" Then after coming out of the interview, I realized I should have told "Parking, Vehicle, Slots are classes. Parking will have member objects of class Slot. Car, Truck, Bike etc will be derived from class Vehicle. And then we can have appropriate methods. Some of them are virtual. Vehicle class could be abstract having pure virtual methods and so on..." It was that easy. But right in front of them, very much at that time itself, under "do it now and let me see" pressure, I could not have thought of it all clearly and what I went on telling them was totally weird.

Thus, despite of designing complicated projects (along with their coding and testing) like high-performance server framework and Messaging app, all by my own, I still get rejected in multiple C++ interviews in this manner. In one of the interviews I tried to tell them to go through my GitHub repository and have look at my design and coding. But of no use. This is really extremely frustrating experience I am going through these days.

Please advise me and give me suggestions as to how can I go about it next time I face interview. Time is running fast and I cannot afford loosing interview opportunities just like that. Please help.

closed as too broad by gnat, Dukeling, The Wandering Dev Manager, Jay, Malisbad Jun 30 at 22:17

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Voting to close, as this looks more like a rant than an actual question. – espindolaa Jun 28 at 18:19
  • 1
    @DarkCygnus, till now gone through more than 3 such interviews. One was SkyPe, rest were face to face. – mr.solo Jun 28 at 18:21
  • 1
    @mr.solo I see, did they actually expect you to code everything needed to do XYZ? Or where they asking for the outline and logic you would use if developing it. – DarkCygnus Jun 28 at 18:22
  • 1
    @mr.solo this is one of the things they are testing as well: how does pressure affect you. I guess your best bet would be to practice such things with somebody. The other person would be coming up with such tasks and with some reasonably random answers to your questions, your task is going to be to come up with the design. Try to keep it under 30 minutes every exercise. Couple times a week. And don't be perfectionist. Just do it (TM). – AlexanderM Jun 28 at 18:39
  • 2
    There are plenty of resources online explaining how to answer system design interview questions, e.g. Top 10 System Design Interview Questions for Software Engineers, System design interview for IT companies, How to Succeed in a System Design Interview, InterviewBit. – Dukeling Jun 28 at 19:18
9

Despite of doing all this, whenever I face interviews (currently I am looking for job) interviewers sounds completely disregarding the work that I have done. They do not even seems caring to look at my source code or documentation

Don't be surprised by that. Interviewers not always are people with software background, and if they are they may not have the time to look at the source code of all people applying for the job.

Also, it could be that Server Frameworks are not related to the specific things they do on that company, so mentioning that in your CV is relevant (as it is C++) but perhaps not as relevant for them in their area.

Please advise me and give me suggestions as to how can I go about it next time I face interview.

First thing first, I suggest you try to keep it calm and cool. The calmer you are the better you will be able to think and perform in the interview. You say you have lots of experience in C++, so bear that in mind next time you get nervous.

Second, be aware of interviewers looking to get free work from you. As per your post, it seems that the interviews you had recently asked you how to design XYZ using C++, and then were expecting you to do it and finish it in front of them.

Depending on what XYZ is and what it entails, this is completely unreasonable to start and finish during an interview. Most likely (I guess) they were asking you to outline and describe how would you design it in C++, and perhaps write some code with TODO stubs in it for the complex parts... but coding it all during an interview is quite a long shot.

So, next time you are in an interview and they ask you how would you do XYZ in C++, start by indicating the approaches and designs you would use. What patterns would be useful, what caveats can one expect and perhaps what tools or plugins would be useful. If they ask for some code, provide the outline for it, and leave the too-long-for-an-interview parts commented as TODO.

When doing this keep in mind the first thing (keep calm, you got this), and when writing the sample code focus on the outline of the project; don't try to code each and every aspect. Try to focus on the bigger picture. Define the methods you will use, code the ones that are doable in an interview and leave the rest empty (but declared).

Another thing that could greatly help you is to simulate an interview process, as you say you know your stuff but get nervous when under pressure and being stared at (if you can get some friend to help play the role of the interviewer would be better). Think about some random project idea, and try to outline it as concisely as possible, writing some snippets and leaving the complex parts empty... Perhaps you (like me) prefer to think it thoroughly before starting to code; this simulation will help you to "improvise" better in interviews, and be able to write snippets without having to think and consider every possible scenario.

  • 3
    Since the biggest issue is seems to be a pressure put by the interviewers in the "simulation section" I would suggest to practice it with somebody else, where the other person is going to be acting as interviewer and would come up with crazy tasks (not the ones you have any interest in), look over the shoulder, ask reasonably stupid questions and provide a random answers on your questions. – AlexanderM Jun 28 at 18:45
  • 1
    @AlexanderM lol, yes that would make it more realistic (including it in the answer, thanks)... perhaps putting a timer would also increase the stress of the simulation (and provide a point of reference for OP to improve) – DarkCygnus Jun 28 at 18:50
  • Developers are rarely asked technical questions by non-technical people. Never at serious companies. "Second, be aware of interviewers looking to get free work from you." Only the tiniest no-hope startup would try this, and they would give it as a take-home problem. – kevin cline Jun 29 at 10:04
8

I doubt they are expecting you to design an entire system out of thin air right before their eyes.

They want to hear about what process you would employ to get the job done.

Answer similarly to:

I would start first by gathering all the requirements, then start gathering the resources to complete the requirements, once I had all that I needed to get to work I would proceed to establish the base framework of X and start building Y then Z then finish up by closing all the "what nots". Then once testing was complete and successful, I would document the entire thing and post the project...

or something similar to those lines. If they ask you to make a sandwich you don't waste time talking about cultivating soil to grow flour and making bread, or raising pigs before turning them to ham. They simply want to hear you describing spreading mayo on bread, slapping cheese and ham on it and finishing it off with a napkin.

  • 1
    "I would start first by gathering all the requirements, then start gathering the resources to complete the requirements," That's too basic to mention. The candidate should start by clarifying the requirements (use cases) for the system. – kevin cline Jun 29 at 10:24
6

I think you misunderstand two points about design and design process.

First, design and specifications, just like software, are never finished, only released. That is, you can always start small, cover most of the important ground given known knowns, commenting on known unknowns, and hypothesizing elsewhere. Remember, this is a test of communication skills, as much as technical proficiency.

Secondly, you might mix up design and implementation. I think that because of your quote:

For example, in one interview I was asked "How would you design parking system when given there are multiple parking slots and for various types of vehicles?" Then after coming out of the interview, I realized I should have told "Parking, Vehicle, Slots are classes. Parking will have member objects of class Slot. Car, Truck, Bike etc will be derived from class Vehicle. And then we can have appropriate methods. Some of them are virtual. Vehicle class could be abstract having pure virtual methods and so on..."

You are getting absorbed by details of the implementation process before designing the thing. For example, why do you need separate classes for car type? Modern programming languages and practices are great in incremental improvements of the software. So start as simple as possible, with minimal ship-able product. Like with classes spot and vehicle. When you start your program, you'll initialize bunch of spots, and wait for cars to pull up. Even though you program in C++ (I am not) I think you don't have to go full OOP from start.

6

Why they do it

Inverviewers want to see your way of problem solving. It is not so easy for them to value your previous work even if it is accessible, as they don't know anything about the parameters, and they usually cannot spend enough time to really understand it.

Furthermore, being able to prioritize and talk through problems on an abstract level are skills that are important for some jobs, so interviewers may be interested in that too.

One more reason for asking you the same questions as everyone else is that it makes evaluating the interviews a lot easier.

You are not alone

Altogether, your description sounds like you are not uncomfortable solving design and architectural problems, but that you may not be doing it so well in an assessment situation.

You should not worry too much, this is very common in our sector.

"Failing" a few C++ interviews does not mean you don't have it, just that in those cases, someone else may have made a better impression.

So how do you prepare for this?

I would suggest: Compile a number of typical design questions from the internet, get a sparring partner, and have them interview you.

When you answer those questions, don't go into too much detail first. Try to paint a top-down picture of your solution incrementally, pointing out unclear requirements or assumptions you make while at it:

Interviewer: How would you design a parking system with multiple parking slots and for various types of vehicles?

You: OK, so our system should be controlling the ticket and vending machines?

Interviewer: No, let's imagine the parking lot is fully automated, you control all the lots and all the vehicles while they are on the premises.

You: OK.. er.. so, when a vehicle arrives, the system can either allow or deny entrance?

Interviewer: Yes.

You: ... depending on whether there is space available for that kind of vehicle?

Interviewer: Yes.

You: OK so if our system accepts a vehicle, it has to park it into an appropriate space. Then, when the customer wants it back, the system needs to retrieve it and transfer it to the exit.

Interviewer: Exactly. Let's not worry about how exactly the vehicles are transferred for now.

You: OK, well, we have different types of vehicles and different types of spaces in our system. I'm assuming each type of vehicle has exactly one type of space that it may use.

Interviewer: Hmm... OK.. I didn't think of that, but no problem, you may assume that.

You: I would probably define an abstract class "Vehicle" to encapsulate functionality all Vehicles share. I would then model each type of vehicle as a subclass of "Vehicle". Then I would...

Interviewer: So you are using inheritance for modelling vehicle types. What would you tell your colleague if they implemented this in a different way: They are using only a "Vehicle" class with a "type" member to distinguish the different types.

You:...

As you see, it takes really long before you even arrive at the class level in this example. The interview I wrote here shows the interviewer that

  1. you are willing to ask if you need help or clarification
  2. you try to understand the problem thoroughly before jumping into it, thus avoiding costly mistakes on the requirement level and
  3. that you can switch between different levels of abstraction and keep the overview in the process (that one is seen here only a little bit).

Your sparring partner should be, if possible, someone who understands very well what you are talking about. Ask them to pay attention not only to your solution, but also to the impression you make on them while answering their question. Would they hire you? Why would they, or why wouldn't they?

4

I've done a lot of interviewing, so here's a viewpoint from the other side of table.

"Despite of doing all this, whenever I face interviews (currently I am looking for job) interviewers sounds completely disregarding the work that I have done. They do not even seems caring to look at my source code or documentation"

We don't have time to read your 65,000 lines of C++ code. Even if we did, we couldn't be sure it was your original work. Nor can we make a hiring decision based on your resume alone. I've interviewed people with 15 years experience who couldn't solve simple coding problems, at least not while anyone was watching. Same for graduates with an MSCS and a 3.9 GPA. Some can code, many cannot.

If you want to get hired to a senior position at a top company, you are going to have to demonstrate both an ability to code and an ability to define a basic system design in a series of interviews. The people who can do this get hired.

The suggestion from Michael Jaros to do practice interviews is a good one. It would be best if you can practice with a friend who gives technical interviews.

If you are also struggling with whiteboard coding, practice that as well. Take some of the problems from "Cracking the Coding Interview" or whatever and practice solving them before reading the solutions.

Good luck.

  • ability to define a basic system design can you please share link to resource which will help me practicing/learning this? Thank you very much for your inputs. – mr.solo Jun 29 at 11:49
  • 1
    Sorry, I cannot. But it sounds like you have some problems you have collected from previous interviews. Practice answering them with someone who gives technical interviews. – kevin cline Jul 1 at 4:03
  • Yes I was actually indeed shocked to digest the fact that how people straight away ignore what work you've done all the years... and judge you based on what you speak in few minutes!... Anyways just got over it now. Thanking you all for your kind words here – mr.solo Jul 1 at 4:36
  • It's more than 'a few minutes'. People who have made real contributions to software projects can talk about them in considerable detail. We've learned that education and experience don't guarantee anything. Would you hire a musician because they have a degree, or would you want to hear them play? – kevin cline Jul 1 at 6:11
  • No, they never asked about my project. I have lots to tell about it otherwise. How did I conceived and completed it. How it's initial design got evolved over the time. How much efforts I have taken for its scalability and performance tuning etc. All they asked me are questions out of some ready pockets, available somewhere on Internet forums and videos. Musician is real good example as in one cannot ask musician to compose something right in front of them and judge him/her based on it. One gotta see the whole lots of compositions andwork he has done in the past. – mr.solo Jul 2 at 4:10
2

As sad as it is, interviewing isn’t performing your job functions. It’s sales. You are talking about the things you do, not doing them (or at least not in nearly the depth that really accomplishes a finished product). Unfortunately, until getting into leadership, sales is virtually entirely UNLIKE software development so skills that serve you well in interviewing have very little application in actually doing the job you’re interviewing for.

Put yourself in the interviewer’s position. He has dozens of resumes/CVs and six candidates to interview and he has all his normal work to get back to doing. He doesn’t need to know how passionate you are about a project he doesn’t need. He needs to see how you can work through a problem and how that will work with the team. He needs to know you are passionate about the type of work he’s hiring for, not the specific project you did.

It is understandable in the pressure of an interview, but I wonder if you have misinterpreted the intention. Your comments speak to classes being written, for example. He’s likely asking more about stubbing classes or what they might be for.

Interviewer: “Design an elevator control software”

Solo: “Let’s get a few details. How tall is the building? How many elevators are there? Do all elevators run the height of the building or do different bays service different levels?”

Interviewer: “19 stories, two elevators servicing the entire building”

Solo: “Great. I’m happy to get into more depth, like do we need emergency access or key-required access for penthouse floors. But with only an hour, let’s keep the assumptions to what you’ve stated.”

From there you talk through the communication is based entirely on buttons so you’ll want a basic button class. That class will include an OnPush() method which lights the button and sends a message. And it will have an OnComplete() that turns off the light when called. From here we have two basic types of interface: call an elevator and operate the elevator. “Call” sends a message to a scheduler class that manages which elevator to call. “Operate” buttons are inside the elevator and serve to tell the elevator where to go. These could each be a subclass of “Button”.

Again, remember you're showing the process with bits of pseudo code, not turning in a functional system.

Not the answer you're looking for? Browse other questions tagged or ask your own question.