First you prep. You have to remember reasonably well what you’ve done over the past 2–3 years, and have some self-awareness about what are your strengths, your weaknesses, what are your goals, what do you think of your career so far, where do you see it going etc.

This self-reflection should really happen naturally but if you haven’t taken a lot of time to do so, do yourself a favor and dedicate some time to this. It may help to actually write down your answers.

Now, in the interview.

How it works is that your interviewer is going to try to evaluate you according to 5–10 criteria. Those change company to company, and may be related to the engineering ladder, the values of the companies, etc. but not necessarily. That being said, there’s some commonality across companies, so it’s likely that things which are valued are: does this candidate care about results, are they a natural collaborator, does the candidate have a moral compass, etc.

Next, your interviewer is going to ask you questions, and each question is really an attempt to make you speak something directly about these criteria they care about. You want to answer to these questions just as directly as possible, using the memories of your last 2–3 years that you recently rehashed.

For instance, if your interviewer asks, tell me about a time you disagreed with someone more senior than you, well, you go back to your last 2–3 years of experience and fetch an anecdote where you did disagree with someone more senior than you. You don’t want to restrict your answers to stories where things magically went your way because you are so great. You can choose stories when you were wrong and acted upon getting feedback. Or when you two found a third way out of the confrontation. Basically, those would be stories where you used your skills as an engineer, not restricted to coding.

What you don’t want to do is one of the following:

• avoid the question. “I try to never be in a position where I would disagree with someone”. Not useful to the interviewer, and actually negative signal.
• answer the question with a non-work example. “I could bore you with something that happened with my director last year, but let me tell you about a time when I disagreed with my father.” Don’t do that. This is not useful to the interviewer. This means that whatever time you will spend with that story is not going to produce signal, that the interviewer can use to argue that the company should hire you, and you only have a limited number of opportunities to do so.

The more senior you go, the more you are expected to show that whatever they ask you is something you have previously thought about (because you most likely would have) and that the examples you choose confirm that you have the level expected by your interviewer.

First: What do you mean by "graphical applications"? Something with a graphical user interface (GUI), something doing graphics processing like 2d/3d animation renderer, graphical editors (e.g. something like a photo touchup tool), 3d/2d drafting, 3d/2d games, etc.?

Secondly what do you mean by "object oriented programs"? Were they written in the most common form of OOP, focusing on inheritance and polymorphism? Or the original object orientation idea regarding passing messages between object instances? Or is the program in modules acting like objects linking with each other? Or some combination of these?

