Programming, graphics, games, media, C++, Windows, Internet and more...
Entries for tag "career", ordered from most recent. Entry count: 5.
# Most frequent questions on programming job interviews
Thu
29
Aug 2019
There are different questions that appear on job interviews. Good preparation to such interviews is an art on its own, just like making a good CV, and there are whole books and trainings about it. A potential employer usually asks for details of what is in your CV - your past experience (especially previous 1 or 2 jobs) and why did you leave your previous job. He may ask you to solve some algorithmic puzzles to test your general “intelligence”. He may even ask some ridiculous questions like “Try to estimate how many litres of paint is used every year to renovate buildings in London?”, believing that your response and your way of thinking will be some estimate of whether you will be a good employee. But most of the interviewers also ask some real, technical questions, checking your knowledge from the domain you will work with. Out of these, I observed few questions occurring most frequently. Here they are, together with a draft of the correct response:
1. About C++
1.1. What does inline keyword do? Answer: It means the function should be inlined by the compiler in each place where it is called instead of leaving the function call in the compiled code. It’s only a hint, modern compilers decide which functions to inline on their own.
1.2. What does virtual keyword do? How does it work? Answer: It lets you implement polymorphism when using class inheritance. When an object of a derived class is passed by a pointer or a reference to a base class, calling such a function will call the version from the derived class - the one that the passed object “really is”. It works thanks to each object having an additional, hidden pointer to the virtual function table, which dispatches calls to such functions to the appropriate version.
1.3. What does volatile keyword do? Answer: It tells the compiler that a variable marked with this modifier can change value out of its control (e.g. by a different thread, operating system, or hardware) so it should not optimize its access by caching its value in CPU registers, assume it won’t change for some period etc., but use it in its original location every time. Side note: This keyword is rarely used. It probably appears more frequently on job interviews than in a real code :)
1.4. What does mutable keyword do? Answer: It allows to change a class member variable marked with this modifier even if the member function and the current object is const. It might be useful e.g. to perform lazy evaluation - object is passed as const& and appears to be unchanged, but its methods GetSomething() calculates and caches the value of “something” on first call. Side note: This keyword is rarely used. It probably appears more frequently on job interviews than in a real code :)
2. About general programming
2.1. What is the difference between process and thread? Answer: Process is launched from a particular executable file. It has its own address space (memory heap is common for the whole process), handles to open files, network sockets etc., separated from other processes in the operating system. It comprises a main thread and may have several additional threads. Each thread shares the same code and memory heap, but it has its own stack, instruction pointer (the place in the code currently executed), and values of CPU registers.
2.2. What is a mutex? Answer: It’s a synchronization object that allows multiple threads to access a common resource safely. If only one thread can access the resource, the code accessing it (called a critical section) has to be surrounded by locking the mutex above it and unlocking the mutex below it. Then only one thread will be able to execute that code in any moment. Other threads have to wait.
2.3. What is a deadlock? How to prevent it? Answer: Deadlock is an error in multithreaded code occurring when two or more threads wait for each other and will never make progress. To prevent it, always remember to unlock your mutexes (even when doing early return, break, throwing exception etc.) Also, when locking multiple mutexes, always lock them in the same order, never like: thread 1 locking A then B, thread 2 locking B then A.
3. About graphics programming
3.1. Describe graphics pipeline in modern GPUs. Answer: Depending on how detailed you want to describe it, you can tell that data is processed through following stages: vertex fetch / input assembler (fetching vertices/triangles) --> vertex shader --> optional tessellation (hull shader aka tessellation control shader --> fixed tessellator --> domain shader aka tessellation evaluation shader) --> optional geometry shader --> triangle clipping and culling (incl. viewport culling, backface culling etc.) --> rasterizer (converting triangles to pixels) --> pixel shader aka fragment shader --> depth-stencil test --> writing to render targets with blending.
3.2. What’s the difference between forward and deferred shading? Answer: In traditional forward shading, each object is rendered already shaded by each affecting light. In deferred shading, objects are rendered only once, with their parameters stored in intermediate render targets called G-buffer - like albedo color (taken straight from color texture), normal, depth (allows to reconstruct full position), material parameters (like roughness and metalness in case of PBR). Then separate screen-space passes use these data to apply shading from particular lights. One could say forward shading has complexity of O*L, where O is a number of objects and L is a number of lights, while deferred shading has O+L, which is better for a large number of lights. But deferred shading has its drawbacks: heavy G-buffers consume lots of bandwidth, the algorithm doesn’t work well with translucent objects, MSAA, or using different materials.
There are many more questions you may meet on programming job interview, whether from the topics described above (e.g. from advanced C++ - what is RAII, what is SFINAE), or any other topics important for a specific position, but from my experience those mentioned above are especially frequent, so preparing good answers to them may be the best investment of your time before the interview.
# Remote programming job is usually not an option
Fri
10
May 2019
Every programmer these days receives lots of job offers from recruiters, especially if having profile on LinkedIn. Some people make fun of it. I used to ignore or reject them, telling that “sorry, I’m not looking for a new job at the moment, I’m happy with my current one”. For some time I started to do something different - I tell them that I’m not interested in relocation to California/London/Germany/Iceland/South Korea/wherever and ask if I can work remotely. The answer is usually “no”.
This is contrary to a popular belief that programmers can often work from home. I have a remote job now, but this one is unique and I know such job is hard to find. Maybe it’s more frequent when someone develops web pages, mobile apps, or other small programs that a single person can make. A freelancer hunting for specific projects and tasks may have an opportunity to work from anywhere in the world. But if you want to work in a team of many programmers developing a large and complex project, they usually expect you to be full time on site.
You can come from any place in the world and have a great coding talent. You can study solid computer science at your local university or even learn by yourself from the Internet. But it’s unlikely you can make a world-class career or take part in state-of-the-art, innovative projects while staying in your small home town. For that you have to move to one of these technology hubs, like Silicon Valley. This is despite the developments in telecoferencing, Skype, Slack, etc.
Here are screenshots of 12 chats I had with recruiters on LinkedIn since the beginning of this year. I told them I don’t want to relocate and asked them if I could work remotely. 11 of them said “no”. Only 1 said it’s possible.
# Iteration time is everything
Thu
06
Sep 2018
I still remember Demobit 2018 in February in Bratislava, Slovakia. During this demoscene party, one of the talks was given by Matt Swoboda "Smash", author of Notch. Notch is a program that allows to create audio-visual content, like demos or interactive visual shows accompanying concerts, in a visual way - by connecting blocks, somewhat like blueprints in Unreal Engine. (The name not to be confused with nickname of the author of Minecraft.) See also Number one / Another one by CNDC/Fairlight - latest demo made in it.
During his talk, Smash referred to music production. He said that musicians couldn't imagine working without a possibility to instantly hear the effect of changes they make to their project. He said that graphics artists deserve same level of interactivity - WYSIWYG, instant feedback, without a need for a lengthy "build" or "render". That's why Notch was created. Then I thought: What about programmers? Don't they deserve it too? Shorter iteration times mean better work efficiency and higher quality of the result. Meanwhile, a programmer sometimes has to wait minutes or even hours to be able to test a change in his code, no matter how small it is. I think it's a big problem.
This is exactly what I like about development of desktop Windows applications and games: they can usually be built, ran, and tested locally within few seconds. Same applies to games made in Unity and Unreal Engine - developer can usually hit "Play" button and quickly test his gameplay. It is often not the case with development for smaller devices (like mobile or embedded) or larger (like servers/cloud).
I think that iteration time - time after which we can observe effects of our changes - is critical for developers' work efficiency, as well as their well-being. We programmers should demand better tools. All of us - including low-level C and C++ programmers. Currently we are at the good position in the job market so we can choose companies and projects to work on. Let's use it and vote with our feet. Decision makers and architects of software/hardware platforms may think that developers are smart, so they can work efficiently even in harsh conditions. They forget that wasting developers' precious time means wasting a lot of money, not to mention their frustration. Creating better tools is an investment that will pay off.
Now, whenever I get a job offer for a developer position, I ask two simple questions:
1. What is the typical iteration time, from the moment when I change something in the code, through compilation, deployment, application launch and loading, until I can observe the effect of my change? If the answer is: "Usually it's just a matter of few seconds. Files you changed are recompiled, then launching the app takes few seconds and that's it." - that's fine. But if the answer is more like: "Well, the whole project needs to be rebuilt. You don't do it locally. You shelve your changes in Perforce so that build server picks it and makes the build. The build is then deployed to the target device, which then needs to reboot and load your app. It takes 15-20 minutes." - then it's a NOPE for me.
2. How do you debug the application? Can you make experiments by setting up breakpoints and watching variables in a convenient way? If the answer is: "Yes, we have debugger nicely integrated with Visual Studio/WinDBG/Eclipse/other IDE and we debug whenever we see a problem." - that's fine. But when I hear: "Well, command-line GDB should work with this environment, but to be honest, it's so hard to setup that no one uses it here. We just put debug console prints in the code and recompile it whenever we want to make a debug experiment." - then that's a red light for me.
Comments | #career #tools #philosophy Share
# New Job at AMD
Mon
24
Apr 2017
It's already 3 months after I started a new job, so I think I can write something about it. Before that I've spent last 5 years living in Gdańsk and working at Intel. I've been developing shader compiler, which is part of the driver for Intel integrated GPU-s.
Now I moved back to Warsaw and I work at AMD. My position is called Developer Technology Engineer. (Other name is SMTS Software Developer Engineer - Senior Member of Technical Staff. You can find my colleagues on LinkedIn specifying one or the other.) This job is quite different. I'm responsible for cooperation with game development studios to make sure their PC games work well on AMD graphics cards. On the other hand, it's similar in the way that I still work with native C++ code, graphics APIs (like DirectX, Vulkan), shaders, and low-level GPU stuff, yet it's not a work strictly in the game industry - so a very unique position.
# Pixel Heaven 2014 - My Impressions
Tue
03
Jun 2014
31 May - 1 June I've been in Warsaw on Pixel Heaven. As I haven't been on previous edition, I didn't really know what to expect. Timetable was full of various activities - lectures, competitions or just opportunities to play some games. Would it be only about retro games, or also modern games? Only about indie games, or AAA games too? Is it more for gamers, or for professional game developers? What about demoscene? Either way, I decided to go there.
I'm not really into these retro platforms, so I planned to go listen to lectures about indie game development. I've seen and heard many interesting stuff there, like Adrian Chmielarz from The Astronauts presenting their game - The Vanishing of Ethan Carter - for the first time!
But as it turned out, I met so many interesting people there (some of them I haven't seen for years) that I've spent most of the time talking with someone :) It's a coincidence that just recently I've heard stories of several people who work for many (some more than 10) years in just one company. Very often that's their first job after graduating university. They speak with confidence like they know a lot about doing career. Surely after all these years they were promoted many times. But at same time, I think sometimes such people preceive possibilities and limitations of their job as something obvious, its rules as something critically important, like it was whole world. I don't think it's good attitude and I want to avoid that.
On the other hand, noone can try in his life every possibility in terms of work and career. For example, someone who already has a house and spouse and children and mortgage many not be willing to move to different city or country or try to make his living from doing a startup or indie gamedev studio. That's why I think it's so important to talk to many different people and hear their stories. Knowing how working for some other company looks like, whether your competition or in completely different business, or how totally different may someone's work and lifestyle be (e.g. freelancing, working from home, being a consultant, traveling to different countries to do different projects, making a startup) is mind-expanding because it makes you think about your own career with all its pros and cons in the context of bigger picture of what's possible.
Back to the Pixel Heaven, I recommend this party to anyone who is interested in either retro games or indie games. There is a lot of things to do all the time so noone should be bored.