The Pomodoro Technique

Entry 32

          I was recently attending a talk about planning stuff, and one of the aspects of it was an introduction to time management method called The Pomodoro Technique.  I’ve decide to try it myself and share some insights here.

The Idea

                The idea is simple and involves a timer and some discipline.


  • Decide what should be done.
  • Set the timer to 25 minutes, the interval is called a Pomodoro.
  • Work on the task until the timer rings. If you get distracted, just write it down, but get back to the task at hand immediately. Try to shield yourself from any possible distractions as much as possible.
  • Take a short break (3-5 minutes), stand up, walk, get something to drink, do a quick exercise. Anything that is not related to the task and will help you clear your mind. Go to next Pomodoro. Repeat.
  • If you complete four cycles, take a longer break (15-30 min) instead short one. Repeat.

The Execution

                It requires some time to get used to. Especially if you find it difficult to focus on one task and constantly think about dozens different interesting things to do, like me. Before I stumbled upon the Pomodoro, I tried to work in 45-minute focus and 10 min break cycles. Like in school, more or less. However, it actually seems that 25/5 cycle is better for me. I’ve noticed that after longer cycles, I tend to drift away much more, especially towards the end. Also, school is over.

                20160823_161540Besides timing, there is an issue of shielding from distractions. I’m trying to shut down email, social media, phone and all that stuff, put headphones on. What to do if someone comes to your desk in the middle of Pomodoro? Well, it’s up to you.

                As a tool, I’m using tomato-timer. It’s simple and got all that’s needed. There are plenty other pages and a lot of mobile apps, some with fancy statistics, but I didn’t research them. It’s just a damn timer. When I get up from my desk I usually leave my phone, and I haven’t used a wristwatch since high school, so I usually mess the break timing. Before I leave though, I start the break timer on my computer. If it’s still on when I come back, I just mindlessly browse cats or something in the internet or play with radio controlled Lego excavator I keep on my desk. If I come back too late, well… I just hop onto another Pomodoro (shame… shame… shame…).

                Using timer has also an additional advantage. You don’t have to check the time periodically and think about whether you should take a break or not, asses your mental fatigue level, decide if you are in a good place to pause and all that stuff. When you hear the Pomodoro rings, just finish your current thought, line of code, sentence, or whatever you got there, set a break timer and get up. Or just leave everything and get up immediately if it works for you.

                In typical office conditions it might be difficult to sustain perfect cycles. There are irregular meetings, there are people that want to ask something in person, there are delivery guys that won’t show up at exact hours. There is The Flow. There are fuckups on production… Just don’t try too hard, remember it’s a tool to help you, not to restrain you.

                Some mentally old people might have objections that the Labor Code (at least in Poland) states that you should work 55 min and then you got 5 min break. Yeah, that might apply to a factory, not to software development. If your manager would make you fuss about that, tell him he should manage factory workers not programmers. Any smart company would understand that it’s just a number on a paper that HR has to keep signed in a binder, and we are here to get the shit done efficiently, not to sit at the desk for a given number of minutes a day. And, remind me, why would you want to work for a dumb company?

The Retrospective

                stay_focusedPomodoro works for me. Perhaps, to some extent, it’s a placebo to help you focus. You might think somewhere around “Damn I’m using a legitimate time management technique that has a name, so I should ignore this Facebook notification and keep working until the timer tells me to stop”. Intervals? People are different, some can focus for more than 40 minutes, but most probably can’t. Where is the efficiency threshold? I guess it requires some experimenting and might be difficult to measure. 25 minutes seems fine. Go ahead, try the Pomodoro. It’s healthy.


Leave a comment

Posted by on August 25, 2016 in Misc


Tags: ,

I know what you committed last summer

Entry 31

            As promised, the continuation of Code of Principles is here. This time I’m going to talk about stuff that is less canonical and perhaps not so well known. Today’s motto is that you are not alone. There are strangers, psychopaths, users, fellow developers and good scouts out there.

Don’t talk to strangers


            Let’s discuss Law of Demeter also known as Principle of least knowledge. Proposed in 1987 by Northeastern University, can be informally described in four bullet points:

  • You can play with yourself (naughty boy).
  • You can play with your own toys (but you can’t take them apart).
  • You can play with toys that were given to you.
  • And you can play with toys you’ve made yourself.

Which basically means that object should assume as little as possible about its environment, surroundings, its structure, properties and anything else, especially about internal structure of objects it’s manipulating. Classic violations of this rule are chains of invocations like this: a.getB().getC().doSomethin().getD().doSometingElse(); By the way, such style poses additional problems when resolving exceptions. Can you tell which invocation threw one exactly? Code following Law of Demeter tends to be more maintainable and adaptable. Following it strictly has some disadvantages however, like introducing time and space overhead needed to facilitate wrappers and auxiliary access methods.