In all of those OOP may very well be suitable, or it may not. OOP (as used mostly, i.e. hierarchy and polymorphism being paramount) is nothing more than a way to structure the code in some controlled hierarchy enabling some benefits for re-use, maintainability, scalability, multiple contribution, etc. while loosing a small bit of performance through things like virtualizing methods (i.e. instead of directly calling a function, first look up the correct one in a virtual function table). And also enforcing a bit of added boilerplate (i.e. programmer overhead). So in some cases this may mean it helps a great deal in making programs more robust, easier to understand and modify. But in others it may mean you loose performance and need to refrain from using such virtual functions (though this is pretty rare and only of essence if the program isn't IO bound).

I'd say that for most GUI apps OOP (common type) is a very good choice - it maps onto GUI elements pretty neatly. Even when looking at OOP messaging types this maps very directly onto event passing, so works well in this scenario too. Especially as GUI means the program is extremely IO bound - it would spend nearly all its time on waiting for user input - micro optimizing performance would have NO effect whatsoever. There are other alternatives, e.g. research of FRP (Functional Reactive Programming), but you'd most likely find that in most work environments when doing GUI you're also doing OOP (be that good or bad being immaterial).

Most of the rest of those program types tend to have more hybrid ideas. Things like rendering engines / image manipulation libraries are built to be extremely RAM and CPU efficient, but they may be mapped onto an OOP hierarchy for use from the program itself. Some may add modules as a form of addon/plugin, e.g. allowing specialized algorithmic materials in a 3d modeller/renderer, filters for image manipulation, using various rendering engines, etc.

OO has its roots in ADTs and a paper written by David Parnas in Communications of the ACM in 1970. The first OO language (although not called that) was Simula 67, an extension of ALGOL, where stack frames were made persistent by moving off the stack, hence becoming objects.

In the 1970s, Xerox PARC developed Smalltalk as a general purpose language, but it also drove graphic interfaces. Around this time Alan Kay coined the term ‘object oriented’. He now thinks he should have called it ‘message oriented’, since it is the interfaces to the objects defining the messages which is more important.

Apple did MacApp with Object Pascal, which it designed with Niklaus Wirth.

Thus OO has been tightly integrated with graphical applications, and it is ideal for that since it controls presentation of objects to the user.

Not at all.

There are many hard things I do. Broadly speaking, they are structural. How do I work with large, legacy code I don’t understand? How do I design cleanly split up software? How do I apply TDD to get good designs?

There are other common challenges, relating to concurrency, data access, networks, scalability.

I’ve had jobs such as games, where advanced 3D vector maths and physics was required. Not just the ability to code it, but the ability to research/figure out the equations themselves, code the maths libraries, then write the code.

But in terms of the kinds of puzzles and algorithms you describe, I’ve not had to design any.

My response to this is to not ask questions like that in the interviews I am part of.

And like others, I had to suffer rejection from a job pre-screen on some online test where I didn’t quite work out an algorithm in the hour allocated. Nobody even got back to me about that. Just nothing happened.

My view was that if that company absolutely requires that all developers can complete those kinds of tasks, then they made the right decision.

Otherwise, their interview process successfully screened out a 30+ year experience candidate, with good agile/TDD/SOLID skills across multiple languages and industry verticals.

I think this is a truly sad state of affairs in our industry.

Next headline: “There’s a shortage of X language programmers…”

The most import thing is to think about is: who is going to use the thing you create and how are they going to use it? If you don’t get that right, no one will care that it was a most elegant OO design (or what ever design paradigm you care for). They will either not use it because it’s awkward or will never buy it because it doesn’t answer their need.

End user don’t care much about what a great software design an application has. They care about a tool that does exactly what they need it to do. You don’t use the chainsaw to cut a wedding cake. It may be good for trees or brush. It may be the best chainsaw ever. But…

You get the drift. Think about your target user and what they want. If you don’t have a target user in mind, think about what you’re creating. Is it at all useful for anyone? Will people want this and what for?

As an engineering manager, this has never been a question I've planned to ask during an interview. The topic has come up once or twice in the last few years (and I've done a LOT of interviews in that time), but it's not something I ask to asses some technical or personal aptitude. Rather it's because I like my interviews to feel much more like a conversation between two people with similar interests.

One example of this topic was when someone mentioned experience of QBasic. That was interesting to me because that was one of my earliest experiences in programming. So we talked about that. All out of interest, and building a rapport with the candidate as well as helping them to relax.

In short, they're probably just showing an interest. Not every question during an interview is meant to assess a specific skill.

Software companies typically have a “framework” or a “ladder” that describes objectively what skillsets are required to perform at any given level. (Some of these companies make these frameworks public, see progression.fyi for a nice collection).

There is a lot of overlap between these. At Uber the 6 engineering competencies are citizenship, software engineering, design and architecture, execution and results, collaboration and creating efficiency.

An onsite interview typically has 5 rounds, 2 being coding, 1 on architecture, and 2 behavioral interviews. Coding rounds assess “software engineering”, architecture evaluates “design and architecture”, and so behavioral interviews score the non-technical competencies.

It’s pretty easy to rank candidates on how well they do on coding challenges. But that’s not enough to determine at what level a candidate should be hired. That’s the main goal of behavioral interview, they give much more signal to level the candidate.

At lower levels they focus on the attitude of candidates, whether they understand what's expected of them in a software organization or in a project context, how they navigate interpersonal relationships.

At mid levels interviewers expect more autonomy from a candidate. Candidate should be able to demonstrate they have worked on hard problems, have experience mentoring, have influenced the organizations they work in. Interviewers also start to factor in more heavily the candidate communications skills who should be able to express their thoughts clearly.

At higher levels candidates need to establish leadership and show they can engage an organization and effect change at a high level, how they can work with folks across organizational lines, identify large scale problems and tackle them. Candidates should not just be able to describe their experiences clearly but also show that they have developed a philosophy, a thought system about the work they do.

