Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

What Facts Should Be Resident in a Developer’s Head?

DZone's Guide to

What Facts Should Be Resident in a Developer’s Head?

How much implementation details should a developer remember when going for an interview? Should you remember whole algorithms by heart?

· Agile Zone ·
Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

I just finished reading this reddit thread about a guy that cheated to get a job (the original post doesn’t really shed a good light on anyone there) and the comments related to that.

That got me thinking about our own interview process and what kind of things I expect people to have in their head, for interviews, but also in general. In particular, this comment:

Honestly, I wouldn't hire someone who couldn't code a search or sort algorithm on a whiteboard and tell me how e5fficient or inefficient it is.

Another example I heard of in a conference is literally examining people on Knuth. To the point where you didn’t know chapter and verse for Oscillating Sort (literally, in what chapter is that covered), for example, you are obviously worthless and there is no point in continuing in the interview process.

For myself, I don’t think that I bother keeping any actual details about algorithms in my head. Much more important is to know about the algorithms and to be able to have just enough information to recognize that it might be a viable option for my use case and then read up on the details.

In interviews, and in their work, I would expect people to know about big O complexity and be able to tell what kind of complexity a specific piece of code had, as well as whatever this was good or not.

As for implementing a sorting algorithm, I remember some of the details on how quicksort works - but actually writing that from scratch? There are far too many details for this to actually be a viable option.

For example: 

  • Lomuto or Hoare partitioning?

  • What about the choice of pivot?

  • How about parallelism?

  • How do you handle repeated elements?

I just pulled those from the Wikipedia page, mostly because I remembered this post about how to answer such interview questions.

Implementation details shouldn’t matter (beyond understanding costs & complexities), so they shouldn’t take up valuable mental space in your head - that is why we can search for that. The important thing is that you know that you need to look up additional information, as well as know how to do so.

Do you pay to use your database? What if your database paid you? Learn more with RavenDB.

Topics:
agile ,interview ,developers ,algorithm ,career

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}