(P)rinciple (o)f (L)east (A)stonishment


            Also known as (P)rinciple (o)f (L)east (S)urprise. Often used in context of user interfaces from the ergonomics standpoint, along with (D)o (W)hat (I) (M)ean rule coined by Warren Teitelman in the sixties. Regarding user interfaces, people have experience, expectations and mental models. Design should reflect that in being the least surprising as possible. This also applies to code. You should construct things in a way that are intuitive, obvious, consistent, predictable and boring, based on the thing name, location and other clues. Try to leverage existing techniques, standards and conventions as much as possible. What if your project already violates those? Well it depends, if it’s easy to fix, just fix it. If it’s harder, nag your Product Owner for budget to do it. If it’s too hard to fix, follow the bad conventions. Bad conventions are usually better than no conventions at all.

         Good example of intuitive stuff is a ParseInteger(string, radix) method present in many programming languages, that has a one-argument version that usually assumes radix to be 10. Notable exception where it doesn’t work that way is JavaScript, which is… well… JavaScript.

Write Code for the Maintainer


            “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” This is somewhat connected to the previous rule. Usually, code is written once and then maintained for a long time. Even if your creations brilliantly fulfill the Open Closed Principle, and don’t need to be modified, still someone has to understand what should be added where to achieve desired result. Think of people who are new to the project and will have to update your code, can they easily do that? Will you be able to do that after a year? When I was working longer on single project I had situations where after finding myself in some strange and scary place I would thought “What kind of moron wrote this crap? Hmm… oh…  it was me a year ago…”. Don’t make me think too much. It hurts my brain.

            Also, Brian Kernighan once said: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it”. Keep that in mind.

Boy Scout Rule


            “Leave the code better than you found it”. Boy and Girl Scouts have the rule about camping, namely, they should leave it cleaner than they found it, meaning not only taking care of mess they made, but also of the possible mess they encountered originally. This translates directly to software development. When you arrive at location in code, make sure you don’t leave a mess, as well as try to take care of the mess you have found in the first place. This is a bit tricky. Firstly, you can fix something, spot another thing, fix it, spot another thing and fall into the trap of never ending cleaning further and further away from your camp. This is dangerous, since you stray away from your task goal and thus your sprint’s success might be in jeopardy. Secondly, it’s sometimes risky in legacy (nice word for “shitty”) systems. If you lack automatic tests and wander outside of the area of your task, which will be tested manually, you might break something without noticing. In theory IDE support for automatic refactoring of static language is quite impervious (but not always), however when technologies collide no one is safe. You might change an enum with all its occurrences in Java, but maybe there is a nasty JavaScript code that uses it recklessly on the frontend and boom! you are screwed.

            Boy Scout refactoring should be safe and small, and/or it should happen around the code you are working with. I remember the situation when I walked happily into my manager’s office saying “you know what, I threw away that crappy piece and written it from scratch nicely!” and instead of joy I saw grim face and heard “I didn’t ask you to do that…we have budget and stuff…”. I had to explain in details that I was building upon that change and I can deliver things faster now, and it was safe and good thing in general. If you spot a bigger refactoring opportunity outside of scope of your current task (say more than one hour of coding, depending on your team’s work agreement, deadlines, sprint tension and all such things), don’t rush into being good Boy Scout, ask your Product Owner if it’s okay and add it as a separate story to sprint. Remember, we are not here for the sake of art (unfortunately) but to fulfill our client expectations. We can shape those expectation too of course.


            Think before you commit. Do they know where you live? Should you be scared if they do? Don’t worry, stick with the dragon blog and you will be fine ;)

i know what you comitted

Leave a comment

Posted by on August 18, 2016 in Clean Code, Sweet Sixteen


Tags: , ,

Code of Principles

Entry 30

            Enough about recruitment, let’s get back to code. This article is (more or less)  going to be a continuation of Rock SOLID Code. I’ve talked about five principles forming letters in the SOLID acronym, now I’m going to talk about further set of well known (hopefully) programming (and not only) concepts.

(K)eep (I)t (S)imple, (S)tupid

kiss problem

            “Everything should be made as simple as possible, but not simpler.” Albert Einstein once said. KISS acronym was coined by Kelly Johnson, U.S Navy engineer in the sixties. Basically, simple thing doing the same job as complex thing is better. It’s easier to understand which means being less error-prone, easier to maintain, cheaper and more efficient. Always try to come up with simple and intuitive solution to the problem. Sometimes it might be more difficult than coming up with difficult one! There are people who are proud to invent overly complicated and “smart” solution that only they can understand. They should burn in hell. Every time when I see a class name containing “smart”, my inner warning light turns on. Why the author had to use word “smart”? Is there a nasty hack somewhere there? Is there a dirty non-standard solution? Does he need to prove that he is smart by constructing something incomprehensible to others? Where does he live if I had to track him down? Tick… Tock… Tick… Tock….