With that in mind, what are tips for behavioral interviews?

• self awareness. Candidates should recall in detail their past work history (or equivalent, college etc.) especially the recent years. They should have in mind the difficulties they faced, especially in working with others, but also what they have accomplished. Anytime a candidate is free to collect their thoughts rather than answering immediately a question but actually this is always detrimental. Having a ready answer to any question is a huge advantage, as is being able to dive deeper into any story.
• have the large picture in mind. Remember the purpose of the behavioral interview is to level the candidate especially on non-technical skills. Behind most questions there is a thin-veiled attempt to grade the candidate on one of the dimensions of the engineering ladder of the company. Don’t think outside of the box or try to outsmart the question. For example to the question: tell me about one of your accomplishments? every so often, candidates insist to talk about a non-work accomplishment. By so doing they miss an opportunity to prove that they are good on the things we care about in a work interview!
• The best way to practice is to interview candidates. Interviewing candidates gets you a whole range of perspectives and make you reflect on your own trajectory and as a result make you much stronger as a candidate.

Some do.

I do, though mostly indirectly, through test automation.

My job primarily focuses on testing weather mapping software, which is a graphics technology. My colleagues (the developers) build that software using tools including WebGL and React.

The most obvious software engineering roles with a relation to graphics are game developers, graphics firmware developers, and rendering application developers. These software engineers typically require an advanced understanding of how the graphics rendering process works.

But I’ve also worked on projects where there is no graphical component, on APIs and databases which send raw data to other applications. Some of the software engineers I worked with on those projects had no experience in designing or building graphics applications.

This is for software developer role. Based on the resume, I would frame the questions to understand the following,

1. Knowledge/Proficiency in Test Driven Development.
2. Writing a code in different language/tools/environment. Probe to get examples from his/her previous work for this(Warming up to the idea of coding in different platform alone won’t be sufficient).
3. How would you estimate a typical feature request?. Candidate can pick her/his own example.
4. What are the questions she/he would ask about the project on her/his 1st week(Assuming no or very minimal introduction is given but a work is assigned)?.
1. Following questions are expected, not in any particular order..
1. Is there a Project Plan & What is the planned completion date and are we on track?.
2. Do we have a documented consent/approval for the scope & work so far?.
3. What are the unknowns/dependencies that affects my deliverables?. Who depends on my work?.
4. What is the escalation/warning process/mechanism if something don’t work or goes wrong?.
5. Where is Requirement Specification and/or Technical Design document?.
6. Are there any coding guidelines ?.
7. Is there a dedicated testing team?. Do we have use cases/test cases available?.
8. Who is authorised/empowered to make what decision?.
5. If no guidance/expectations set, what are the status updates he/she would send to her/his boss or customer?. What details would be in such status?.
1. A status update is expected to answer the following questions but it must be based on the need.
1. “# of days/hours behind Schedule or On Schedule”, Then percentage of work completion.
2. List of risk/dependencies that affects the schedule or cost. (This is to avoid unpleasant surprises)
3. Upcoming milestones or anything that needs attention.

I find coding skills are often exaggerated. These days with stack overflow and with colleagues help, almost anyone can complete a coding work. But it is the other things such as “Requirements, Priority of features, Cost, Who uses the software and how (much) it is used..etc” are determining the true value of a software. It is like running in a treadmill. If I keep running hard, I will get fit but won’t move from point A to B. Sheer coders without these other skills are like those treadmill runners. Another anology is of a car. A good engine(coding skill) is nice but without Steering & Brakes the car is useless.

Doing right software is more valued than doing the software right!.

I am a software engineer but also a 3rd-year physics major. I have been fascinated by the intersection of both fields. I am also very interested in graphics. Here are some areas of math I’ve found useful for graphics.

• Linear Algebra is the most important.
• Transformation matrices: Used for scaling, rotation, translation, and projection of objects in 2D and 3D space.
• Vector operations: Manipulating points, vectors, and normals.
• Matrix operations: Multiplication, inversion, and determinant calculations for transformations and coordinate systems.
• See this video as an example.

