How to prepare a programming job interview
Since I have been myself hunting for a job recently, I thought it would be a good idea to share with you what I think are a few and basic key points to successfully face job interviews.
Before the interview
1.- Find out about the company. Visit their website. Usually, at the beginning of the interview, you are given the chance to explain what you know about the company. Use this opportunity to show that you have some interest in them, and that you have done some research. For instance, if you know the names of the people who are interviewing you, google their names, many times you can find valuable information about them in sites linkedin or their personal blogs.
2.- Review the specifications for the position. They may ask you about technologies that you haven’t used for a while. A quick review the day before the interview can make a huge difference.
3.- Make sure you know where the interview is and how to get there. An obvious one, but worth to remind. I find it very useful to bring with me some notes with the names of he guys interviewing me, the address and the phone number of the agency.
4.- Arrive always a bit before to the interview. Another obvious one, I personally like to arrive to the interview 5-10 minutes before.
During the interview
5.- If you don’t know the answer to a specific technical question, be plain and honest. There is only one thing worst than not knowing the answer to a question and that is not being sure about yourself. If you don’t know it, don’t fake it.
6.- If you know the answer to a specific technical question, be precise, concise and rational. Meaning: answer what they ask you about, not something related. Explain as much as necessary, no more, no less. If possible, explain why your solution is valid as opposite to another solution.
7.- If asked to do some code review, design… Ask permission to stand up and use the board to explain better your ideas (assuming there is a board in the room). It is not only easier to explain your ideas through diagrams, it also shows that you are confident and have initiative.
8.- Ask questions at the end of the interview. Having interviewed people myself, one of the things I most appreciate is people that come up with good questions at the end of the meeting. Some examples maybe asking about their continuous integration process, testing strategy, architecture… One particular question I like to ask at the end of the meeting is “do you have any concern about my technical skills?” This question works great, because you are opening a door for the interviewer to provide you with immediate feedback about the interview. Also, if they do have some concern, you have a second chance to revisit the areas where they think you may be not strong enough.
At all time
9.- Smile and look in the eye to your interviewer. Looking confident and friendly is very important in a job interview, eye contact and smiling is fundamental.
10.- Relax, try to enjoy. Relaxing in a job interview and approaching it from a “let’s have fun” perspective is going to help you a lot to finish convincing your interviewers that you are the right candidate for the position.
[EDIT] Best contributions IMHO from the coments
11.- Bob: I would add: Study logic puzzles, algorithms and data structures like crazy… at least if you are going to interview for a coding position at any kind of startup. My last interview (two weeks ago) consisted of 4 hours and 5 different interviewers, and I spent a good 3 hours at the white board solving, or trying to solve, tricky logic puzzles and programming problems. There was very little interest in my work experience and past projects, and I have 15 years experience. Google and MSFT have ruined the interview process…
12.- Amin: Good points. Another tip can be referring to your previous cool projects. For example when you are talking about a method or algorithm you can refer to a project that you have used that method or algorithm and talk more on the results.
13.- Rick: Good, but all rather reactive. The most important thing to remember is that your chances of getting the job don’t depend on the quality of your answers, but in the way you can make your interviewers feel about you.
One good starting point for that is to try to figure out before or during the interview what problem they have that they are looking to solve by hiring. Because it is rare that a company is looking for just another programmer like the other ones they already have. There’s a specific void that needs filling, and only a small part of that void is described in the job description.
Related posts:
Java and tree data structures.
There isn’t any standard java implementation.
In almost every single project I have been involved, at some stage, I have found necessary to use a tree data structure, but I have found myself rewriting the same code to represent it because Java doesn’t provide with standard interfaces and implementations for Trees.
There are some open source tree data structures, but they are not flexible enough.
It is also surprising that there isn’t any major open source project, at least that I’m aware of, that tries to fill this gap. I have found on the Internet a few attempts to implement trees, but even thought they are correct, I don’t think they are as flexible as they should be.
The usual solution, the composite pattern on the objects itself, is far from ideal.
The most common implementation of trees, is using the composite pattern on the objects itself, meaning that no abstractions are created for classes as Tree, or Node. This approach has two main flaws:
- Low cohesion: Now each object which is member of the tree needs to also have methods for navigation, insertion or other operations which are completely out of the scope of their own nature.
- High coupling: Each node knows about their parents or about their children, changing one of them usually requires to changes the others as well.
How it should be (IMHO)
In my opinion, these are at least the main characteristics that a flexible Tree library should have.
- Ability to branch and sub-branch. Instead hanging nodes directly from other nodes, have the ability to add branches and sub-branches to nodes and hang the child nodes from them.
- XPath enabled. So you can call something like Node<Something> node = tree.get (“path/to/node”);
- Navigation specified through strategy. Navigator nav = tree.getNavigator (Strategy);
- Ability to filter.Navigator nav = tree.getNavigator (Strategy, Filter);
- Ability to create sub-trees from nodes. Tree subTree = new Tree (tree.get (“path/to/node”));
- Multi-threaded.
Your opinion and collaboration.
The main reason to write this article, is that I’m actually about to start writing this library myself, and I would like to share it with everyone, but before, I would like to hear from you guys. What’s your opinion: Do you think this sort of library would be useful? Would you use it? Do you think there are classes already that I might not know that have this functionality?
I am really looking forward for your comments!
Related posts:
- How to create services in Java
- Are you using too many technologies in your projects? The 7 anti-patterns for technologies, frameworks and other technicalities in software development.
- Loose coupling is overrated.
- The next software development revolution is here… Are you ready?
- Robustness, the forgotten code quality.
Waterfall vs. Agile: QA and Management
FYI:
The third and last part of the post Waterfall Vs Agile that I’ve been writing for DZone has just been published, follow the link to read it…
Waterfall vs. Agile: QA and Management
Related posts:
Waterfall vs Agile: Development and Business
FYI:
The second part of the post Waterfall Vs Agile, has just been published in DZone, follow the link to read it…
Waterfall vs. Agile: Development and Business
Related posts:
QDD (QA Driven Development). How QA should be…
Historically QA is been considered the last stage of software development, and QA testers have been seen as not necessarily qualified people, that all they need to do is to run manual or some automated UI tests over applications handed over by development.
This classic approach is somehow still used even in several agile projects, and it has many inconveniences:
- QA becomes a certification/cop department that adds very little value to Development.
- It only assures the quality of the final product, but not the quality of the code.
- It creates the illusion that software can be created without bugs.
- It’s not synchronized with the business needs, but with the requirements contract.
QA should switch to a new paradigm, QDD – QA Driven Development. In QDD the main role of QA should be to engage with development and the customer.
In order to achieve this new paradigm, QA should:
- Review not only the final product, but also the code. The code is the big gap in classic QA. It is never itself checked for quality. Low quality code will make the maintenance of the application a nightmare.
- Be involved in the day to day of development. QA should be present in every single important decision taken during development. They should also be aware of what the code looks like through daily code reviews or pair programming.
- Have qualified and skilled employees. QA should drive the development, and that requires QA personnel to be very skilled and qualified.
- Keep continuously updating the customer. QA should make sure that the application as it’s developed is fulfilling the customer’s expectations. It should also be their duty to guarantee that new requirements are identified, and also to identify previous requirements that are not necessary anymore.
- Decide when a feature is completed. As the top part of the pyramid of software development, QA is the most qualified member to decide when a feature is completed.
- Create a comprehensive suite of automated tests. QA should aim to cover as much as possible with automated tests, this will guarantee that regression testing should be easy to perform for each new feature.
- Handover requirements to development. QA should have the best understanding of both, technical and non technical aspects of the application. That is what will make them the perfect candidates to handover new requirements.
- Have formal authority over development. None of the previous points would be possible is QA is not given formal authority over development.
Based on these characteristics, QA personnel will have to be well trained in computer science, actually, QA should be an specialization of software development, and not a completely different branch. An ideal candidate for QA then should be a seasoned developer, with coach and lead abilities.
Of course to move to QDD there are very big challenges, being the three most importants:
- Companies that have QA infraestrucutres and personnel not fitted for this new paradigm, and not wishing to lose their investment.
- Developers not willing to become QA.
- Companies are afraid of the over cost of switching non-qualified QA people for skilled developers.
While these are important factors to overcome, in my opinion switching to this new QA paradigm will bring benefits in the mid/long run as the quality of the applications delivered will grow exponentially.
Related posts:
Waterfall vs Agile: Can they be friends?
To all my readers.
I’ve been honoured to author an article for dZone, “Waterfall vs Agile: Can they be friends?” If you follow the link you should be able to read it.
Thanks!
Related posts:
10+1 things they never teach in college about programming.
I still remember how naive I was just after I finished my studies. I was convinced that I was ready to join any software company and start shining as a top class developer. Obviously, no long after I started working, I realized how many things I didn’t know.
As I have been acquiring experience, I have been learning things the hard way, stuff which I was never taught, and which its understanding, is basic to become a good developer. This is my list of the 10 things I wish I had been taught.
1.- We’re always wrong.
Developers, among other non technical defects, have quite big egos, that´s why is very hard for us to recognize that we were wrong about something. I’ve seen many endless design discussions where developers will go on and on with their own ideas… well, guess what.. We are all wrong, the only difference between our positions is the degree of wrongness.
Is very important to understand and embrace this fact, only once that we do so we will be open to listen to others and use their own ideas to build a better solution.
2.- If something can break, it will break.
Aka “hope driven development“, if you are not sure about something, if you find yourself using the word “should”, then you are in trouble.
There is only one solution for this, do whatever is necessary to make sure that it doesn’t break, this could mean that you will have to write a test, debug, clarify the requirements…
3.- All code is crap.
After 10 years complaining about all the code that surrounds me, I have come to a brilliant conclusion, all code (including mine), is crap. Of course there are many degrees of crappy code, but even the best code I’ve ever seen is not easy to read.
This doesn’t mean that is not worthy trying to make your code better, all the opposite, there’s a huge difference between the best kind of code and the worst kind of code.
4.- There is always a bug.
ALWAYS! Is just a matter of how hard you look for it.
5.- The most important thing is the client.
Among many things the client doesn’t care are: the technologies you use in the project, how many more things that required the application does… or in general, if you use good practices.
And since I can imagine how much hate comments I will get if I only leave the previous paragraph, let me clarify what I want to say… We should never forget the client perspective, sometimes developers use technologies or insist in over engineering just for the sake of using best practices, but remember, if it doesn’t add any value for the client, drop it.
6.- Design on paper doesn’t work.
I used to believe that I could put my whole design in a paper upfront, and then just fill in the gaps, but it simply doesn’t work.
Software development is complex, is hard to see all the entities and their relationships until you don’t get the hands dirty. So keep planning and designing upfront, it is very helpful, just don’t try too hard, and don’t take the diagrams as contracts.
7.- Less is more.
Or as you probably know it better: “Keep it simple, stupid!” (KISS). So if is not necessary drop it, because remember: “If something can break, will break”.
8.- Coding is only 20% of what we do.
Be ready to spent 80% of your time thinking, debugging, testing, in meetings, conversations… And all of the other activities are very important, so you have to develop a wide range of skills, not only technical, to become a good software developer.
9.- The customer doesn’t know what he/she wants NEVER!.
Customers have a necessity, or an idea, but they don’t know the details… Software development is all about discovering the details and removing all the uncertainty and converting them into an application.
10.- Someone has done it before.
So don’t reinvent the wheel, use Google, or better yet, ask your colleagues, many times they may have done already the same or something very similar.
Bonus: Hey! Our job is cool!
On the bright side, programming is still cool!
Related posts:
How to create a good domain model. Top 10 advices
Domain modeling is the most important part of software design. Having a good model allows developers and business to have a common language, which in turn, makes much simpler the communication of requirements and the maintenance of the application.
Having a good model is synonym of having a low representational gap. Having a low representational gap means that the main concepts and their relationships from the real business model are represented almost identically in the software domain model.
Creating a good domain model is one of the most difficult challenges developers have to face. What follows are some advices to create a good domain model
1.- Understand the business model completely.
In order to create a good domain model, developers need to look into the detail of the the business model, not only in the surface. It requires to understand and distill the main entities and then find their closest equivalent software abstractions.
2.- Use good names for all your domain model classes.
Naming is critical in software domain modeling. There are two qualities that you should be looking for in a good name for an entity in your model:
- Consistent. Business and developers should always use the same term to define a single concept.
- Exact. A name should exactly define the responsibilities of an entity in the domain model.
3.- Use metaphors.
Many times is necessary to model abstract operations/entities in software development, (processing orders, simulations…), for these cases, metaphors will help you to simplify the design of the domain model.
4.- Make the domain model self-contained.
The domain model should contain the raw logic of the application. Any additional logic should be contained in some other layers, as for instance the work-flow, dependency injection, persistence…
5.- Make the domain model independent.
The domain model shouldn’t change because the underlying persistence implementation or the UI or any other layer changes.
6.- Make the domain model technically simple.
It should only contain POJOs. The responsibilities assigned to an entity in the domain model should be limited to only those necessary for the software domain
7.- Keep the domain model updated.
Synchronize it always with the business domain model, having two unsynchronized models is one of the biggest sources of productivity killers. Synchronization requires refactoring and enough test coverage to make sure that things don’t break as they are refactored.
8.- Make the software domain model match the business domain model.
A software domain model should be easy to understand for a business domain model expert and it shouldn’t have any discrepancy.
9.- Care for the code quality of your domain model.
There are two reasons why you want to make sure that the code quality of the domain model is top-notch.
- The domain model is the foundation of your application, if it is bad, the whole thing can fall apart
- It changes a lot. There are very few areas in your code that are going to change so many times as the domain model
10.- Test the domain model independently, and involve the customer in the test.
As already mentioned, the domain model is an independent and very important part of the architecture of the application. That’s why is so important to pay attention to test it in isolation. Involving the customers in this test phase can be very productive as they can identify test cases that are likely in production and which probably are the most interesting ones to test.
Related posts:
Before coding… Think!
There is lately a lot of hype around engineering practices as TDD, Refactoring, keeping things simple (KISS)… and while they are great, it is important to remember that they will never replace your intelligence and experience.
Engineering practices are considered by some developers to be the best tools in your toolbox for coding but the best tools are still the very old same ones used to solve any problem: a board, or a piece of paper, and some other good programmers to discuss the issue with.
Some developers, usually action heroes, tend to overuse engineering practices (mainly refactoring and KISS), falling in the “no need to think” mode. This particular kind of Hope Driven Development (HDD) is a constant source of bugs and productivity killers. It is like if we try to go from A to B only looking at our feet. It can only work when there isn’t any big, or unexpected obstacle in the path.
Engineering practices only help you to drive your code, but they can’t take any decisions for you, so before you start coding Think!
- Always ask other colleagues to review your ideas and code, and offer yourself to do the same.
- Use meeting rooms with big boards. It might look ridiculous if your are not used to it, but drawing on a board is a great way to share your ideas.
- Thinking beforehand doesn’t mean that you have to come up with the complete design of the application. That is impossible, but at least try to identify the big picture of what you need to design.
- Don’t let the enthusiasm for engineering practices make you forget that your intelligence and analysis are your best tools to create good code.
- Use engineering practices. They are great and will make you a better developer, but don’t hope that they will come up with the design for you.
- Don’t ignore parts of your design because they are complex. If you have to ignore them, do it because it is not necessary to deal with them right now. If you are going to code something and you know already that you are going to deal with some complexity try to fit how you are going to deal with it in your code.
- When coding a part of the application, think on the big picture and how are you going to integrate that part with the rest of components of your application.
- Remember that apart from your intelligence there are other things that are more important than the engineering practices such as having fun or other non technical skills.
Related posts:
Stop waiting to the end of the project to start QA!!! (And other QA principles)
Many project managers consider finding major bugs during QA an unexpected occurrence, which is like going to war hoping not to have any causalities. One consequence of such naive reasoning is that they usually schedule QA as the last stage of software development just to find that:
- It doesn’t allow for any reaction time when major bugs are found.
- It creates a lot of tension between QA and development. It becomes crucial for development to pass QA because they know they won’t have enough time to fix any major bugs.
- It is not suited for exploratory testing. Exploratory testing, allows testers to have an out of the box approach to testing which is excellent to find the most important bugs of the application.
- It requires heavy handovers and setup.
A lesson I learned quite a while ago is that QA as a separate process may work in other industries, like manufacturing, but it doesn’t work in software development. Every single unit of functionality that is coded for an application should be QA’d immediately. In particular referring to QA, these are my principles.
1.- There are no handovers between development and testing.
Coding and testing are not two separate processes, they are performed in parallel, and one can’t be completed without the other one and vice-versa. [extracted from: Continuous Integration, going beyond continuous compilation]
2.- Developers and Testers have a common goal.
They don’t perform different activities. Developers are not just focused on developing and testers in testing. They share a common goal- to produce quality software in coordination with the product owner expectations. [extracted from: Continuous Integration, going beyond continuous compilation]
3.- QA and development must provide their schedules as one unique schedule.
There isn’t one schedule for development and another for QA, and that’s because they depend on each other.
4.- The QA tester role shouldn’t be less valuable, skilled or recognized than the developer role.
I have worked in many projects where QA resources are seen as second class employees that perform easier tasks than developers. In many projects, the kind of role that is pursued is a tester that only follows a test script, taking notes on the expected and actual result for each step.
In my opinion, testers add a lot of value to the project, they should be responsible for writing automated tests, setting up stage environments and coordinate with the business making sure that they know what they expectations are.
5.- QA tester and Developer don’t need to be two different people, it is only two different roles.
Because QA used to happen at the last stage of software development, and because it was seen as a sort of certification process, management decided that QA should be part of a completely independent team, and that introduced the idea that the QA tester and the developer should always be not only two different roles, but two different people.
6.- QA should be scheduled so that I could take up to 50% of time of development.
This is just a rule of thumb, and of course it depends in a case by case basis, but is important to understand that QA is a very important task that when is completed could take up to 50% of the development time.
Related posts:
![[Google]]( http://www.makinggoodsoftware.com/wp-content/plugins/easy-adsenser/google-light.gif)