(D)on’t (R)epeat (Y)ourself

dry problem

            Every piece of knowledge must have a single, unambiguous, authoritative representation within a system as formulated by Andy Hunt and DaveThomas in The Pragmatic Programmer. Violation of this principle is called (W)rite (E)verything (T)wice, or (W)e (E)njoy (T)yping. The idea is that every piece of information in the code, be it data or algorithm, should be written once. This way we avoid verbosity, copy-pasting and risk of inconsistencies and errors. It is strongly connected with The Abstraction Principle which states that we should aim at finding common characteristics of fragments of code and abstract them, thus reducing code duplication. However there should be balance between avoiding duplication and over-complication of the system. I was once the developer who couldn’t stand looking at one duplicated line of code, and tried to abstract it as much as possible, which sometimes lead to overblown class diagrams or myriads of too small methods. But I’m cured now. There is also a rule, somehow relaxed, called Rule of three mentioned by Martin Fowler in book Refactoring, which says that code can be copied once, but if it is used three times, it should be extracted to separate procedure, class or whatever. There is no silver bullet here, use your judgement.

(Y)ou (A)ren’t (G)onna (N)eed (I)t

yagni problem

            “Always implement things when you actually need them, never when you just foresee that you need them” said Ron Jeffries, co-founder of Extreme Programming. It emphasizes writing as much code as needed to complete the feature or task at hand. In times of agile development, rapid prototyping and ever-changing requirement, it’s often risky to assume much about future. Expectations change, technology changes, ideas change, market changes. Sometimes you conceive a brilliant framework for your application that will take two months to develop and at the end turns out to be useless because client changed his mind, the scope got reduced or something similar happened. This doesn’t mean of course that you should dump creating elegant, abstract and flexible solutions over loathsome copy-pasted pile of crap. Just start simple, with what is needed to achieve goal of story or sprint, increment, refactor, experiment and shape suitable abstractions as complexity grow. That’s called emergent design, and it works providing you are disciplined to refactor stuff.

Minimize Coupling

coupling problem

            “Coupling is the manner and degree of interdependence between software modules” reads dear old Wikipedia. Loose coupling is desirable property of application modules, since it makes them easier to reuse, easier to test in isolation and less likely to break down after modifications. Introducing changes to tightly coupled systems tends to have a ripple effect, where new feature causes shitstorms (or solid-waste-atmospheric-disturbance, if you like) in random places, often remote from where the change originated (sounds familiar?). Often though reduction of coupling comes at a performance cost related to message transmission / translation / interpretation. Sometimes, for some critical points of the system, trade-offs have to be considered. You may think of low coupling of modules in high-level terms as good encapsulation. In modules, much as in classes, it’s good to hide implementation details and only expose clean and elegant interfaces.

Maximize Cohesion

cohesion problem

            “Cohesion measures the semantic strength of relationships between components within a functional unit” or, simply put, refers to the degree to which the elements of a module belong together. High cohesion is good, because it improves code readability. When stuff is where it is supposed to be, and fits well together with its neighbors, it’s easier to understand. Cohesive code is likely to be easier to reuse. There are several types of cohesion, going from the worst to the best: Coincidental, Logical, Temporal, Procedural, Communicational, Sequential and Functional. While coupling problems are easy to detect automatically via static code analysis, cohesion is much more elusive, subjective and difficult to assess, thus requiring human insight.

            That’s it for now. In the next episode I will continue the topic and dig into some less known and more informal principles of programming.



Posted by on August 11, 2016 in Clean Code, Sweet Sixteen


Tags: , , , , ,

Software Developer Interview: Your part.