• Geometry
• Euclidean geometry: Understanding concepts such as lines, planes, angles, distances, and intersections.
• Parametric curves and surfaces: Used for representing and manipulating shapes like splines, Bézier curves, and NURBS.
• Non-euclidean geometry e.g spherical and parabolical are sometimes used in games for crazy effects.
• Trigonometry
• Trigonometric functions: Understanding angles, rotations, and periodic behavior essential for rotations and transformations.
• Trigonometric identities: Used for solving geometric problems, interpolation, and shading calculations.
• Coordinate Systems
• Polar, Cartesian, Cylindrical, Spherical
• Probability and Statistics
• Monte Carlo methods: Used for approximating complex lighting, shading, and global illumination effects.
• Sampling techniques: Employed to simulate complex phenomena like motion blur and anti-aliasing.
• Calculus
• Derivatives: Used for calculating gradients and rates of change, essential for simulations and shading.
• Integration: Used for tasks like numerical integration for rendering algorithms and physics simulations.
• Euler Integration and Verlet Physics are used in many game engines to change the position of a body over time.

Don’t be scared by the sheer volume of this.

Start by watching the coding train channel on youtube. It will guide you on how to start.

I write on medium at

My newsletter

I do it all the time. First, and most important step: UNDERSTAND THE PROBLEM. If you’re working with a client then speak with them about it the REALLY UNDERSTAND what is being asked of you. If you’re part of a technical team then you may have to trust your program manager, but ask questions and get as much information as possible. It’s then a matter of designing a solution. Are you using technology you understand? Then start breaking the task up into smaller tasks. If it’s an unfamiliar technology, find people who will share their expertise. Don’t just start coding; think through the solution and ask more questions. Once you start coding there will be more questions. Do you notice a theme? Communication is vital and once you present your solution it will feel great. Best of luck!

What Software Engineers Should Know About Computer Graphics

Software engineers should understand the fundamentals of computer graphics to develop visually appealing and efficient applications. They should grasp concepts like rendering techniques, shading algorithms, and image processing to optimize graphic performance. Familiarity with graphics libraries and APIs such as OpenGL and DirectX is crucial for creating interactive and immersive graphical experiences. Additionally, knowledge of vector graphics, rasterization, and color theory enhances their ability to design engaging user interfaces and visualizations. For a user-friendly introduction to graphic design, try CorelDRAW Graphics Suite, offering powerful vector illustration and photo editing tools.

Same as any field of endeavor:

1. “Do I want to to do it?”
   If yes, good so far. If not… Why are we talking about this??
2. “Do I have an aptitude for it?”
   There’s an old saying: “Many are called, few are chosen.”
   Just because you want to do something does not mean you can. (I’d be thrilled to be a pro-level cyclist—I am not! And I never will be!!)
3. “Am I willing to spend hour after hour, day after day, week after week, month after month and year after year honing my knowledge and skills?”
   If yes: Congratulations! You may attempt to become a software developer.
   If no: Please do not bother those of us who are seriously trying to advance software technology.

That’s pretty much the definition of “correctly” - so yes!

But “correctly” and “run without problems” are kinda slippery terms.

You can argue that “correct code” is that which adheres to the language standard - so if your code compiles without errors, then it’s a “correct” program as far as the programming language standard is concerned. By that standard then there is a guarantee that the code will do what you told it to do. But if you wrote code to calculate Pi and your function says: “return 3.0;” then this linguistically correct program has a rather serious flaw in it.

In truth, we cannot write code that its perfectly “correct”. It’s absolutely certain that any program of any significant size has bugs in it. Sure, you can write little ‘toy’ programs of maybe 1000 lines that are perfect - but once you get into the realms of 10,000 lines, 100,000 lines or more - bugs are absolutely, 100% certain!

Even when you put in place the most rigorous possible testing and QA procedures, there WILL be bugs in very large programs.

How robust?

Look up “clean room engineering” R.C. Linger for a good solid technique. In short, use logic to clarify the preconditions, the side effects and the post-conditions for each statement in your code. Each function will then end with a set of post-conditions that are guaranteed by that function’s code.

