Win a copy of Fixing your Scrum this week in the Agile forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Frits Walraven
  • Himai Minh

Five killer interview questions for developers

Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You’ve found a role that seems a great fit and passed the code challenge, now it’s time for the interview. Over the years the management team at Geektastic has hired hundreds of developers. In that time we’ve found there are certain types of interview questions that will get discussions going and allow a skilled interviewing team to see how much you really know and how you might fit in. If you’re a developer looking to prepare for your next interview, take a few minutes to look at the below:

1. Why did you make decision X in your code challenge submission?

The very fact you’re interviewing face-to-face means you passed the code challenge, the next step is to make sure you’ve come prepared with a rationale for the decisions you made and be ready to talk them through. “Oh, I wrote that? I don’t remember”, could lead to some difficult moments. While it’s unlikely you’ll be expected to write out perfect code on a whiteboard (many developers use IDEs and this is a reasonable mitigation for imperfect syntax), being able to justify your choices and the ability to rationalise and compare alternative solutions is particularly important in agile development teams.

2. What happens between you typing a URL into your browser address bar, hitting enter and seeing a web page?

This is an example of a broad type of question that could lead in any direction. You can talk about all sort of things: maybe DNS to start with – what are DNS servers? How do they work at a high level or a lower level? Lookups. Primary and Secondary servers. Caching. TTLs. Change propagation. DNS records. A records. CNAMEs. MX records. And that’s just DNS. We’ve not hit a load balancer or web server or app server yet.

Although “there is a DNS lookup that tells the browser the IP address of the server that will respond to this request” is a good starting point, skillful interviewers might lead you down one or two rabbit holes to see whether you know more than the bullet point. Thirty seconds into your response you might be onto TCP, HTTP, transport layers, SSL, certificate chains – who knows? You’re not expected to be Google and if the role involves building JavaScript libraries, a gap (or abyss) in your knowledge of transport layers is likely not going to kill your chances, but it’s always good to show that you know there’s more going on than just how much of the internet npm downloads when you build that 50 line JS file you’ve just written. If you are a JavaScript engineer working on client-side code, it would not be unreasonable to expect that you have some depth to your understanding of how a web browser works – since that’s effectively the platform that you’re writing your code for.

3. What are the things you should consider if you were writing your own database server?

Most software engineers, particularly those working with backend applications, will use data stores. But do you understand something more about the application underlying that nice GUI interface that you double click on? How would you write an application like MySQL or MongoDB or Neo4j? Questions like these could lead into general database principles such as ACID; SQL / NoSQL; different types of NoSQL; transactions; logging; file storage; blocking/non-blocking I/O; threading; indexing; sharding; query optimisers etc. As with question two, the interviewer is asking an open-ended question in order to investigate the bounds of your knowledge.

4. How does role Y fit in with role Z within the development team?

Many developer interviews will involve meeting lots of members of the team – in start-ups especially it’s not unusual to meet upwards of eight different people, all keen to check that you understand how your work will influence their work and how you’ll work together. Do your research, spend some time before the interview thinking about how the IT flow works in the company and demonstrate you have an idea of how the pieces fit together.

5. What working environment are you looking for?

Hopefully you’ve done some research and you know the company only has 10 employees or it has a development team of 150. If you’re moving from large to small or vice versa it’s probably good to show that you know what you might be in for. If you like a nice subsidised canteen and powering your machine down at 5:30pm, then a 10 employee company might not be for you. Be prepared to talk about the environment you’re expecting and how environments you’ve experienced in the past have worked. How do you see yourself fitting in? Do you understand how IT projects tend to work in smaller or larger development teams?

It may be obvious, but if interviewing at a startup, don’t make the mistake of thinking there are no rules. All smart businesses, no matter how laid-back and new, will want you to adhere to certain principles and take responsibilities for your choices. Similarly, a financial institution for example, will be looking for you to show you can follow strict protocols and understand how the work you’re doing is often directly quantifiable in financial terms for the business.

Some bonus tips:
Be curious about the technology choices they’ve made at the company. If they’re not explained to you, ask about them and don’t be afraid to question choices particularly if there are obvious alternatives.
If you’re not an expert on the subject matter of the role you’re interviewing for, it’s fine to say you’re interested in the technical challenges – just make sure you’ve thought about what those might be!
Don’t panic if you get the "how would you write a database server" question! Unless your interview is with a company that writes database servers, what is being assessed is your understanding of the nature of the problem and how you might approach it, rather than writing code.
And it goes without saying, it’s usually a bad idea to lead discussions into areas that you don’t know much about. Suggesting you know Python if you’ve only copied and pasted the Hello World example can go very badly wrong. One of the interviewers might have hidden expertise in an area that only comes out in interviews! One-upmanship is a character trait that is not exactly a rarity in developer interviews and if you’re starting from the Hello World position it’s best to come clean sooner rather than later.

We’re looking for amazing software engineers to join our team of uber geeks at Pass the code challenge to join our network and you can earn cash in your spare time by creating and reviewing other code challenges.
I don't like that guy. The tiny ad agrees with me.
the value of filler advertising in 2021
    Bookmark Topic Watch Topic
  • New Topic