Entry 29

            Now you will ask questions. Lots of them.

            As I have mentioned in the previous article, job interview is a symmetrical process. There are two entities – the Company and the Developer that meet in order to find out if they want to start a collaboration. The company will try to check if you have suitable skills, talents and how you handle different situations. They will ask you tons of questions. And you should do the same – carefully and thoroughly find out if the are suitable for you in each aspect you care about. Basically, you should have the same amount of time for your questions, as they had for theirs. Symmetry and honesty.


            When you have technical people in front of you, ask them as much as you can about the project you are going to participate in.

  • High level business overview as seen by developer.
  • Technical overview.
  • Technology stack and plans for it.
  • Legacy problems, and if present, how do they deal with them.
  • Software development process: do they have Agile? Scrum? Scrum-but? Waterfall?
  • Do they have Continuous Integration? Automatic tests? Deployment at the push of the button?
  • How do they host their stuff?
  • How big is the project? How old is the code and how many people worked on it?
  • What tools do they typically use? What IDE? Can you use your favorite IDE and tools?
  • Will you have the level of autonomy you want?


            How does your potential future office and workplace look like? Do you like it? Can you spend there 8 hours a day 5 days a week comfortably?

  • How big is the team? Is it distributed or sits in one room? How many teams are on the project?
  • What are you working on? Is it a laptop or workstation? Is it powerful enough? Does it have SSD drive? Will you be given two big displays? Or is it just a thin client to virtual machine hosted in another country? (good luck with that).
  • Do you have control over your computer? Can you install whatever you need for work? Or you have to wait for management approval for simplest and most obvious things?
  • Are there any restrictions in access to web pages? Will you have to wait 3 days until you will be given access to technical blog with information you need for work?
  • Can they give you tour around the office?
  • Do you sit in a room or in an open space? Or even worse, in “smart” office where you don’t even own your freaking desk?
  • Do you like view form the windows? (like, physical ones… you know)
  • Is there a dress code? Is it okay with you? If tech guys came to interview in suits, you should probably run (I would at least).
  • Is there a free / affordable, convenient parking space?
  • Suppose, you like to cycle or run to work. Is there a shower in the office you can use?
  • Is there a flexible approach to work hours? Can you work 6 hours one day and 10 on another one? Can you work 35 hours one week and then 45 hours another one? Can you leave office for 2 hours and later stay 2 more? Let’s assume that those fluctuations won’t interfere with duties to your project like meeting or deadlines, of course.
  • Is there free coffee / tea / milk other stuff in the kitchen? Some companies will even provide you free breakfast or lunch. That’s a nice touch and you can avoid queues to the “sandwich guy” or thinking about how do you not starve to death today.
  • Are there mugs, glasses, plates, cutlery, dishwasher, microwave oven? Place to sit?
  • Do they have physical library? Access to online libraries you would be interested in? Chill-out room? Fun room? Do you like to play table football with your mates? Do they have it?
  • Do they have displays with build status or other relevant stuff on the wall?
  • Can you order a package for the company address and have it handled by someone if you are unavailable to pick it up?
  • Is it software company or they just have IT because they “have to”?
  • Is it even technological company or are they working in totally unrelated field? Find out about how they truly perceive software development and if you are comfortable with that (feels like necessary evil? – run).


            Let’s talk money. There is a specific number regarding your salary, but there are a lot of other things to consider.

  • Are there any bonuses? What are the conditions and average numbers? A company offering lower salary but higher bonuses might overall give you more cash. But it might be tricky.
  • What are the other benefits? Sport cards? Private health care? Cinema tickets? Phone? Laptop? Car? Jet? (ok, maybe I’m aiming too high here, but you know what I mean)
  • Will the company pay for your certifications or external training if you need / want one? Will they pay for conference in another country and let you go in your work hours instead of forcing you to take leave of absence?
  • What kind of contract is at stake? Do you like to be an employee or one-man enterprise? Can the company offer you what you want?
  • How much time do you need to get to work? Remember time is money. An additional hour spent on traveling to office is equivalent of effectively being paid over 10% less per hour of your time and not getting any experience out of it.


            If you are interviewed by a person who is going to be your superior, you should make sure you will get along. Does this person have technical background? Or speaks only Excel? Ask questions to determine his / her behavior in certain situations and make sure you like the answers. I was once in an interview with a guy who was supposed to be my future boss and in the middle of it I knew there is no way freaking this is going to work. Some people just have a bad aura (or should not be allowed to manage anyone). Dump them immediately while you still can.


            Do you see yourself in this company in the future? Is there a path you can follow? Or maybe this company it’s just a step in your own path and you are not planning to stay here for long. It’s fine, just think what your expectations are and if they will be satisfied.

Final thoughts

            Yes, that’s a lot of issues, and some of them might sound silly, but we are talking about the place you are going to spend over a half of your awake time excluding weekends. You should feel good there in all aspects you can think of.

            Basically, if you decide to change job, don’t fall for the first or second offer you are given. Try to get several (perhaps 4 to 10 depending on how much time and determination you have) interviews in relatively short time (2 to 4 weeks seems to be reasonable). The list of question and issues I came up with is my personal preference, and things I care about. You might have an entirely different list. Just have the damn list! Prepare your questions, ask them, dig deeper, observe reactions, note answers, compare, prioritize, think. Sometimes you might want to call some company again to clarify something or to negotiate. Find out if you have colleagues or they have colleagues that are working / worked in the company you are thinking about. Talk with them. Research the online opinions about company, are they favorable?

            Sometimes it’s hard to come up with a verdict, so just try to trust your gut feeling.

Good luck!

software developer interview your part

1 Comment

Posted by on August 4, 2016 in Misc, Recruitment



Software developer interview questions: The soft part