This is nearly impossible to do in practice unless you use “Functional Decomposition” (where were you in ‘82!) and that is almost impossible to do for any normal/large sized system unless you use solid Object Oriented design techniques, especially encapsulation (look up SOLID).

Code in vertical slices, not by layers. Write the smallest bit of the UI. Write all of the support code needed to get that bit of the UI to work. (versus writing all of the low level code, then the middleware, then the GUI). Then add the next slice.

Think in terms of “services”. This is an overused term, but think of it as a top level pillar that handles a suite of behaviors, e.g. the communications service handles all communication to a device or a server, the protocol service handles all the commands and responses sent to the device/server via the communications service. The Controller (of MVC fame) will then just communicate at a high level with a suite of services.

Work out not only the overall system architecture but also the “micro-architecture” i.e. how do the big chunks of behaviors fit together, but also how do the smaller pieces fit together? Refactor as needed as you discover how the top level code has to work.

Use automation E2E testing to confirm these top level pieces work together well. This means that you will be writing code to be testable. This will almost always force you to use very tight OOD techniques especially single purpose and encapsulation i.e. each service presents a very clean, very well defined interface to the outside world

Finally don’t try to figure it all out by yourself. Use code reviews. Use lint.

in summary, this will work:

• use small, completely encapsulated classes, each with a single purpose
• have all of the OO methods in that class be singular and tiny.
• Ensure those methods are single purpose and tiny.
• Use logic techniques to do this for each method:
• clearly state and ensure the preconditions for the method e.g. either use guard clauses or asserts
• clearly specify the expected side-effects
• clearly specific the expected post-conditions
• use unit tests to double-check all of this at a class level
• Use services to break up the top level behaviors
• use automated E2E tests to confirm it’s good at the upper levels
• use static analysis tools to help find code smells
• use code reviews for an additional double-check

I don’t think programming interviews should be pop-quizzes

It irritates me that a position that should be focused on actual problem-solving has been relegated to evaluating talent like they are highschool students in an english class.

What should software engineering interviews test for?

• Conceptual and terminology understanding - Depending on position a loose or specific knowledge of a task, toolsets, or coding standard may be required but ultimately you just want to know “can this person work the way the rest of our team works using tools our team knows or would like to embrace going forward?”. My current job asked me about my perforce and git experience and those are daily relevant tools that are valuable to my specific role.
• Understanding related to daily tasks - If they aren’t writing string reverse parsing functions on the fly daily then taking the limited time you have to evaluate them to ask them to do just that feels wasteful. Ask them to write a simple script doing something you do a lot in your work . At one of my companies we worked with car data daily, an effective test would have been showing them a webpage and asking someone to write a basic class encapsulating all the various car data we were working with, what data they’d choose to exclude, what data they would choose to pick, ask them to make a small interface that allows them to navigate and display the data . That was work relevant, simple enough to determine style or lack of, and allows you to give them a simple resource to determine their problem solving approach . All stuff we did daily and anyone joining us should be able to do.
• Communication skills - I think all of us have worked with someone brilliant who could not articulate what they were doing or desired and THAT is extremely frustrating because they can deviate or drive the project in a direction that puts your organization in a hard place to climb out of and the rest of the organization may not even understand it’s happening! Does the person interviewing understand how to take their goal and your value as a stakeholder into consideration? Are they open to questions , can they tell you the intended direction or goals they are trying to achieve and how they’d achieve them ? If you can’t communicate with them to accomplish a simple task is it realistic that you can learn to communicate with them when you assign them more complex tasks? Do they have respect for other departments ? Are they someone who will upset other stakeholders ? Poor communication is just as bad if not worse than poor code , a poor communicator is often a great culprit for unrealized technical debt later on
• Behavioral - It’s hard to lead someone who won’t take your direction no matter how brilliant they are. When you ask them about past projects and failures was everyone else in the room the culprit always ? Are you one of their future problems if you hire them ? How do they respond to adversity ? Some people check out when the pressures on and others lock-in , the last thing you want is someone who can’t be found when you need all hands on deck. Do they know how to manage their “ professional voice “ ? It doesn’t cost anything to be courteous and respectful even in disagreement . Can they learn? Do they mind learning ? Do they hate anytime the work deviates from their predefined desires? Tech is constantly moving the last thing you want to do is hire someone who is going to oppose change Day 1.