Entry 28

            Soft is not a short from software here. In the previous article we went through technical aspects of Java developer job interview. This time we are going to explore the non-technical part or soft part or HR part or however you want to call it (it’s not just Java developer now, of course, but software developer in general). Sometimes you will talk with your potential team leader, project manager, line manager, other kind of manager, someone from human resources department or just a guy from dev team (hey, they can talk too!). They will try to find out if you will fit the organization, project or, in general, if you are the guy they would like to work with. I feel that developers tend to trivialize this part and think that if they are technically strong, nothing can stop them. However soft skills and personality plays a decent role in the recruitment process. After all, no one wants to work with an asshole, even if it’s technically brilliant asshole.

Up to the point

            So, I’m going to try to recollect these types of questions I’ve been asked on my recent interviews. As before, I’m not going to answer them, partly because I’m lazy and partly because sometimes there is no right or wrong answer.

  • Why are you changing job?
  • Name your three greatest advantages and disadvantages.
  • How would you describe your perfect workplace?
  • What do you expect from your future employer?
  • What motivates you?
  • Where do you see yourself in five years?
  • Describe a conflict situation you were in and how was it resolved?
  • What was your greatest fuckup in work and how did you handle it? (the choice of words may differ of course…)
  • How would you organize a newly formed team as a senior developer?
  • How would you react if your teammate is late with his tasks all the time and does private stuff or just nothing during work hours?
  • How would you convince me in one sentence that you are the right guy / gal for the job?
  • What do you know about our company?
  • Do you like to work in SCRUM? Why yes / no?
  • Imagine that at the end of the sprint a manager (or better: high manager) storms into devs room and demands some last minute feature to be included in the release. You know it’s too risky to do that, how would you react?
  • What software development book have you read recently and you can recommend?
  • How do you keep up with latest technologies, trends and stuff in the industry? What’s your main source of information?
  • Do you have some private software projects or contributions to open source? Tell me about it.


Some people in this part like to give you abstract questions, brainteasers or puzzles to solve or just to see how you would approach solution, how creative you are and if you can think outside the box. Some examples:

  • What can you do with a drinking glass? You got one minute.
  • How many golf balls would fit in a bus / this room?
  • How many gas stations are in this town?
  • How would you measure the height of [tall building name]?
  • Burning Rope Problem (how original…)


If you are not native English speaker, you will usually be tested for your language skills. Typically they will ask you to describe your work experience, talk about your hobbies, or perhaps answer some of the previous questions in English. You might want to review that too.

Is there more?

Again, internet is full of questions and answers.

Books I’ve mentioned in previous article are mostly focused on technical side, but some of them contain a “soft” section too.

Besides I’d like to point out one particular book relevant to the subject. The Clean Coder: A Code of Conduct for Professional Programmers by Uncle Bob, not to be confused with Clean Code (worth reading too).

The Clean Coder tackles software craftsmanship from different angle than Clean Code. It cover ethics, attitude, prioritizing things (not only backlog items), dealing with pressure, corporate bullshit, different types of difficult people and other stuff. Go for it.

At least one more!

I have at least one more recruitment topic I’d like to cover. We talked about questions you might be asked as developer, we should talk about question you should probably ask your potential future employer. They want to check you, you want to check them. Symmetry.

See you next time :)

interview soft part

1 Comment

Posted by on July 28, 2016 in Misc, Recruitment


Tags: ,

Java developer interview questions: The hard part

Entry 27

            Since I’ve attended several job interviews recently, I’ve decided to share some experience with you. Why hard part? Because this article is going to be about technical stuff. I’m going to write something about soft part later. Technical interview will probably look a bit different depending on your programming background. If you are new, expect more core language / programming questions. Later on emphasis probably shifts more towards your actual work experience, technologies, frameworks and practical problem solving skills. I’m not going to answer questions (I’m lazy), just provide list of topics you might want to review if you are going to a Java interview.

General object oriented programming / design core

  • Explain polymorphism, encapsulation, cohesion, coupling.
  • Difference between inheritance and aggregation.
  • What does “clean code” and “technical debt” mean to you?
  • Describe some refactoring techniques.
  • Explain SOLID principles.
  • Other principles like KISS, DRY, YAGNI, law of Demeter etc.
  • What design patterns do you know, explain some.
  • What design anti-patterns do you know?
  • How would you design an amphibious vessel / math expression evaluator / a dragon?
  • What sorting algorithms do you know and what’s their computational complexity? Which would you choose having some knowledge about the data you are given?
  • Write a code that:
    • calculates a factorial of given number
    • does a Fizz Buzz
    • inverts order of letters in words of given sentence.
    • checks if given string is a palindrome.
    • enumerates all permutations / variations of given set of characters

Java core

  • What is the contract between equals and hashCode and how it’s used in Java collections?
  • Describe Java collections, interfaces, implementations. What’s the difference between LinkedList and ArrayList?
  • What’s the difference between primitives and wrappers, where do they live, what’s autoboxing?
  • Where can you put keywords final and static and what do they do?
  • Access modifiers in Java.
  • Difference between String and StringBuilder / StringBuffer.
  • Difference between interface and abstract class.
  • Difference between overriding and overloading.
  • Types of exceptions and “handle or declare” rule.
  • How does garbage collector work?
  • How would you deal with memory leak / stack overflow problem?
  • How to make a class immutable and what’s the point?
  • What’s JIT compilation?
  • What’s new in Java 8 / Java 7? What’s coming in Java 9?

Hibernate / databases

  • What’s ORM?
  • Describe benefits and drawbacks of Hibernate.
  • Difference between Hibernate and JPA
  • What’s new in latest versions of Hibernate?
  • What’s lazy loading?
  • What’s N+1 problem?
  • Explain some Hibernate annotations.
  • What’s Hibernate Session and SessionFactory?
  • States of entity beans.
  • Cashing levels in Hibernate.
  • Transactions support in Hibernate.
  • What’s optimistic locking?
  • Describe ACID principles.
  • Describe database normalizations.
  • How would you approach to optimization of a slow query?


  • What’s new in latest versions of Spring?
  • Describe benefits and drawbacks of Spring.
  • What’s inversion of control and dependency injection?
  • What Spring modules have you used?
  • What types of dependency injection can be used in Spring?
  • What modes of auto wiring are available in Spring?
  • Describe Spring MVC.
  • Scopes in Spring.
  • Bean life cycle.
  • What’s the difference between Spring Bean and EJB Bean?

Miscellaneous topics

  • Explain Aspect Oriented Programming.
  • What’s the difference between GET and POST?
  • What’s the difference between web server, web container and application server?
  • Describe what’s happening in Java web application between entering an url in browser and getting the requested web page.
  • What’s a n-layer architecture?
  • What are the differences between microservices and monolithic applications?
  • What enterprise design patterns do you know?
  • How would you test an application? Different layers of tests. What testing frameworks do you know?
  • How would you test a single method?
  • What was the hardest technical challenge you’ve faced in your career?
  • What’s Domain Driven Development?
  • Name some important plug-ins for your favourite IDE.
  • Apart from IDE, what tools do you find essential for your daily work?
  • What version control tools have you used?
  • What’s the difference between branch and tag?
  • What tools for continuous integration / build / static code analysis have you used?

There is more

            As usual. I’ve tried to cover most typical for the interview. There are plenty stuff aside from core language and everything depends on particular job and your resume. Personally I’m not a big fan of strict specialisation and like to do full stack development from database to frontend, with maybe more bias towards backend. Most popular technologies around Java backend are now probably Spring and Hibernate, that’s why I gave them separate sections here. Most popular stuff for front end would now be Angular.JS and Bootstrap. But more on that later on.

            There is plenty information on the internet about “[technology name] interview questions”, go ahead and google what you need. If you like to hold a book in your hand, there are several on the topic of programming interviews, I’ve read three of them some time ago, you may find some useful stuff there as well:

            Good luck on your technical interviews! In the next episode we are going to talk about soft parts of software developer recruitment process :)

 java developer interview

1 Comment

Posted by on July 14, 2016 in Misc, Recruitment, Technology


Tags: ,

No-ip hosting

Entry 26

            So, I’m back after a longer while. As a warm-up I’ve decided to write about dynamic dns and why it’s interesting for software developers.

            Suppose, you want to write your own web applications at home, and present them to the world, but you don’t have a static IP address. A common scenario. Back in the days when I had my first broadband Internet access I didn’t have that problem, I had my own IP. So besides spending countless hours on playing Diablo II or WarCraft III. I was also playing with some PHP with MySql and building my homepage which I was proud to share (and nag people to create an account on it).

            Now, if I wanted to do something like that, I have basically two options: either I take the stuff to “The Cloud” meaning some external means of hosting, or I do it myself using dynamic dns service. The idea is easy – you setup an account on dynamic dns provider site, choose a subdomain and domain you like, download a client handling IP updates, forward appropriate (e.g. 8080) ports on your router and voila. You are a host now.


            I’ve tested the and it’s ok for me. You can use three domains for free as long as you log on every 30 days and click a button confirming you are still alive and avaricious, or you can pay and get more options. There are a lot of domains available, like:,, etc, so your final address might look like this: Of course, if you don’t want to expose that you are cheap, you can always get a top level domain and redirect it to your free ddns domain.

            So, it’s easy, its fast, it’s free. Any disadvantages? Some ddns domains are considered harmful. For example facebook won’t let me paste a address in chat. Second, if you want your app to be alive, your machine and server needs to be up. Third, exposing your network to the outside world like that may pose some security threats.

            That’s it for now. My pet project I’ve written a lot previously is on hold as for now, but I’m slowly planning to get back to it. Currently I’m experimenting with a few technologies and poking with  Endomondo rest api. See you next time, hopefully without such a long breaks.