Look I understand tech interviewing is hard, understanding people and how they fill a role in a larger organization is hard! Add onto that you only have a few hours to determine if someone is worth a high 5 or 6 figure salary and of course throwing a problem at them and letting that determine their value offloads the responsibility and complexity of being marked as the responsible decision-maker in the case of a bad hire.

However I am deeply dissatisfied with what the current tech interviewing landscape is . I think it prioritizes people who can stomach looking at the same exact series of problems multiple times and survive studying extreme repitition with little to no creativity needed and in my professional experience software engineering can change DRASTICALLY from day to day. This week at my day job I had to write code that changed the naming scheme for exported assets, yesterday i finsished writing a consumer facing introductory tech document, and the day before that I put out a fire that on our project was outputting video assets at the incorrect frame rate in specific locations in our app .

I think the role of a software engineer is quite dynamic and requires understanding and being able to not just build according to your own vision but the vision of others as well. I wish more tech interview prioritized trying to search for and understand these factors in tech talent.

Imagine you bought a new car and drove it home. You drove it every day for a week. No problems. The following day, you cannot drive it because overnight, the road has narrowed down to 2 feet in width.

Situations like this happens with software ALL the time. No matter how meticulously written, there is a very strong chance that the software would have to be re-written very soon. Either the OS would change or the requirements would change or some underlying technology would make your software feel like a snail on Valium.

I once met a guy who wrote a crew scheduling software for an airline. He told me that they had to make major changes every year to comply with the latest regulations, company policies and the new crew contracts. Add in the moving technology and new reporting ideas people came up with and it was like they were in development mode ALL the time.

I’m assuming that a “good software developer” is someone who has at least some professional experience.

1. Tell me about a time where you either failed outright or were so stuck on a problem you weren’t sure how to proceed. (If a candidate tells me they’ve never failed or have never been stuck on a technical problem the probability that they’ve worked on anything of interest is slim)
2. Tomorrow the team needs to come up to speed on technology X as quickly as possible. What is your process for learning new/challenging technical material quickly? Can you give me an example of when you’ve had to do this?
3. What is your favorite programming language? Why? (This seems like a simple question but is fraught with potholes. Do they understand that their favorite language isn’t necessarily the best language to use for problem X? Are they married to a given language/technology? Do they understand language design at all? Do they understand how manual memory management works? If not, do they understand why garbage collected environments aren’t meant to be used in all situations? Etc.)

1. Understand the problem. Without understanding the problem you will often waste time going down the wrong path and making code iterations that are not meaningful. In an agile/SCRUM process this happens in grooming and it’s why the grooming and pointing steps are so important.
2. Visualize your outcome. What is this thing suppose to do in the end?
3. Do your test cases. You can only make valid test cases if you know 1 and 2. When you’re done you should have a set of unit/integration/behavioral tests that reflect your understanding of the problem. Test Driven Development (TDD) reflects this as a discipline. While TDD seems tedious at first the reason it accomplishes tasks faster is that it helps minimize wasted time and effort. That said I’m not the strictest follower of TDD but I do acknowledge cases where it would have saved me time if I was.

Readable code is a symptom of clear thought and understanding of the problems to be solved. Conversely, unclear code reflects the unclear thought process that is still wandering around looking for a solution.

Remember that when you are coding, you are communicating with the computer and with other humans. Use meaningful names that are unambiguous. Code small units that have small numbers of elements to keep track of.

Write consistently, using the subset of whatever language you are using that gets the job done, in a consistent style.

Clear thought makes clear code.

Clear, consistent requirements are essential for clear code.

A good programmer wants the right things. Clarity is one of those things.

Fundamentally, the most important question is simply this: What do I want the computer to do for me?

The answer is purposefully vague and drives the asking of all other questions. E.g. I want the computer to edit pictures. Okay, how will the picture data be represented? What size pictures can be supported? Which color models? What editing tools and processes are useful? How should the user access them? etc. etc.

It's all about defining your terms. The more you know what you want, the better it will go.

The computer is a mental construct. The questions you ask of it are the questions you are really asking of yourself.