p.s. here is your dragon, as always.

noip hosting

Leave a comment

Posted by on June 30, 2016 in Technology


Tags: ,

Software Craftsman: Professionalism, Pragmatism, Pride

Entry 25

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

Software Craftsman:  Professionalism, Pragmatism, Pride by Sandro Mancuso is the second book about the subject I’ve read recently. Thanks to Safari, even before the paperback edition is available on Amazon. Actually I had an occasion to attend the author’s talk on software craftsmanship at last Jax conference, but I’ve chosen in memory data grid which was probably mistake. Or maybe not, since we have everything on You Tube anyway.


The book came thirteen years after the one I’ve talked about earlier. It gives you a bit of history of the whole idea of software craftsmanship, books, articles, conferences, events and things like that. The basic ideas are described in similar way, to give you a good basic understanding, but there is much more.

A lot has happened in past thirteen years. We had an explosion of the whole Agile and Scrum thing popularity. Simultaneously almost no one does Scrum the way it should be done. Some people are at least aware they have ScrumBut (“you know, we have Scrum, but…”), some don’t. Anyway there is quite a lot of material in the book about issues with Agile transformations and what to do with it. There are several archetypes of problematic personalities like The Sceptic, The Evangelist, The Ivory Tower Architect and so on, and tips on how to talk to them to make things better.

A lot of attention is paid to the topic of management and recruitment of software craftsmen. I especially liked examples of good and bad job descriptions and the elaborate logic behind it. Sadly, most recruitment processes are far from being able to attract good programmers. They are done by people who just think in years and acronyms.

Also, importance of technical excellence is discussed. Some people tends to believe, that if they employ Scrum to their project, things will magically fix themselves and everything will be great. Bullshit. If you had mediocre programmers who produced crap, Scrum meeting, roles and artifacts won’t change that. You need to change the way software is written and thought about. Continues integration, tests, refactoring, striving for technical excellence and constant learning. Nothing comes for free, except coffee. If your company does not provide free coffee, leave it immediately.

Important message is, that craftsmen are not paid to work 9 to 5, do what is told them to do and go home. True craftsmen care. They are far more than just coders. They are there to help client achieve their goals. Through coding, motivating, organizing, sharing their knowledge and most importantly striving to make things better and transforming their organizations. They need to talk to their client, and try to understand what is really to be done. Unfortunately many organizations are stuck in previous era and not ready for this. There was a story about project that had a sole goal of bringing code coverage of code debase to 70%. It was off shored to different company, no one explained them any business logic and all the original programmers were to busy to talk. As it turns out, the reason for that is because some manager had a yearly goal, and fulfilling it gets him a bonus. So he fulfilled it blindly. Well, some people just need a hive five. In a face. With a chair.


I enjoyed the personal feel of the book. Author presents his American dream story (or British, in that case) of poor kid from Brazil who wanted to be software developer in London. Now he is the founder of London Software Craftsmanship Community. There are a lot of true stories from the trenches, which are lively, convincing and I had a feeling “hey, I had this one too… just like that”. For me it was much more enjoyable than Pete McBreen’s book.

Finally, do not expect that your employer will train you, educate you, buy you books or anything. If he does, that’s great, but this is your responsibility to learn, invest time, money, energy and passion to be good. You own your career. You shouldn’t pursue “career in an organisation”. You should pursue your own career. That’s your life, isn’t it? If organisation’s career map is not aligned to what you want, they way you want, simply quit. Don’t be afraid. Each job is just a step on the long staircase to mastery. Some are longer, some are shorter, lower or higher. Some will lead you down, not up. But it’s everything about the beauty of the journey. It’s not about catching the rabbit, but chasing the rabbit. Have fun!


Leave a comment

Posted by on December 7, 2014 in Agile, Books


Tags: ,

Vaadin Intro

Entry 24, Day 114

While being in the topic of web framework research: another one I’m considering to use is Vaadin. It has been around for quite some time, over 10 years now, so we can say that it’s mature (or “old”, if you like). Anyway it has large and active community, and is quite popular which is always helpful.


Vaadin is a server side centric framework, meaning that all content is rendered to html and passed to browser on each request. It’s a bit old school approach. Nowadays it’s more popular to keep as much as possible on the client side, mostly as Java Script and communicate with server only when needed. Vaadin guys argue that server side approach is safer, because it’s impossible to temper with the executable code.

There are other pros and cons, but what is important to me, that current version of Vaadin uses GWT as rendering engine. As you may recall from previous article I’m a big fan of GWT, since I believe that having all code in statically typed language under decent IDE control is a must for any non trivial web project (I’m yet to meet a happy Java Script programmer after successful and pleasant refactoring). But enough introduction, let’s get down to business.

To start easily with Vaadin I recommend The Vaadin Book. You can get it for free from Vaadin website (after registration, but still nice move). In short: get the Ivy and Vaadin plugins for Eclipse, then create new Vaadin project. To make things simple, you can ask the plugin to create project stub. We will rewrite it just a bit then to get something similar to what we had in articles about GWT and Spring.

In order to get things going we actually need only two classes. First doesn’t even have any code, just two annotations and a parent. It’s a Servlet class with a standard url mapping (this time as an annotation) and some Vaadin specific configuration to associate with GUI content class. Also, it extends VaadinServlet.

The content class needs to extend UI and implement init method where the page is created and hooked much like in GWT entry point. The @Theme annotation is optional, it provides us a default css and makes our button look nice. I’ve also added a Service class as our “backend”. Since everything is on server side, you don’t need synchronous and asynchronous interfaces, rpc mappings, callback and all that stuff. Just create class and call method (it’s an example, in real life you would want to have some dependency injection here). That’s all, deploy on server, run and enjoy your Hello World.


Comparing to pure GWT, Vaadin is much simpler to start. You don’t need any html to hook your Java code. You don’t need server communication handling. You don’t need module definitions in xml. You don’t need dev mode and all the acrobatics to debug client side code. The price is however page responsiveness. I’m not sure if it’s a high price though, keeping in mind an average modern bandwidth and latency. And you still keep all the luxury of not worrying if your method gets three Cats instead of two Dog it expects.

There is also a possibility to write client side code in pure GWT and integrating it with Vaadin but it pretty much brings all the GWT complications back.

Still better than JavaScript :)


Leave a comment

Posted by on November 23, 2014 in BookSentry, Technology


Tags: , , ,

Software Craftsmanship: The New Imperative

Entry 23, Day 107

The book by Pete McBreen is one of the early books on the topic. The analogy of software development and medieval craft were suggested before in The Pragmatic Programmer and earlier articles.

software craftmanship

When I got the book my first thought was “I expected this to be bigger” It has only 180 pages. And font is quite large. And a lot of almost empty pages. But okay, never mind maybe author is very concise.

Classical view on software development comes from software engineering applied to large scientific or government project in sixties and seventies. Those methods are in turn rooted in old school management where knowledge on how to do job well lies in managers heads while workers are not paid to think but to follow an optimal way of doing things. Reality is very different though. It’s the programmers who know how to do their jobs well. And in order to succeed in software project, the key things is to find excellent programmers with reputation and get out of their way when they start doing their job.

Author emphasizes importance of programmers strive for mastery and ability to stand behind their creation and support it. Because ability to deliver well crafted software builds their reputation. In such scenario, developers choose their project carefully as wrong client is recipe for disaster.

Also there is a lot about managing craftsmen. Junior programmers are overpaid while Senior programmers are much underpaid usually. Author states, that it’s much better to have a team of 5 masters and pay them as much as 25 or even 50 juniors, because overhead of coordinating the work is dramatically lower and if each of them delivered successfully many applications before, there is a good chance it will happen again. The product will have much higher quality, will be easier (= cheaper) to maintain.

So what about those poor juniors? Well it’s okay to have few of them, but not majority of them. They should learn not only from seniors but mainly from intermediate developers. And whey the gain some experience, they should pass it along to new joiners.

Managers should get accustomed to deal with subordinates who earns much more than they do, and the dumbest thing you can do to a master programmer is to move him to management because this is the only way to ramp up his grade and payment. If your organization has such a model, it’s probably time to say god bye and find someone smarter.

In general, the book presents a strong parallel to medieval craftsmanship model. There are apprentices, who study for few years to become journeymen. The wander from master to master to learn the craft in humility, gaining reputation and crafting better and better software. Andy finally they become masters if they persist.

It’s not silly to be developer your entire career. That’s what I thought five years ago, but now I see that it may be a good path for entire life. Did you know that an average developer has now only five years of experience? Industry is in deep need of people who are doing it for ten or more years, have vast experience and are willing to share it. Yeah, new frameworks and technologies are sprouting on a daily basis, but a lot of core skills haven’t changed much. If you are ambitious and plan to be developer for longer, this book will make you feel good, that’s for sure. Even though author tends to repeat himself and charges 30 bucks for not that much of a content, I think it’s worth reading. And then dropping on your managers desk.

Currently I’m reading another, much newer book on Software Craftsmanship by Sandro Mancuso, and Pragmatic Programmer is in the queue. I guess I will share some thoughts on them in the future.

Hiccup sharpening sword


Posted by on November 16, 2014 in Agile, Books


Tags: ,


Get every new post delivered to your Inbox.